Sziasztok!
Egy szoftver (egészen pontosan egy egyetemi házi) magyar nyelven való dokumentálásához szeretném valamelyik roff-szerű programot (groff/troff/...) használni. Nagyon megtetszett, hogy jó unixos szokás szerint preprocessor-okon meg postprocessor-okon lehet pipeolni a dolgokat ellentétben az unalmas LaTeX-el.
Viszont az ékezetes karaktereket nem szereti. Azt még preconv-al meg tudtam oldani, hogy az egyszerűbb (latin1-ben lévő) karakterek (pl: é-á) működjenek, de az ő-ű sehogy sem akar rendesen megjelenni. Itt még hozzáteszem, hogy a kimenetnek pdf-be kellene menni, terminálban (pl.: nroff-al) szépen megjelenik minden utf-8-as karakter, de amint pdf/ps-ről van szó a program megadja magát.
Találtam egy groff-utf8 című projektet is, de az is csak html-be és tty-ba tolja a kimenetét. És igen html-t pdf-be konvertálni lehetne, de ennél kevésbé hackelős megoldást keresek. Hasonló okokól a " és o kombinálása sem játszik. És a dokumentáció nem egy manpage lesz, bonyolultabb formázásokat is szeretnék használni, így az openbsd-s mandoc sem jó.
parancs:
echo "ő" | groff -k -Tpdf > test.pdf
válasz:
troff: :1: warning: can't find special character 'u006F_030B'
A válaszokat előre is köszönöm!
- 206 megtekintés
Hozzászólások
Ebben a válaszban:
ezt írják:
... Unlike other troff implementations (namely Plan 9 and Heirloom troff), groff does not support UTF8 in documents...
Tehát meg lehetne próbálkozni a Heirloom dokumentációs eszközökkel, lásd
https://github.com/n-t-roff/heirloom-doctools
Hogy sikerül-e lefordítani/föltelepíteni, az már egy másik kérdés ;-)
- A hozzászóláshoz be kell jelentkezni
Én is ezt találtam meg tegnap. Nekem amúgy az jutott eszembe, hogy talán abba az irányba is el lehetne menni, hogy első lépésben iconv-val vagy recode-dal ISO-Latin-2-be konvertálni a doksit, majd mintha ISO-Latin-1 lenne, úgy odaadni a groffnak. (Lesz benne kalapos / hullámos o, és u) . Ha pedig ez működik, akkor a legvégén valami bináris peccseléssel kijavítani. (bpatch, perl script, ilyesmi.)
Nem szép, nagyon hekkelős, de aki 2021-ben roff-olni akar, annak ez nem kéne problémát okozzon. (No jó, a groff-nak se kéne problémáznia az UTF-8-cal, az is igaz.)
Amúgy jó lenne tudni valami OS, troff verzió infókat.
Jav: kipróbáltam, az utolsó lépés nem annyira triviális, mint gondoltam - legalábbis így első olvasatra nem találtam meg a kimeneti PDF-ben sem a szöveget, sem azt, hogy hol a sunyiban van a fontkészlet. Ezt csináltam:
$ echo "árvíztűrő tükörfúrógép" | iconv -f utf-8 -t iso-8859-2 | groff -K iso-8859-1 -k -T pdf > xxx.pdf
És szép kalapos U és hullámos o van, ahogy gondoltam.
- A hozzászóláshoz be kell jelentkezni
talán abba az irányba is el lehetne menni, hogy első lépésben iconv-val vagy recode-dal ISO-Latin-2-be konvertálni a doksit, majd mintha ISO-Latin-1 lenne, úgy odaadni a groffnak
Azt hiszem, hogy az alapprobléma az, hogy a groff által kezelhető karakterek halmazának számossága túl kicsi. Így még ha egyedi trükkökkel bele is tudunk varázsolni az outputba egy ő-t, ű-t, stb., ha beesik egy újabb karakter, mondjuk egy \varepsilon (hogy a TeX se maradjon említés nélkül ;-) új trükkök kellenek, vagy elfogy a tudomány.
- A hozzászóláshoz be kell jelentkezni
Köszi a válaszokat, találtam közben archwiki-n egy megoldást, ami előbb dvi-ba fordít és abból csinál egy pdf-et és azzal valamiért jó:
https://wiki.archlinux.org/index.php/Groff#Correctly_display_Polish_dia…
Az kicsit szúrja a szemem, hogy a tex-től így se szabadulok teljesen dvi miatt.
És igen, működhetne a groff és akkor nem kéne ez a plusz lépés, de mindegy, jó lesz így is.
"I am completely uninterested in your opinions of what is or is not possible. This is computer science. There aren't restrictions. I can do anything I want. It's just bits. You don't own me." - cnlohr (rawdrawandroid)
- A hozzászóláshoz be kell jelentkezni
Próbáltam a plan9-osat plan9ports-ból, de azzal se ment az ő-ű, viszont archwiki-n volt egy megoldás groff-hoz, most elég lesz az is.
"I am completely uninterested in your opinions of what is or is not possible. This is computer science. There aren't restrictions. I can do anything I want. It's just bits. You don't own me." - cnlohr (rawdrawandroid)
- A hozzászóláshoz be kell jelentkezni
Ezeket találtam én is, pont akartam is linkelni, de megelőztél. Én ezért sem tanultam meg soha a groff-ot, azért maradtam a Plain XeTeX-nél, mert nekem fontos az UTF-8, modern OpenType fontok támogatása, mikrotipográfiás eszközök, modern képformátumok beágyazása, CMYK támogatás, stb. feature-ök, ezek meg hiányoznak a *roff-ból, mint állat. Nem hiába, egy nagyon régi konstrukció, a 70-es évekből. Nem véletlen, hogy manpages-en és néhány rém egyszerű doksi legenerálásán kívül kb. senki se használja már.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Csak erre reagálnék, mert ez nem tetszik:
> Nem hiába, egy nagyon régi konstrukció, a 70-es évekből.
az elv, az előzmények valóban, '65 környékiek. Maga a UNIX világ troff-ja kb 70-71-re tehető. Ezzel szemben a konkrét megvalósítás - a GNU troff 1990-ben jelent meg (*), míg az általad kiemelt TeX első kiadása 1978. Szóval itt valami nagyon félrement. Nem azért nem jó pl. az UTF-8 kezelése, mert amikor kitalálták, még nem volt elterjedt, hanem mert valamiért a fejlesztők valamit elcsesztek. (Vagy nem - a fent említett működő megoldás eléggé ellentmond annak, hogy nem működik.) Szóval mindent elfogadok, de nem azért szarabb a groff a TeX-nél, mert régebbi.
(*) ráadásul a GNU eszközök mindig is híresek voltak arról, hogy a kompatibilitást lazán veszik (bash vs ksh pl.). Azaz még ha kellett volna bárhol pl. kompatibilis fájlformátumokkal játszani - de nem kellett, a nyelvet és az elvet implementálták újra (fentiek szerint talán nem túl átgondolt módon).
- A hozzászóláshoz be kell jelentkezni
Kösz, hogy megerősítetted, amit eddig is tudtam, meg írtam. Egyébként, ha már felhoztad, a plain TeX is elavult. Azért is írtam XeTeX-et, esetleg LuaTeX jön szóba.
Az meg nem jelent semmit, hogy a groff 1990-ben jelent meg. Attól még épp így 70-es évekbeli alap, csak licenc miatt implementálták újra. Azzal viszont egyetértek, hogy a GNU eszközök sokszor fél vállról veszik a kompatibilitást. Annyira nem, hogy a gáz legyen, de semmiképp nem 100%-ban kompatibilisek. Szerintem már ez az egész GNU kérdés elavult, annak idején nagy jelentősége volt, míg a BSD-k helyzete jogilag nem volt teljesen tisztázott. De mivel a GNU-t felkarolta a Linux, így köztudatban maradt. Részemről a BSD userland szimpatikusabbnak tűnik, de ennek ellenére a GNU sem használhatatlan, elvagyok azokkal is bármikor. Nálam csak az a lényeg, hogy ne Apple-ös, meg MS-os szutyok legyen a rendszer, ami csak önmagával kompatibilis, vagy még azzal se.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Szerintem már ez az egész GNU kérdés elavult, annak idején nagy jelentősége volt, míg a BSD-k helyzete jogilag nem volt teljesen tisztázott.
Szerintem már csak azért sem avult el, mert éppen a GNU toolchain tette/teszi lehetővé rengeteg új hardver eszközre a Linux, az Android, vagy más oprendszer portolását, megfelelő vezérlő/rendszerprogramok elkészítését (tudom, a BSD-k is mennek a kenyérpirítókon ;)
- A hozzászóláshoz be kell jelentkezni
A modern portolásokat a Linux kernel, meg különböző inites, grafikus és más API-k teszik lehetővé. A GNU toolchaine csak unixos userlandet biztosít, de azt már biztosítja azóta a tisztázott helyzetű BSD/Open/Libre/tökömtudja milyen toolchain is, Rustban újraimplenetmált toolok, sőt, ugyanez igaz még a gcc-vel is, hiszen ott van már a llvm, clang, stb.. De az a baj, hogy félreértitek, amit írok. Sehol nem mondtam, hogy maga a GNU avult volna el, vagy nem lenne alkalmas eszköz a feladatra. Hanem az az igény avult el, ami életre hívta, hogy mindenáron szükség van rá, egyedüli linuxos userlandként. Ma már számos alternatívája van. Linux disztrók tradicionalitásból ragaszkodnak hozzá, talán mert megszokott lett, és emögé sorakozott be a legtöbb fejlesztő. Amikor a GNU indult, akkor tényleg égető szükség volt rá, mert a unixos toolokat védte az AT&T licenc, a BSD helyzete nem volt tisztázott, pereknek nézhetett elébe, aki bevállalta. A Linux kernel mellé meg kellett valami jogilag is tiszta, szabadon terjeszthető megoldás, hogy komplett OS legyen. De ma már, így 30+ év után nem ez a helyzet, hogy GNU mindenáron, mindenkinek, minden igényre. Szépen példázza ezt az Alpine Linux, különböző BSD-terjesztések, MacOS, stb.. Ennek ellenére a GNU-val sincs semmi baj, a történeti érdeme is nagy jelentőségű, csak a mai szerepe nem olyan jelentős már, mint azt sokan gondolják. Ezt akartam belőle kihozni.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Hát, erre a feladatra még valószínűleg groff-ot használok, de ha legközelebb feljön szövegszerkesztés kipróbálom a Tex-eket, ami eddig visszatartott az a texlive packagek mérete (btw arch-on).
"I am completely uninterested in your opinions of what is or is not possible. This is computer science. There aren't restrictions. I can do anything I want. It's just bits. You don't own me." - cnlohr (rawdrawandroid)
- A hozzászóláshoz be kell jelentkezni
Kicsit off: mi annak idején doxygent használtunk szoftver dokumentálására. Tud html, pdf, rtf és man kimenetet is. Ha nagyon nem jutsz előre a roffos megközelítéssel, szerintem éremes lehet elgondolkodni rajta.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni