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

Resource fájlok eclipse plugin extension-ben

Aki fejlesztett már Eclipse PDE felett, az talán találkozott a lehetőséggel, hogy egy extension point tulajdonság típusa lehet “resource” is. Ez annyit tesz, hogy a kiterjesztésben megadhatunk egy, a plugin-nel csomagolt fájlt. De a másik oldalon, az extension point beolvasásakor hogyan is olvassuk ezt be? Hiszen fogalmunk sincs honnan jött, melyik plugin adja az extension-t, és hol keressük a fájlt. A megoldás nem triviális, és kell egy kis kutatást végezni, hogy rájöjjünk. Én ezt megtettem, és igyekszem közérthető formában továbbadni.

Aki fejlesztett már Eclipse PDE felett, az talán találkozott a lehetőséggel, hogy egy extension point tulajdonság típusa lehet “resource” is. Ez annyit tesz, hogy a kiterjesztésben megadhatunk egy, a plugin-nel csomagolt fájlt. De a másik oldalon, az extension point beolvasásakor hogyan is olvassuk ezt be? Hiszen fogalmunk sincs honnan jött, melyik plugin adja az extension-t, és hol keressük a fájlt. A megoldás nem triviális, és kell egy kis kutatást végezni, hogy rájöjjünk. Én ezt megtettem, és igyekszem közérthető formában továbbadni.

A probléma, kicsit formálisabban: adott egy extension point, melyen egyik attributúma resource típusú. Mikor egy plugin extension-t csatol ehhez a ponthoz, az adott attríbutúmnak úgy ad értéket, hogy a programozó kiválaszt egy fájlt, amit a pluginnel együtt csomagolva ad. Az extension point-ot adó plugin pedig az ilyen módon regisztrált fájlokat szeretné beolvasni.

Amikor beolvassuk ezt az értéket az extension-ből, a fájl relatív elérési útvonalát kapjuk meg a plugin csomagjában. Első feladatunk tehát, megtalálni a plugin csomagot ([[http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html|Bundle]]), ahonnan az extension jött, hiszen abban kell keresni a fájlt is. Ha megvan a csomag, kérhetünk tőle egy URL-t a fájlhoz. A kapott URL azonban nem szokványos, “bundleresource:” előtaggal rendelkezik. Korábban létezett egy asLocalUrl() függvény, ami az ilyen jellegű URL-t hivatott átalakítani abszolút “file:” URL-é. Azonban ez a függvény a 3.2-es verzióban @Deprecated megjegyzést kapott, tehát ez nem a megfelelő mód a megnyitásra. Szerencsére azonban az ilyen URL-ekhez implementálták az URL.openStream() metódust, ami nyit egy megfelelő adatfolyamot a számunkra. Kicsit egyszerűsítve a kód valahogy így néz ki:


//Listázzuk az extension point-hoz csatolt extension-öket:
IExtensionRegistry registry = Platform.getExtensionRegistry();
IExtensionPoint point = registry.getExtensionPoint("ExtensionPointID");
for (IExtension extension : point.getExtensions()){
//Így kell lekérni az extension-t adó plugin csomagot:
Bundle bundle = Platform.getBundle(extension.getNamespaceIdentifier());
for (IConfigurationElement element : extension.getConfigurationElements()){
//A csomagon belüli relatív elérési út:
String path = element.getAtribute("resourceAttrib");
URL url = bundle.getResource(path);
InputStream is = url.openStream();
//...Olvasás...
}
}

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. 😀

Projektbemutató videóval

Úgy néz ki, egyelőre Balage Debug Visualisation projektje még fut egy darabig, nem ért véget azzal, hogy megkapta rá a jegyét. Nemrég volt egy újabb release, most pedig én egy régi ígéretemnek tettem eleget, és készítettem hozzá egy bemutató videót.

A videó nagyon egyszerű: megmutatom, hogy egy komplex debug eljárás esetén (hiszen egy másik Eclipse példányban futtatott plugin projektet tesztelek vele) hogyan használható ez a plugin.

Mindenesetre jöjjön a lényeg:

Úgy néz ki, egyelőre Balage Debug Visualisation projektje még fut egy darabig, nem ért véget azzal, hogy megkapta rá a jegyét. Nemrég volt egy újabb release, most pedig én egy régi ígéretemnek tettem eleget, és készítettem hozzá egy bemutató videót.

A videó nagyon egyszerű: megmutatom, hogy egy komplex debug eljárás esetén (hiszen egy másik Eclipse példányban futtatott plugin projektet tesztelek vele) hogyan használható ez a plugin.

Mindenesetre jöjjön a lényeg:

Megfelelő igény esetén esetleg arról is fogok beszélni, hogy hogyan készült a videó – most csak annyit mondanék róla, hogy teljesen nyílt szoftverek felhasználásával készült – eltekintve a youtube felületén hozzáadott annotációktól.

Ami viszont vicces volt, hogy feltölteni macerás: a fájl lassan töltődik fel, és időnként megszakadt közben a net – ebben az esetben pedig az AJAX-os feltöltő script végtelen ciklusba került, és nem töltött fel semmit, de nem is vette észre, hogy vége a dalnak. Talán majd egyszer ezt is javítják (vagy nekem javul meg a netem 😀 ).

Eclipse update site az oldalon

Aki figyelemmel kisérte a nem rég [[Debug vizualizáció Eclipse-hez|bejelentett]] projektet, az már tudhat róla, hogy pár hónapja működik egy eclipse update site a honlapon. Az említett projekt [[http://code.google.com/p/debugvisualisation/|honlapján]] egy ideje már bejelentettük a létezését, de az itteni kihirdetés idő és kedv hiányában késett egy kicsit.

Tehát a lényeg: az eclipse menüben Help/Software Updates../Available Software/Add Site..: http://eclipse.cubussapiens.hu

Aki figyelemmel kisérte a nem rég [[Debug vizualizáció Eclipse-hez|bejelentett]] projektet, az már tudhat róla, hogy pár hónapja működik egy eclipse update site a honlapon. Az említett projekt [[http://code.google.com/p/debugvisualisation/|honlapján]] egy ideje már bejelentettük a létezését, de az itteni kihirdetés idő és kedv hiányában késett egy kicsit.

Tehát a lényeg: az eclipse menüben Help/Software Updates../Available Software/Add Site..: http://eclipse.cubussapiens.hu

Jelenleg egyetlen feature található rajta, de ahogy az időnk engedi, ez a kör bővülhet. Addig is használjátok egészséggel ezt az egyet, és nyugodtan küldjetek hibajelzést/kivánságot a projekt oldalára.