Gentoo: man-pages-cs: UTF-8 vs. ISO-8859-2

4.1.2007 20:18 | Přečteno: 3372× | | poslední úprava: 15.1.2007 18:54

Gentoo portage obsahuje groff ve verzi, která umí zobrazovat 8bitové manuálové stránky na UTF-8 terminálu. Ovšem už neumí zpracovat manuálové stránky, které jsou samotné v UTF-8.

Sbírka českých manuálových stránek man-pages-cs dovoluje během instalace překódovat stránky do UTF-8 nebo je ponechat v ISO-8859-2. Problém je, jak se která možnost vybírá.

Pohledem do Makefilu zjistíme, že se rozhoduje podle obsahu proměnných prostředí LANG a LC_ALL. Obsahuje-li alespoň jedna z nich řetězec UTF-8, budou stránky nainstalovány v UTF-8. Jak vidno, výsledek práce závisí na locale správce systému.

Obě popsané vlastnosti vedou k nečitelným manuálovým stránkám. Proto jsem vytvořil ebuild, který reaguje na USE flag unicode a podle něj řídí instalaci. Samozřejmě odstraňuje citlivost na locale správce. Navíc obsahuje rady, jak přivézt man/groff k rozumnému výstupu.

V současnosti je jediný postup, jak vidět manuálové stránky hezky česky v UTF-8 terminálu, a to následující:

# Přesuňte ebuild do portage a vygenerujte kontrolní součty.

echo "app-i18n/man-pages-cs" >> /etc/portage/package.keywords
echo "app-i18n/man-pages-cs -unicode" >> /etc/portage/package.use
emerge man-pages-cs
sed --in-place \
  's/nroff -Tascii -c -mandoc/nroff -Tutf8 -mlatin2 -c -mandoc/' \
  /etc/man.conf

Patch jsem již poslal do Bugzilly (#159906).

Doplnění:

Jan Kundrát mi vytkl, že C.UTF-8 není korektní locale. V tom má pravdu, a tak jsem ebuild předělal tak, aby vše bylo v naprostém pořádku. Výsledkem je patch na původní Makefile, který může být užitečný i mimo Gentoo.

       

Komentáře

[Filip Jirsák]

Díky, funguje! Rozpadlé kódování UTF-8 se čte přeci jenom hůř, než pokud se rozpadne některé z 8bitových kódování

[Luboš Doležel (Doli)]

Pro dobro všech bych navrhoval zrušit ten link do Bugzilly Gentoo (spamboti).

[petr_p]

Ono je mozne prispivat bez registrace? Nebo mate na mysli dnesni lenost Bugzilly?

[Luboš Doležel (Doli)]

Mám namysli to, že přes tenhle link se spamboti můžou dostat k e-mailovým adresám, které jsou ve stránce toho bugu. Všimni si, že z hlavní stránky Bugzilly (právě proto) nevede žádný link přímo k bugům, je tam jen vyhledávání/zadání čísla.

[Non_E]

Super, běží to. Už nemusím používat výhradně anglické manuály

[Marián Kyral]

Díky, až budu doma, tak to vyzkouším.

[Marián Kyral]

Tak funguje, ale teď bych zase pro změnu potřeboval přesvědčit konqueror aby ty man stránky zobrazoval ve správném kódování. Manuálně to přepínat není moc pohodlné

BTW:

LOG: postinst
man utility can't recognise encoding of manual pages. Therefore
you should replace -Tascii by -mlatin2 in /etc/man.conf on line
configuring nroff. Otherwise manual pages wouldn't be displayed
properly.

s/-Tascii by -mlatin2/-Tascii by -Tutf8 -mlatin2/

[petr_p]

Dik.

[zde]

Půjdeme zkratkou! Je to sice o trochu delší, ale zato horší cestou. Používejme výborné a superiorní UTF-8 locales. Textové soubory sice zabírají více místa na disku, ale zato nám přestane fungovat man. :) :) :)

[petr_p]

Tak to pozor. Ja netvrdim, ze je chyba v UTF-8 locale a man je bezchybny a proto zustaneme u osmibitu. Naopak se tesim, az groff bude umet sam o sobe UTF-8.

Moje reseni neni konecne. Je to jen docasny krok zpet, ktery se vyplati na osobnim pocitaci, kde si vystacime s anglictinou a cestinou.

Pokud by vas to zajimalo, tak vyvojove verze groffu uz umi rozpoznat znakovou sadu manualove stranky a na zaklade teto informace predradit patricny filtr. Bohuzel stale jsou problemy s pruchodem sirokych znaku celou *roff masinerii. (Existuji specializovana reseni pro CJK jazyky, ale to nas nemusi vzrusovat.)

[Filip Jirsák]

V době disků v řádech stovek GB je těch pár bajtů navíc opravdu problém. Když navíc s UTF-8 získám možnost používat libovolný znak, který mne napadne, a ne jen pár „vyvolených“ znaků…

Hm, docela by mne zajímalo, jak bych předchozí větu správně česky napsal třeba v iso-latin-2…

[zde]

V době disků v řádech stovek GB je těch pár bajtů navíc opravdu problém.

Pravda. A kdo si hraje nezlobí, ale stejně umře. A navíc bude konec světa.

možnost používat libovolný znak, který mne napadne, a ne jen pár „vyvolených“ znaků…

не понимать HTML entity? да это возможное также без UTF8 locale.

[Filip Jirsák]

HTML entity? V čistě textovém souboru? To bych si početl…

[zde]

Vy píšete rozsáhlý, smysluplný text, plný diakritiky a speciálních symbolů které "nutně" potřebujete, a píšete to do "čistě textového" souboru, kde psané znaky textu nejsou v žádném strukturovaném kontejneru (HTML/XML/YAML/TEX/RTF/Structured text/Media Wiki/...)? Požadujete instantní přístup do všech znakových sad, a současně vám nevadí nedostupnost základní kontroly nad strukturou textu (odstavce, kapitoly, styly, nadpisy, tabulky, seznamy, odkazy...)? Proti gustu žádný ..., ale fakt nevím co si o tom myslet...

[Filip Jirsák]

Žádný z uvedených formátů neumožňuje zapsat znaky mimo znakovou sadu iso-latin-? úsporněji, než UTF-8. HTML entity jsou delší; XML musím psát buď v UTF-8 (nebo jiném Unicode), jinak tam opět znaky z celé Unicode nedostanu; a ostatní formáty na tom budou podobně.

Ztěžovat si, že univerzální UTF-8 české znaky s diakritikou zapisuje pomocí 2 bajtů, a navrhovat individuální řešení pro každý formát, kde navíc české znaky s diakritikou budou mít třeba 5 bajtů - není to protimluv?

[zde]

Žádný z uvedených formátů neumožňuje zapsat znaky mimo znakovou sadu iso-latin-? úsporněji, než UTF-8.

To nerozporuji. Ovšem český uživatel potřebuje znaky mimo ISO2 velmi, velmi zřídka. Naopak v psané češtině jsou znaky s diakritikou (na které má UTF8 dodatečnou režii 100%) velmi časté, odhadem 15-25%, což je dominantní. A protože možnosti obou formátů jsou stejné, není UTF8 na místě.

XML musím psát buď v UTF-8 (nebo jiném Unicode), jinak tam opět znaky z celé Unicode nedostanu; a ostatní formáty na tom budou podobně.

XML opravdu nepodporuje HTML entity?

Ztěžovat si, že univerzální UTF-8 české znaky s diakritikou zapisuje pomocí 2 bajtů, a navrhovat individuální řešení pro každý formát, kde navíc české znaky s diakritikou budou mít třeba 5 bajtů - není to protimluv?

Ano, je to protimluv, každé balancování výhod a nevýhod je protimluv. Čert vem neefektivitu UTF8 na českém textu. Máme jeden problém- nutnost používat více než 256 znaků. Existují dvě řešení: UTF8, nebo používání nějakého markup jazyka. Proč na stejnou věc používat dva mechanismy? Nebylo by dobré jeden z nich zrušit? Bez UTF8 se obejdu docela dobře; bez nějakého ML se ale neobejdu. Volba je proto jasná- jdeme na pekaře a UTF8 letí do koše.

[Filip Jirsák]

Ovšem český uživatel potřebuje znaky mimo ISO2 velmi, velmi zřídka.

Pokud mu nevadí, že píše jako prase, a používá znak palce místo uvozovek, mínus místo pomlčky, tři tečky místo výpustky…

XML opravdu nepodporuje HTML entity?

Ne.

Existují dvě řešení: UTF8, nebo používání nějakého markup jazyka. Proč na stejnou věc používat dva mechanismy?

Protože jsou to 2 různé věci. Jedno je text, což je více znaků za sebou, druhé je značkování (např. textu).

… kde navíc české znaky s diakritikou budou mít třeba 5 bajtů

Pardon, tuhle demagogii jsem napoprvé přehlédl.. Do HTML/XML dokumentu s encodingem správně nastaveným na ISO8859-2 samozřejmě české znaky vkládáte jako 1, nikoliv jako 5, bajtů.

A každý program pak musí umět desítky různých znakových sad. Navíc vkládat přímo do dokumentu samotného informaci o tom, v jakém je dokument kódování, je dost nepraktické a způsobuje to spoustu problémů.

Unicode je po letech problémů s různými znakovými sadami konečně relativně dobré řešení, a už aby bylo všude a na nějaká iso-8859-2 a Windows-1250 a CP850 a Kamenické a KOI-8-ČS se mohlo zapomenout.

[zde]

1) V době kdy půlka mladejch ignoruje shodu podmětu s přísudkem, nadměrně klepe do klávesy 'w', a důsledně píše bez diakritiky, bych vámi úváděné prohřešky nepřeceňoval. Trochu realismu, prosím.

2) Podle wiki jde numerická HTML entita normálně vložit i do XML dokumentu, rozdíl je jen že když je hexadecimální, musí být malými písmeny. Takže se zřejmě mýlíte.

3) Jistě, principielně jde o různé věci. Ale když už značkovací jazyk zavedl escapes pro vkládání značek, a umožňuje je (a alespoň pro čechy výrazně efektivněji než UTF8) použít pro vkládání unicode znaků mimo aktuální 8-bit znakovou sadu, jsou to dvě mouchy (funkcionality) jednou ranou (nástrojem). Proč tedy používat další?

4) Jaképak "program musí umět desítky kódování...."??? NLS podpora je dávno v glibc, a API je plně nezávislé na použíté znakové sadě. Tvrdíte že uložení informace o použitém kódování do dokumentu přináší problémy? Jak je asi tak vyřešíte, když krom starých 8-bit kódování začnete používat i jakési UTF8?

[Filip Jirsák]

2) Podle wiki jde numerická HTML entita normálně vložit i do XML dokumentu, rozdíl je jen že když je hexadecimální, musí být malými písmeny. Takže se zřejmě mýlíte.

Máte pravdu, myslel jsem si, že numerické entity se odkazují k aktuálnímu kódování XML dokumentu, ve skutečnosti se odkazují na Unicode.

Výhoda je ta, že můžu na všechna stará kódování zapomenout, a používat jedno kódování znaků (Unicode) s omezenou množinou způsobů, jak se znaky z tohoto kódování převádějí na posloupnost bitů - navíc pomocí BOM je možné jednoznačně a bez věštění určit, který způsob zápisu je použit.

České manuálové stránky byl první problém s UTF-8, který jsem zaznamenal, a díky tomuto spotu u mne trval jenom 3 dny (předtím jsme používal anglické manuálové stránky). Všude jinde bylo naopak užití UTF-8 bezproblémové, naopak se jím odstranila spousta problémů, např. když aplikace byla vyvíjená ve Windows s Win1250, na serveru běžela pod Linuxem s iso-8859-2 (nebo iso-8859-1). Takže děkuji, že jste mne chtěl před zlem Unicode zachránit, ale mně již není pomoci, už doporučuju a cpu Unicode všude, kde je to jen trochu možné.

[Michal Vyskočil]

Doublepost jsem smazal ...

[zde]

.. kde navíc české znaky s diakritikou budou mít třeba 5 bajtů

Pardon, tuhle demagogii jsem napoprvé přehlédl.. Do HTML/XML dokumentu s encodingem správně nastaveným na ISO8859-2 samozřejmě české znaky vkládáte jako 1, nikoliv jako 5, bajtů.

[yac]

Díky tomuto článku jsem si uvědomil, že řešení mého problému je zleca jednoduché... paludis -u man-pages-cs. Díky za inspiraci.

[Smajchl]

Jsem asi hloupej, jak se to ma spravne udelat?

stahnul jsem ten ebuild a dal jsem ho do /opt/moje_ebuildy/app-i18n/man-pages-cs potom jsem spustil prikaz ebuild /opt/moje_ebuildy/app-i18n/man-pages-cs/man-pages-cs-0.16-r2.ebuild digest

a nakonec:

# emerge -av man-pages-cs

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] app-i18n/man-pages-cs-0.16-r2 [0.16] USE="-unicode%" 0 kB [1]

Total: 1 package (1 upgrade), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /opt/moje_ebuildy

Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) app-i18n/man-pages-cs-0.16-r2 to /
 * man-pages-cs-0.16.tar.gz MD5 RMD160 SHA1 SHA256 size  ...           [ ok ]
 * checking ebuild checksums  ...                                      [ ok ]
 * checking auxfile checksums  ...                                     [ ok ]
 * checking miscfile checksums  ...                                    [ ok ]
 * checking man-pages-cs-0.16.tar.gz  ...                              [ ok ]
>>> Unpacking source...
>>> Unpacking man-pages-cs-0.16.tar.gz to /var/tmp/portage/app-i18n/man-pages-cs-0.16-r2/work

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /opt/moje_ebuildy/app-i18n/man-pages-cs/files/man-pages-cs-unicode.diff
 *   ( man-pages-cs-unicode.diff )

 *
 * ERROR: app-i18n/man-pages-cs-0.16-r2 failed.
 * Call stack:
 *                     ebuild.sh, line 1701:  Called dyn_unpack
 *                     ebuild.sh, line  817:  Called qa_call 'src_unpack'
 *                     ebuild.sh, line   44:  Called src_unpack
 *   man-pages-cs-0.16-r2.ebuild, line   20:  Called epatch '/opt/moje_ebuildy/app-i18n/man-pages-cs/files/man-pages-cs-unicode.diff'
 *                 eutils.eclass, line  161:  Called die
 * The specific snippet of code:
 *                      die "Cannot find \$EPATCH_SOURCE!"
 *  The die message:
 *   Cannot find $EPATCH_SOURCE!
 *
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/portage/app-i18n/man-pages-cs-0.16-r2/temp/build.log'.
 * This ebuild is from an overlay: '/opt/moje_ebuildy/'
 *

 * Messages for package app-i18n/man-pages-cs-0.16-r2:

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /opt/moje_ebuildy/app-i18n/man-pages-cs/files/man-pages-cs-unicode.diff
 *   ( man-pages-cs-unicode.diff )
 *
 * ERROR: app-i18n/man-pages-cs-0.16-r2 failed.
 * Call stack:
 *                     ebuild.sh, line 1701:  Called dyn_unpack
 *                     ebuild.sh, line  817:  Called qa_call 'src_unpack'
 *                     ebuild.sh, line   44:  Called src_unpack
 *   man-pages-cs-0.16-r2.ebuild, line   20:  Called epatch '/opt/moje_ebuildy/app-i18n/man-pages-cs/files/man-pages-cs-unicode.diff'
 *                 eutils.eclass, line  161:  Called die
 * The specific snippet of code:
 *                      die "Cannot find \$EPATCH_SOURCE!"
 *  The die message:
 *   Cannot find $EPATCH_SOURCE!
 *
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/portage/app-i18n/man-pages-cs-0.16-r2/temp/build.log'.
 * This ebuild is from an overlay: '/opt/moje_ebuildy/'
 *

Koukal jsem ale, ze nektery manualovy stranky jsou v iso8859-2 a nektery v utf8 a oboje jsou zobrazeny spatne, kazdy ale jinak spatne.

Ma vubec cenu pouzivat utf8? treba Elinks pri pouziti utf8 se po chvilce pouzivani zacne rozpadat (zustavaj sem tam naky znaky) ale cestina je v nem ok.

A ten man, to se neda proste cist

[petr_p]

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /opt/moje_ebuildy/app-i18n/man-pages-cs/files/man-pages-cs-unicode.diff
 *   ( man-pages-cs-unicode.diff )

Nestáhnul jste si potřebné patche, a tak instalace selhala a stále máte nainstalovanou starou verzi.

Měl jsem lépe popsat, co všechno je třeba:

Do /opt/moje_ebuildy/app-i18n/man-pages-cs/files/ uložte soubor man-pages-cs-unicode.diff, znovu přegenerujte kontrolní součty příkazem ebuild /opt/moje_ebuildy/app-i18n/man-pages-cs/man-pages-cs-0.16-r2.ebuild manifest (parametr digest je zastaralý a měl by se používat manifest) a pak by již instalace měla proběhnout.

Možná vás bude zajímat, že již byla vydána nová verze manuálových stránek. A možná bude pro vás nejsnažší zkopírovat celý podstrom app-i18n/man-pages-cs z mého webu do /opt/moje_ebuildy/app-i18n. Pak nebude třeba ani regenerovat kontrolní součty.

Pokud jsou některé stránky v ISO-8859-2 a jiné v UTF-8, tak to je chyba asi jejich správce. Avšak správce se zdá být přes email nedobytný, tak přeji hodně štěstí.

Ohledně elinksu: já používám původní links2, který v UTF-8 prostředí zahazuje diakritiku a drží se původní jednoduchosti, od které se elinks již vzdálil.

[Smajchl]

Ja jsem si rikal, jestli soubor man-pages-cs-unicode.diff nemam vzit z distribucniho ebuildu, ale radeji sem se zeptal, dekuju moc za bleskovou odpoved.

To s tou novou verzi sem nepochopil, ale zejtra si zkopiruju podstrom ze stranek a podivam se i na stranky

A s elinksem: zkusim links2, neznam ho tak uvidime. Me se na elinksu libilo to ze toho umi vic oproti linksu a hlavne je barevnej

[Smajchl]

Zkompiloval jsem to uz v pohode, tu novou verzi, ale ani s flagem unicode ani s -unicode to nezobrazuje spravne pokazdy je to stejny a vypada to takhle: mplayer - pĹehrĂĄvaÄ filmĹŻ

v souboru /etc/man.conf mam toto:

FHS

MANPATH /usr/share/man
MANPATH /usr/local/share/man
MANPATH /usr/X11R6/man
MANPATH /usr/local/man
MANPATH /usr/man


MANPATH_MAP     /bin                    /usr/share/man
MANPATH_MAP     /sbin                   /usr/share/man
MANPATH_MAP     /usr/bin                /usr/share/man
MANPATH_MAP     /usr/sbin               /usr/share/man
MANPATH_MAP     /usr/local/bin          /usr/local/share/man
MANPATH_MAP     /usr/local/sbin         /usr/local/share/man
MANPATH_MAP     /usr/X11R6/bin          /usr/X11R6/man
MANPATH_MAP     /usr/bin/X11            /usr/X11R6/man
MANPATH_MAP     /usr/bin/mh             /usr/share/man

TROFF           /usr/bin/groff -Tps -mandoc
NROFF           /usr/bin/nroff -Tutf8 -mlatin2 -c -mandoc
JNROFF          /usr/bin/groff -Tnippon -mandocj
EQN             /usr/bin/geqn -Tps
NEQN            /usr/bin/geqn -Tlatin1
JNEQN           /usr/bin/geqn -Tnippon
TBL             /usr/bin/gtbl
# COL           /usr/bin/col
REFER           /usr/bin/refer
PIC             /usr/bin/pic
VGRIND
GRAP
PAGER           /usr/bin/less -is
BROWSER         /usr/bin/less -is
HTMLPAGER       /bin/cat
CAT             /bin/cat

CMP             /usr/bin/cmp -s

COMPRESS        /bin/bzip2
COMPRESS_EXT    .bz2

MANSECT         1:1p:8:2:3:3p:4:5:6:7:9:0p:tcl:n:l:p:o:1x:2x:3x:4x:5x:6x:7x:8x

.gz             /bin/gunzip -c
.bz2            /bin/bzip2 -c -d
.z
.Z              /bin/zcat
.F
.Y

Co je spatne?

[petr_p]

mplayer(1) není součástí balíku man-pages-cs. Instaluje se spolu s MPlayerem a tato stránka je dodávána v kódování UTF-8. Takže si buď doinstalujte groff-utf8 nebo ji překódujte do ISO-8859-2.

Jenom aby bylo jasno: man-pages-cs je sbírka českých manuálových stránek a přepínač unicode pouze říká, v jaké znakové sadě budou tyto stránky nainstalovány do systému. Závěrečná rada ohledně změny /etc/man.conf vysvětluje groffu, jaká znaková sada je na jeho vstupu (parametr -m) a v jaké sadě má být výstup na terminál (parametr -T). Takže je třeba zajistit, aby všechny manuálová stránky byly uloženy ve stejné sadě.

Z toho důvodu já v současnosti upřednostňuji balík groff-utf8 a všechny české stránky mám uložené v UTF-8 (mplayer(1) implicitně, man-pages-cs explicitně přes USE=unicode).