LaTeX és az ékezetes fájlnevek

 ( robert | 2007. február 1., csütörtök - 17:08 )

Sziasztok,

Annyi lenne a kérdésem, hogy megoldható-e, hogy a LaTeX elfogadjon ékezetes fájlneveket pl. az \includegraphics{} argumentumaként.

Jelenleg - ha egyszerűen beleteszek egy ékezetes útvonalat, ezzel száll el:

LaTeX Error: File `0_home_robert_Dokumentumok_K\IeC {\'e}pek_bkv' not found.

Pedig a kép ott van...

A Google nem segített, én viszont nehezen hiszem el, hogy 2007-ben az ékezetes fájlnevek problémát kell jelentsenek...

(UHU-Linux 2.0, UTF-8 kódolású a .tex fájl és UTF-8 alapú a rendszer is)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ugye nem teljes elérési útvonalat adsz meg neki, hanem ott van a doksi mellett?

Egyszerű: Ne használj ékezeteket. Nem tudom, hogy lehetne, nekem sem megy, de nem is szokás ékezetes fájlneveket használni, pont a karakterkódolás problémája miatt.

De, a példa teljes elérési úttal operál, ékezettel az útvonalban, szándékosan. Ismerem én is a trükköket, viszont egyre nehezebben fogadom el, hogy nem szabad ékezeteket használnom.

Mára a Unicode-nak köszönhetően azt hiszem kijelenthető, hogy az a program, amelyiknek problémája van az ékezetekkel, az ékezetes fájlnevekkel, nem jó program.

Azért nyitottam ezt a fórumtémát, mert nem akarom elhinni, hogy a LaTeX ennyire nem érti meg az idők szavát - reménykedem, hogy csak én nézek el valamit vele kapcsolatban.

Itt ugyan az olvasható, hogy Knuth felhagyott a TeX fejlesztéssel - nem tudom, hogy ez pontosan mit jelent, és mennyiben vonatkozik a LaTeX-re, de ha ez azt jelenti, hogy megrekedünk, ahol most vagyunk, akkor lassan ideje lesz leszoknom a LaTeX-ről.

Múljanak már el a nyolcvanas évek... :-)

""", mert nem akarom elhinni, hogy a LaTeX ennyire nem érti meg az idők szavát"""

UTF-8-ban írok latex-ben doksikat, ergo igenis modern. Az ékezetlen fálnevek meg teljesen logikusak. Amikor becsatolom a fat32-es partíciómat (pendrive-on nyilván az van), akkor nem mindegy, hogy megadom-e neki a karakterkódolást - ettől függően jól vagy rosszul jeleníti meg az ékezetes fájlneveket. Maga a rendszer UTF-8-as.

"""Knuth felhagyott a TeX fejlesztéssel"""

Elég kiforrott, nincs nagyon mit fejleszteni rajta. A csomagok fejlesztése lényegesebb, ott mindig lesz mit :)

A TeX-es világban három jelentős fejlesztési irányról tudok.

Az egyik az Omega 2, ami lehetővé teszi az európaitól nagyon eltérő nyelvek (pl. arab, héber, kínai, indiai) írásainak szedését a lehető legjobb minőségben. Ez jóval több a sima Unicode-támogatásnál, a felmerülő nehézségeket mi, kelet--nyugat-európaiak nem is sejtjük, ugyanúgy, mint angolszász nyelvterületen az átlagember nem érti, hogy miért nem jó az ASCII mindenkinek, vagy nyugat-európában nem értik, miért nem jó nekünk a hullámvonalas ő betű. Az Omega 2 már támogatni fogja az (okos) OpenType fontokat is.

A másik a LuaTeX, ami a Lua szkriptnyelv használatát teszi lehetővé a TeX-en belülről, így a rendszer olyan elemei is hatékonyan szkriptelhetővé, módosítható válnak, melyek eddig TeX-programozással csak nagyon keservesen voltak befolyásolhatók. Ilyen például az output routine (sokhasábos szedés, haladó lábjegyzetek stb.). A LuaTeX együtt fejlődik a pdfTeX-hel, itt is várható OpenType támogatás, bár esetleg nem olyan mértékben, mint az Omega 2-ben.

A harmadik pedig nyílt forrású betűtípusok készítése ékezetes betűkkel az összes európai nyelvhez. Ez általában nem jelent újfajta betűtípusokat, például a Knuth-féle klasszikus Computer Modern fontcsaládnak csak nemrég készült el az ilyen sokbetűs vektoros változata, a Latin Modern. A következő nagy fontcsalád, ami készül, a 14 (vagy 35) alap PostScript betűtípus (pl. Times, Helvetica, Courier) sokbetűs változata.

Bővebb infó a TUG és EuroTeX konferenciák anyagaiaban.

Most néhány általános megjegyzés azzal a hozzászólással kapcsolatban, amire válaszolok. A LaTeX, mint minden más szoftver, csak bizonyos korlátozások mellett használható, és csak bizonyos célra jó, más célokra kényelmetlen, vagy egyenesen használhatatlan. Ha neked az is fontos, hogy az ékezetes betűket tartalmazó ábrákat be tudd tölteni, akkor vagy javítod ezt a hibát a LaTeX-ben (mert ugye szabad szoftver, bárki bővítheti és/vagy javíthatja), vagy keresel másik programot, ami ezt is tudja (és esetleg mást nem tud, ami szintén szükséges...).

Szerintem erkölcsi szempontból nem megalapozott egy szabad szoftveren bármit számon kérni (pl. legyen Unicode-os, kezelje az ékezetes fájlneveket), mert a szoftver fejlesztője nem tartozik felelősséggel a felhasználók boldogulásáért, nem kötelessége az elvárásoknak megfelelő programot írni, követni a trendeket, kijavítani a hibákat stb. Egy szabad szoftveren egyedül az kérhető számon, hogy forgalmazói betartják-e licenszfeltételeket (pl. a felhasznált egyéb szoftverfüggőségek használata legális-e, GPL-es szoftver esetén hajlandóak-e másolási és postaköltségért postán elküldeni a forrást).

Szerintem azt is értelmetlen kijelenteni, hogy egy program nem jó program, anélkül, hogy megjelölnénk a felhasználási célt. Ha egy program nem jó _egy_adott_célra_, akkor tessék javítani rajta, vagy használni másik programot. Ez a szabad szoftver világ egyik nagy előnye, hogy nincs vendor lock-in, tehát a felhasználónak van választása, hogy egy feladatot hogy old meg: milyen szoftvert választ, milyen szoftveren javít, vagy esetleg milyen szoftvert fejleszt.

Érdekes olvasmány volt a jelenlegi fejlesztési irányokról szóló rész (bár a karakterkódolásokkal csak a szedés szintjén van kapcsolatban), köszi. Az erkölcsi megfontolásaidra inkább nem reagálok, semmi kedvem egy időrablő vitához.

Nincs-e elszúrva mai szemmel nézve az eredeti Knuth féle TeX azzal, hogy csak 1 byteos karaktereket tud használni? Nekem úgy tűnik, hogy ezzel az infrastruktúrával bajos rendesen megcsinálni az UTF-8-as Latexet.

10 éve azt mondták, hogy a magyar LaTeX több és jobb, mintha ilyen ékezeteket írnánk: \"o (ö). Merthogy ez nem ugyanaz a font, meg tud abc-be rendezni, elválasztani, stb. Tegnap viszont olvastam a TeX Book-ban az 1 byteos belső ábrázolásról, és kinyomtattam az összes karaktert így:

\char0 \char1 ... \char255

Az derült ki, hogy továbbra sincs külön tervezett ő betű, hanem az ő-t most is o-ból és "-ből kombinálja össze. És ahogy egy másik helyen írtam, meg is lehet figyelni, hogy a LaTeX-ben az (UTF-8 kódolású) ékezetes betűk parancsokká alakulnak. Ez persze eléggé megnehezíti a használatot.

Mennyire tartod jónak az Omegát. Meg lehet vele írni rendesen egy szakdolgozatot? Nekem úgy tűnik, mintha leállt volna a projekt.

--
CCC3

Ha jól emlékszem, t1enc és az új magyar.ldf használata esetén nem az alap TeX-es ékezetes betűket kapod, hanem a magyar tipográfiai tradícióknak jobban megfelelőt (más a o és a " távolsága talán), de majd pts kifejti bővebben, ő csinálta.
A javított magyarítás Debianra és Mandrivára csomagból telepíthető, de kézzel sem nagy ügy feldobni, pl. MikTeX-be win alá.

Kísérletezgetek, tisztul a kép.

A t1enc csomag obsoleted (gondolom ugyanaz, mint [T1]{fontenc}).
Az alábbiak közül csak az egyik lehet érvényben:

\usepackage[T1]{fontenc} % Latin 1/2 betűk
\usepackage[T2A]{fontenc} % angol betűk + cirill betűk + ékezetek

A T1 font önálló elemként tartalmazza a magyar ékezetes betűket, megy vele az elválasztás.

Nekem most kellenek a cirill betűk _is_, a T2A-ban viszont nincsenek benne a magyar ékezetes betűk (csak \"o típusú parancsként), ezért nem megy az elválasztás ékezetes betűt tartalmazó szavakra.

A fontenc-től függetlenül az indexben (\makeindex --> idx) mindig TeX paranccsal kódolt nemASCII betűk vannak, azért az abc-be rendezéshez vissza kell ezeket alakítani UTF-8-ra. (Egy titkárnő nehezen csinálná.) Hasonló visszaalakítás kellene, hogy az includegraphics jó filénevet mondjon az OS-nak. Mondjuk saját célra nem használok ékezetes filéneveket.

--
CCC3

A TeX célja nem is az, hogy egy titkárnő kényelmesen használja. Ha megnézed a történetét, akkor láthatdo, hogy a TeX-et Donald Knuth azért írta, mert nem tetszett neki, ahogyan szedni akarták a "The Art of Computer Programming" c. könyvét.
Knuth eléggé maximalista, szép szedést akart elérni majdnam bármi áron. Ezek után nem baj, ha munkás a használata, ha le kell mondani az ékezetes filenevekről, csak az eredmény számít. Az pedig valóban egész jó :-)
Rövid kis dokumentumok szerkesztésére, titkárnőknek ott az OOo, vagy a KWord, esetleg a LyX. TeX/LaTeX-ben tudomáyos publikációt, diplomamunkát, könyvet, stb. kell írni.

Az index sorbarendezésére a husort.pl (Perl program) javasolt (szintén pts munkája). Más nyelvekhez jó az Xindy (ez is sok disztribúcióra, pl. Mandrivára, csomagból telepíthető), sajnos a magyar ábécé-rendezés szabályai elég bonyolultak*, az Xindy régi magyar fileja elavult (változott az Xindy felépítése), az eredeti szerző nem ért rá átírni, én meg nem értek a Lisp-hez. (Azóta a Mandriva csomagot nem is nagyon update-eltem, a régi letölthető, magy újabb Mandriván is.)
-----------------------------------
* amellett, hogy bonyolultak, még nem is igazán gépesíthetők: van, aminél a sorrendbetevésnél a szabály attól függ, hogy nyelvészeti műről van-e szó. (Ha jól emlékszem.)

Magyar és orosz szavakat kell rendezgetnem, a TeX parancsokat visszaalakítom UTF-8-ra egy Flex programmal. Nem vagyok titkárnő, hanem a feleségem könyvét szerkesztem. 20 éve használok TeX-et, és azt látom sajnálattal, hogy a TeX korlátainak közelében vagyok, mert nem támogatja eléggé a többnyelvű dokumentumokat. Ami még aggasztóbb, hogy a Latex szintjén ezt nehéz lehet kijavítani, mert a TeX 1byteos karaktereket használ (ami mint tudjuk, már nem fog változni).

--
CCC3

Hát igen, ez már tényleg nem egyszerű (egyébként te írtad, hogy egy titkárnőnek nem menne, csak azért írtam, hogy az spec. nem is baj).
A TeX/LaTeX nem fogja támogatni a többyteos karakterkódolást, de pl. az Omega igen. Ettől persze neked most TeX/LaTeX-ben kell megoldanod.
Esetleg az segíthet, hogy a recode tud TeX-ékezetes cuccok és különböző karakterkódolások között konvertálni, tehát lehet valami olyat írni a programodba, hogy átkonvertálom, locale-t betöltöm, sorbarakom library rutinnal, visszakódolom. De macerás...
(Persze, ha már megvan a saját programod, akkor gondolom a feladat a te szempontodból már meg van oldva, csak azért agyalok itt, mert hátha még másnak is fog kelleni, még az Omega elterjedése előtt.
A tudományos publikációknál nem egyhamar fog elterjedni bármi más, ott bőven elég a 8 bit, úgyis angol nyelven publikál mindenki.

Egészen biztos, hogy a lehetőségek határait súrolod. A legújabb LaTeX is 8-bites karaktereket használ. A jövőben lesz majd Omega 2 és LuaTeX, melyek már full Unicode-osak lesznek. Ezek már most is kipróbálhatók, de éles feladatra nem ajánlottak még, mert akárhol előjöhet egy bug, továbbá nincs hozzájuk megfelelő dokumentáció.

Jól látod, hogy TeX valóban nem támogatja eléggé a többnyelvű dokumentumokat (kivétel, ha az összes érintett karakter a T1 kódtáblán belül van). De ha már full Unicode-os lenne, és a kétirányú írást is kellően támogatná, még az sem lenne elég -- az ázsiai nyelveknek kismillió olyan specialitása van, melyeket egy átlageurópai el se tud képzelni, és nem is érti, miért nem építik bele a támogatást néhány hét alatt. Kérdezz meg egyszer egy arabot, hogy van-e olyan szoftver, amellyel kielégítő minőségben és hatékonysággal (értsd: gyorsabban és szebben, mint kézírással) meg tud írni egy tízoldalas szöveget. Ilyen szoftver nem létezik! (Míg például magyar nyelvhez rengeteg használható szoftver van, például a LaTeX és az OpenOffice is jó lehet. Ha ezekkel a szoftverekkel akarunk arabot szedni, akkor az vagy ronda lesz, vagy elfogadhatatlanul lassan tudunk csak haladni.)

Az Omega 2 szerzői lassan már egy évtizede agyalnak a jó megoldáson. Az Omega 2 nem csak a TeX-világban lesz újdonság, hanem a dokumentumszerkesztők egészére nézve is. Kérdés, hogy mikor. A LuaTeX szerzői nem ilyen agyalósak, valószínűleg ők elsősorban Európára fognak koncentrálni (Unicode, ezen belül főleg latin, görög és cirill írások), de számukra most elsősorban nem a sokféle nyelv kezelése a legfőbb prioritás (hanem a Lua szkriptnyelv), de már felvették a TODO-listára a Unicode-ot és az OpenType-ot.

Némi kutatás után meg tudom válaszolni magamnak az érdemi kérdést: a tex fájl feljécébe belelapátolva pl. a \def\input@path{{/home/robert/áéáé//}} parancsot ezt az ékezetes útvonalat már használhatjuk is a dokumentumban.

Ez még nem a totális kánaán, de már félsiker... :-)

debian + etch + vegytiszta latin1/2 alatt teljesen jol mukodik.

Add meg az eleje'n az \usepackage{t1enc}-et is, hacsak az inputenc csomagot hasznalod, akkor nekem ugy nem mukodott, a t1enc javitotta meg:

\documentclass{article}
\usepackage[latin1]{inputenc}
\usepackage{t1enc}
\usepackage{graphics}

\begin{document}
blabla

\resizebox{10cm}{!}{\includegraphics{árvíztûrõtükörfúrógép.eps}}

dlfksdlgk

\end{document}

mivel az utf8 "modernebb" mint a latinX, feltetelezheto"en azalatt is menni fog igy...

A.

Köszi a tippet, de nálam, utf-8-as fájlnevekkel nem működik a fenti példa, még \usepackage{t1enc}-cel sem. Ha akad majd egy kicsi időm, keresgélek tovább... :-)

Én úgy tudom, hogy a core TeX legbelül 1 byteos karaktereket használ. Ami ebbe nem fér bele azt kontroll szekvenciákká alakítja. Az includegraphics így olyan fájlnevet ad tovább az OS-nek, amiben TeX parancsok vannak. Még szép, hogy ezeket az OS nem találja.

Más helyen is kibukik ez a tulajdonság. Próbálj meg ékezetes (cirill, stb) karaktereket tartalmazó, UTF-8 kódolású szöveget szószedetbe tenni (\index parancs). Keletkezik egy idx fájl, amiben látható ez a TeX parancsokká alakulás. Ezzel meg az a probléma, hogy a TeX parancsok megnehezítik az abc szerinti rendezést.

A tanulság, hogy sok sebből vérzik a Latex. Szerintem még így is nagyon jó, csak nem kell erőltetni, ami nem megy, pl. az ékezetes fájlneveket.

--
CCC3

Teljesen OT, de az ékezetes fájlneveket _úgy általában_ nem egészséges használni.
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

Nálam ez megy. Verziószámok:

$rpm -q tetex
tetex-3.0-12.2.20060mdk
$rpm -q tetex-latex
tetex-latex-3.0-12.2.20060mdk
$latex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
$tex
This is TeX, Version 3.141592 (Web2C 7.5.4)

Valószínűleg újabb verziókkal is mennie kell.

Apa által bemutatott példa símán működött KILE (PC-BSD) segítségével.