ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | \'encoding\' field ignored by utils | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Vitaly A. Ostanin <vyt> |
| Component: | docbook-utils | Assignee: | Mikhail Zabaluev <mhz> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P4 | CC: | aris |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
Explicit specification of the character set in HTML files is: - not belonging to the core standard; - considered harmful. Therefore, I think, the HTML issue is not a bug. On RTF I\'m not sure; the codepage information might probably be hacked into \\ansicpgNNN tag (oh ugliness), but this would open another can of worms. Explicit specification of the character set in HTML files is: - not belonging to the core standard; - considered harmful. Therefore, I think, the HTML issue is not a bug. On RTF I\'m not sure; the codepage information might probably be hacked into \\ansicpgNNN tag (oh ugliness), but this would open another can of worms. Так чем нужно пользоваться для определения кодировки в html? Не по content type charset= работает автоопределение кодировки? Для rtf указание языка должно быть - сделал rtf из koi8-r и из cp1251 - оба в ворде не читаются. В общем, если это не баги, поделитесь right way, pls. Так чем нужно пользоваться для определения кодировки в html? Не по content type charset= работает автоопределение кодировки? Для rtf указание языка должно быть - сделал rtf из koi8-r и из cp1251 - оба в ворде не читаются. В общем, если это не баги, поделитесь right way, pls. Определение кодировки в HTML традиционно возложено на внешние средства, главным образом HTTP (откуда и пришла <META http-equiv=\"...\" ...>) и MIME. Автоопределение кодировки в файле, по-моему, не входит в сферу рассмотрения системы генерации. Насчёт rtf присяжные всё ещё совещаются. Может быть, имеет смысл делать escapes для всех не-ASCII символов? Будем смотреть, что на самом деле производит backend rtf. Определение кодировки в HTML традиционно возложено на внешние средства, главным образом HTTP (откуда и пришла <META http-equiv=\"...\" ...>) и MIME. Автоопределение кодировки в файле, по-моему, не входит в сферу рассмотрения системы генерации. Насчёт rtf присяжные всё ещё совещаются. Может быть, имеет смысл делать escapes для всех не-ASCII символов? Будем смотреть, что на самом деле производит backend rtf. Неудачная традиция, совершенно не right way :( Как быть с html, полученными не через http, локально, например? Лучше бы это было опционально в utils - ставить кодировку или нет. Я бы, например, ставил - документацию будут читать люди, которые про \"not belonging\" не слышали (надеюсь, что будут :)). Кстати, russian apache, упомянутый в похожем обсуждении в <a href="mailto:devel@altlinux.ru" target="_new">devel@altlinux.ru</a> - тоже не лучшее решение. Насчет rtf как-то упоминалось (если не ошибаюсь, AEN\'ом), что там должно быть указание языка. Неудачная традиция, совершенно не right way :( Как быть с html, полученными не через http, локально, например? Лучше бы это было опционально в utils - ставить кодировку или нет. Я бы, например, ставил - документацию будут читать люди, которые про \"not belonging\" не слышали (надеюсь, что будут :)). Кстати, russian apache, упомянутый в похожем обсуждении в <a href="mailto:devel@altlinux.ru" target="_new">devel@altlinux.ru</a> - тоже не лучшее решение. Насчет rtf как-то упоминалось (если не ошибаюсь, AEN\'ом), что там должно быть указание языка. The problem is, OpenJade in its current state does not recognize koi8-r and windows-1251 (NB the IANA-approved name). For HTML, this is not fatal, apart from the questionable META issue. The RTF case can be helped by converting the XML source file to utf-8, with appropriate document changes. Then, run jw this way: SP_ENCODING=utf-8 jw -b rtf file.xml The problem is, OpenJade in its current state does not recognize koi8-r and windows-1251 (NB the IANA-approved name). For HTML, this is not fatal, apart from the questionable META issue. The RTF case can be helped by converting the XML source file to utf-8, with appropriate document changes. Then, run jw this way: SP_ENCODING=utf-8 jw -b rtf file.xml Ок, спасибо. Feedback все еще нужен? Тогда чем, перевесить багу на openjade? Ок, спасибо. Feedback все еще нужен? Тогда чем, перевесить багу на openjade? Use xsltproc with either chunk stylesheets or hack stylesheet wrappers with charset specified, supplied in the docbook-style-xsl package. Use xsltproc with either chunk stylesheets or hack stylesheet wrappers with charset specified, supplied in the docbook-style-xsl package. Как оказалось, это не баг. Для указания кодировки действительно лучше пользоваться стилями из docbook-style-xsl. Как оказалось, это не баг. Для указания кодировки действительно лучше пользоваться стилями из docbook-style-xsl. |
Из файла со следующим заголовком <?xml version=\"1.0\" encoding=\"koi8-r\"?> <!DOCTYPE chapter PUBLIC \"-//OASIS//DTD DocBook XML V4.1.2//EN\" \"<a href="http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd\">">http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd\"></a>; получаются файлы без указания кодировки, проверено на docbook2html -u file.xml и docbook2rtf file.xml. В file.html указания charset нет вообще, file.rtf показывается в word\'е (97) кракозябрами, смена шрифта не помогает. Перекодировка file.xml в cp1251 и смена encoding на cp1251 (как и убирание совсем) не помогла. Текст в file.xml в кодировке koi8-r, конвертацию запускаю на системе в CP1251. docbook-utils-0.6.9-alt2 openjade-1.3.1-alt1 docbook-dtds-1.0-alt2 Система - Master beta 1/Sisyphus 20020314, CP1251 --- ---