Tag: latex

Hibakeresés: LaTeX ábrafelirat probléma

Nemrég volt szerencsém egy idegesítő LaTeX feature-höz (ugye nem bug, hanem feature). Miután visszafejteni a hiba okát elég macerás volt, ezért gondoltam, megosztom itt is.

Megkérdezték tőlem, van-e ötletem, mitől lehet az, hogy egy ábra hivatkozásánál a számot miért jeleníti meg teljesen más stílusban, mint a többi ábrahivatkozást, ill. mint az ábra feliratát. A probléma úgy jelentkezett, hogy Figure 9. számú ábra (ez az elvárt formátum), míg a hivatkozása Figure 4.4 formátumban jelent meg.

A hivatkozásokat a LaTeX vissza tudta fejteni, semmiféle hibaüzenet nem jelent meg, csak rosszul jelent meg a sorszám. Nagyon látványos hiba sem volt a kódban, többszöri átolvasás után (lényegében hasonlóan nézett ki, mint a többi ábrabeillesztés).

Megpróbálgatva kihagyni elemeket, áthelyezni a kritikus ábrát, illetve hivatkozást sikerült rájönni, hogy a LaTeX valami miatt a fejezet/szakasz-számot jeleníti meg az ábra sorszáma helyett.

Innen már egy gyors Google megadta a megoldást: http://www.leancrew.com/all-this/2008/09/latex-figure-captions/ , ill. az oldalon keresztül a következő lap: http://en.wikibooks.org/wiki/LaTeX/Labels_and_Cross-referencing#Fixing_wrong_labels

A megoldás lényege a következő: semmilyen körülmények között ne legyen a [cci_latex]\label[/cci_latex] címkeparancs a [cci_latex]\caption[/cci_latex] feliratparancs elé. A feliratparancs belsejébe vagy a feliratparancs utánra nyugodtan kerülhet.

A végére beszúrok egy javasolt mintát kép beillesztésére, ami ezt a hibát elkerüli (a forrás a TeXlipse plug-in sablon gyűjteménye:

[cc_latex]\begin{figure}[htp]
\begin{center}
\includegraphics[width=${figureWidth}]{${filename}}
\caption[${labelInTOC}]{${figureCaption}}
\label{${figureLabel}}
\end{center}
\end{figure}[/cc_latex]

A TeXlipse editor ezt a mintát automatikusan beilleszti, ezért nekem nehéz ezt a hibát elkövetnem, de másnak még hasznos lehet. Remélem, van, akinek a megoldás megosztásával

Új TeXlipse – új lehetőségek

Még októberben írtam arról, mire való a [[LaTeX szerkesztés OSX-en|synctex]], és ezt hogyan lehet felhasználni a Skim és a Texlipse környezet összekötésére. Illetve arról is, hogy helyenként problémás.

Most, hogy megjelent egy újabb Texlipse változat (1.3), és újabb, rövid határidejű LaTeX dokumentumokat kell előállítanom, ezért megnéztem, hogy mi a helyzet most.

Még októberben írtam arról, mire való a synctex, és ezt hogyan lehet felhasználni a Skim és a Texlipse környezet összekötésére. Illetve arról is, hogy helyenként problémás.

Most, hogy megjelent egy újabb Texlipse változat (1.3), és újabb, rövid határidejű LaTeX dokumentumokat kell előállítanom, ezért megnéztem, hogy mi a helyzet most.

Természetesen a helyzet rossz és reménytelen :D, de kicsit konkrétabban (és kevésbé pesszimistán szemlélve rá lehet jönni), hogy egészen pontosan mi/hogyan változott, és ezt hogyan lehet exploitolni.

A Texlipse 1.3-as változatának számomra legfontosabb újdonsága, hogy együtt működik a Skim auto reload funkciójával, azaz nem kell kézzel frissítgetnem a pdf kimenetet.

Ugyanakkor a synctex (vagy a hasonló célú pdfsync) továbbra sem az igazi. A pdfsync segítségével gyorsan tudok lépdelni a pdf illetve a tex-fájl egyes helyei között, ami roppant hasznos dolog, ha pl. aki proofreadel, az oldalszámmal tudja jelölni a hibát, amit kicsit nehézkes visszakonvertálni latex source-ra.

De ahhoz, hogy ez működjön, fontos, hogy a generált synctex.gz (pdfsync esetén most nem mondom meg a generált kiterjesztést) ugyanabban a könyvtárban legyen, mint a tex fájl, ugyanis a LaTeX környezet ebben a mappában keresi; ugyanakkor az is fontos, hogy ugyanabban a mappában legyen, mint a pdf fájl, mert a pdf néző meg ott keresi… Szóval a kiforrott, több-könyvtáros megközelítések problémásak tudnak lenni. De legalább így működik.

És még egy fontos dolog: amit a múltkor mutattam scriptet a Texlipse megszólítására, frissíteni kell, ugyanis direkt meg lett szólítva a texlipse.jar fájl, és a frissítés után az elérhetősége ennek megváltozott. Eltartott egy darabig, amíg erre a gondra rájöttem, ugyanis semmilyen hibaüzenetet nem kaptam a visszafele kereséskor. De azért csak meglett.

Az új, módosított scriptem:

java -classpath "/Applications/eclipse/dropins/texlipse/plugins/net.sourceforge.texlipse_1.3.0/texlipse.jar" net.sourceforge.texlipse.viewer.util.FileLocationClient -p 55000 -f $2 -l $1

És most a végére néhány apróság, amire érdemes lehet odafigyelni:

  • Ha még nem frissítettél az 1.3.0-s változatra, akkor várj pár napot, ugyanis felbukkant egy elég idegesítő bibtex parsing hiba. A hétvégére ígértek új kiadást.
  • Amikor frissíteni próbáltam, akkor a P2 valami miatt nem akarta letölteni a cuccot, de a dropins mappába könnyen tudtam telepíteni. Emiatt is változott az elérési útja a texlipse.jar-nak. Nem tudom, mi volt az oka, de majd egyszer esetleg ezzel is elszórakozom.

Alapvetően azért szeretem az új kiadást, de vannak gyenge pontok. Mindenesetre a váltást nem bántam meg, de jöhetne már az 1.3.1.:D

Margók a LaTeXben – grafikusan

A LaTeX egyik legbonyolultabb része a margók kezelése. Pláne, hogy a beállításait relatív módon kell megadni.

Ahhoz, hogy ezt kényelmesebben lehessen csinálni, hasznos tudni, hogy mik az aktuális beállítások. Ebben próbálok segíteni azzal, hogy röviden leírom a [[http://www.mackichan.com/index.html?techtalk/501.htm~mainFrame|MacKichan Software Inc.]] honlapján látható gondolatot röviden összegzem itt is.

A LaTeX egyik legbonyolultabb része a margók kezelése. Pláne, hogy a beállításait relatív módon kell megadni.

Ahhoz, hogy ezt kényelmesebben lehessen csinálni, hasznos tudni, hogy mik az aktuális beállítások. Ebben próbálok segíteni azzal, hogy röviden leírom a MacKichan Software Inc. honlapján látható gondolatot röviden összegzem itt is.

Nehéz pontosan meghatározni, hogy mekkora méreteket használ a LaTeX a kimenet generálásához, ugyanis az függ a dokumentum típusától, a lapmérettől, attól, hogy egy- vagy kétoldalas és még ki tudja, mi mindentől.

Éppen emiatt a bonyolult függések miatt egy táblázatba összeszedni sem feltétlen használható megoldás.

Viszont erre is van automatikus megoldás, ami a fordítótól kérdezi meg. Egészen pontosan ez a [cci_latex]layout[/cci_latex] csomag. A működés egyszerű: felvesszük a csomagot a [cci_latex]\usepackage{layout}[/cci_latex] preambulumba felvételével, majd a szövegbe beírjuk a [cci_latex]\layout[/cci_latex] parancsot.

Ennek hatására a LaTeX legenerál egy oldalt, amin felsorolja a paraméterek aktuális értékeit, valamint egy ábrát, hogy könnyebben át lehessen látni, hogy pontosan mi mit jelent. Egyszerű, nagyszerű.

Azért a végleges dokumentumból szedjük ki.:D

PdfLatex – eps fájlok kezelése 2. felvonás

Lassan be kell adni a diplomatervet, szóval ideje megírni a hiányzó részeket. Ok, kicsit csalok a dolog kapcsán, hogy én az őszi TDK-mat bővítem ki/írom át diplomatervvé. Ezért még olyan nagyon nem vagyok elkésve.

A korábbi tapasztalatok alapján nekiálltam, hogy először is frissítsek egy keveset a munkakörnyezetemen. Komoly probléma volt a TDK beadás környékén, hogy egy-egy fordítás egy-két percig tartott. Amikor trial and error módon próbálja az ember a hibákat javítani, akkor hasznos, ha ennél gyorsabb.

Némi kutatás, illetve intelligencia után előkerült a probléma: régebben már itt is leírtam, akkor az eps fájlokból generált fájlokat átmásoltam a temp mappába, mondván, ott jó helyük van. A helyzet az, hogy hála ennek a sornak, a későbbi fordításokkor is mindig újra kellett generálni a pdf fájlokat, nem vette észre, hogy megvannak, és nem változtak.

Most kihagytam ezt a kimeneti mappa beállítást, és így már nincs szükség erre az újrafordításra.

Sőt, sikerült még tovább egyszerűsítenem a képbeillesztési folyamatot: nincs szükség a .eps kiterjesztés megadására a \includegraphics{csp} hívásnál – a program megfelelően kitalálja. Az epstopdf csomagra attól még szükség van!

És ami még szebb: lehet definiálni egy alapértelmezett mappát a képek kereséséhez, hogy ne kelljen a „../img/csp” jellegű módon hivatkozni minden egyes képre:

\graphicspath{{../img/}}

Fontos! Az itt megadott útvonal végére kell a “/” jel, ugyanis egyszerű stringkonkatenáció történik a háttérben. El lehet kezdeni keresni a hibát, ha az ember ezt nem tudja.

Hogy muzsikál ez az új rendszer SVNnel párosítva? Majd az idő eldönti. De a gyorsított fordítás sokat ér a trial and error fázisban. 😀

További pdfTeX gyöngyszemek

A múltkor beszéltem arról, hogyan érdemes szerintem [intlink id=”604″ type=”post”]LaTeX szerkesztést végezni OSX-en[/intlink] Eclipse kiterjesztés segítségével. Azóta némi további érdekességet sikerült összeszedni a témáról – és az ötletek szerintem a TeX környezetek többségére alkalmazhatóak.

Egyik alapvető érdekesség, hogy a pdfTeX motor csak a jpg, png és pdf fájlokat támogatja képfájlként. Ez egyfelől jó (lehet), mert bizonyos képek könnyebben elérhetőek ilyen formátumban, másrészt viszont rossz, mert ezek nem szerkeszthetők vektorosan olyan egyszerűen, ha úgy hozná a sors. Ezért lenne jó vagy svg vagy pedig eps támogatás hozzá.

EPS támogatás beizzítása pdfTeX motorhoz

Abban az esetben, ha az ember gépére telepítve van az imageMagick program, annak a convert parancsát ki lehet hívogatni, és ezzel szinte bármilyen formátumból bármilyen formátumot elő lehet állítani. A megoldás nyilvánvaló előnye, hogy hihetetlenül rugalmas, hátránya, hogy igényli a convert parancs jelenlétét a rendszerben – azaz a hordozhatóság csökken. A következő parancs megmutatja, hogy milyen jellegű utasítást kell kiadni a LaTeX preambulumban:

[cc]\DeclareGraphicsRule{.tif}{png}{.png}{`convert #1 `dirname #1`/`basename #1 .tif`.png}[/cc]

A DeclareGraphicsRule parancs során meg kell adni fájlkiterjesztést, amire figyelni kell, egy típust, egy beolvasási fájlkiterjesztést és egy parancsot. Részletek a következő pdf fájlban: http://www.ctan.org/tex-archive/macros/latex/required/graphics/grfguide.pdf

De tegyük fel, hogy eggyel hordozhatóbb megoldást szeretnénk. Itt jöhet szóba az az opció, hogy a legtöbb TeX disztribúció tartalmaz egy epstolatex parancssori alkalmazást – amint a neve is mutatja, ez egyszerűen eps fájlokat konvertál pdf-re. Külön előnye a programnak, hogy van egy package, ami ennek az egyszerűbb felparaméterezését teszi lehetővé. A package a könnyen megjegyezhető epstopdf névre hallgat.

Az alapértelmezett könyvtárstruktúra és az epstopdf parancs elérhetősége esetén mindössze a package-et kell importálni, és működik, némileg komplexebb felállás esetén a megoldás tovább hegeszthető. Én például azt valósítottam meg, hogy vegye figyelembe az img, src és temp mappákat, amikbe dolgozom, és miközben a LaTeX könyvtára az src, az eps-t az img-ből vegye, míg a pdf-et a temp-be dobja. Ezt a következőképpen sikerült elérni:

  1. Először is megadtam a preambulumban a [cci_latex]\epstopdfsetup{outdir=../temp/,verbose}[/cci_latex] parancsot – ez a temp mappába teszi a pdf-et, és a verbose segítségével kicsit részletesebben kifejti a hasfájásait…
  2. És ezután a képek beszúrásánál az [cci_latex]\includegraphics[width=10cm]{../img/csp.eps}[/cci_latex] módon adom meg a képfájlokat.

Ezután már a rendszer megfelelő hegesztés után elkezd működni. Az epstopdf package dokumentációja alapján a package-et rá lehet venni a DeclareGraphicsRule-lal, hogy mégse az eps2pdf-et használja, vagy ne az alapértelmezett paraméterezéssel.

PDF-specifikus beállítások a rendszerben

Ha csak simán pdfTeX-hel lefordítjuk a LaTeX forrásunkat, akkor már egy használható pdf fájlt kapunk – lehet böngészni meg továbbítani. De mi van, ha mi szeretnénk néhány fancy pdf feature-t kihasználni (na, ez szép hunglish lett 🙂 )? Tipikusan olyasmikre gondoltam most, mint az, hogy a pdf metaadatokat töltsük ki, illetve tegyük klikkelhetővé a hivatkozásokat, valamint a pdf megjelenítő számára is tegyük elérhetővé a dokumentum szerkezetét. Nem hangzik túl extrának, de nagyban növelheti az online olvashatóságot (aki kinyomtatja, annak nyilvánvalóan nem számít…)

Na, csapjunk is bele a lecsóba: a hyperref package jelenti a megoldást a problémára. A bekapcsolt állapot mellett automatikusan klikkelhetővé válnak a hivatkozások, és értelmezni fogja a dokumentum szerkezetét. A metaadatokat nem tölti ki azért automatikusan (noha nem lenne rossz 🙂 ). Mindenesetre ezeket a hyperref csomag opcionális paraméterei között lehet megadni, vagy pedig a hypersetup parancs segítségével. Részletek itt: http://andy-roberts.net/misc/latex/pdftutorial.html

Két fontos megjegyzés a hyperref használatával kapcsolatban: egyrészt opcionális paraméterről van ugyan szó, mégis érdemes megadni a fordítót (esetemben pdftex), ugyanis többféleképpen is keletkezhet pdf a kimeneten, és nem lehet ránézésre eldönteni, hogy melyik fog következni. Az előző oldalon szerepelnek a használható fordítók.

A másik: a hyperref csomagot olyan későn importáljuk, amennyire csak tudjuk (gyk. csak azt tegyük utána, amit feltétlenül szükséges), mert ellenkező esetben sok-sok warningot kapunk, hogy bizonyos hivatkozások megkettőződtek, stb. ami nem könnyíti meg a tényleges hibák felderítését. Ha a végére kerül, akkor ez a probléma nem lép fel (de legalábbis kevésbé). Igen, szép dolog a makrónyelv, ott ilyen szép kis függőségek is kialakulhatnak.