LibreOffice: Mi kell a kiadványszerkesztéshez?

Augusztus 8-ig lehet pályázni nagyobb előadásokkal az októberben megrendezésre kerülő párizsi nemzetközi LibreOffice konferenciára. A mellékelt, pályázati anyagként készült előadásvázlat témája, hogy mi kell ahhoz, hogy a LibreOffice-ból nagy tudású és kényelmes kiadványszerkesztő váljon. “LibreOffice: Mi kell a kiadványszerkesztéshez?” bővebben

Magyar nyelvi ellenőrző a LibreOffice-hoz

Elkészült a nyílt forráskódú magyar nyelvi ellenőrző javított, bővített kiadása, ami most már LibreOffice alatt is menti a beállításait. Az új kiadás többek közt figyelmeztet az olyan nagy médiafigyelmet kapott nyelvi és helyesírási hibákra is, mint „áld meg” és „jó kedvel”, vagy „Budapest Liszt Ferenc Nemzetközi Repülőtér”. A kiegészítő az Eszközök» Kiterjesztéskezelő ablak Hozzáadás gombjával telepíthető. Telepítés után indítsuk újra a programot a gyorsindítóból is kilépve. A működést és az újdonságokat tesztdokumentum segítségével is ellenőrizhetjük.

Az első szembetűnő változás (lásd a mellékelt képre kattintva), hogy bővült az ellenőrző beállítófelülete (ami az Eszközök» Beállítások» Nyelvi beállítások» Magyar nyelvi ellenőrzés menüponton keresztül, és az Eszközök» Kiterjesztéskezelő» Lightproof hu_HU kiválasztása, és a megjelenő Beállítások gomb megnyomásával is elérhető). Az egyik legérdekesebb új korrektúrázási lehetőség az ismertebb angolszász mértékegységek átváltásának felkínálása. Az új opciók lehetővé teszik az olyan ellenőrzések kikapcsolását, amelyek a LibreOffice fejlett Graphite betűkészletei, a Linux Libertine G és Biolinum G használata esetén feleslegesek (ilyen az idézőjelek, gondolatjel, három pont, mínuszjel cseréje, ami a betűkészlet szintjén automatikusan végbemegy vagy mehet, bővebben lásd a Kiadványszerkesztés LibreOffice Writer szövegszerkesztővel jegyzetben).

A magyar köznyelvben nehezen értelmezhető (az iskolai tananyag részét nem képező), ezért átváltásra felkínált mértékegységek a Fahrenheit-fok (°F), mérföld, yard, láb, hüvelyk, gallon, pint, font súly („font súlyú” alakban írva). Az átváltást és a felkínált különböző kerekítéseket a Libreoffice CONVERT_ADD és ROUND táblázatkezelő függvényei végzik el, a toldalékolást (pl. „15 mérfölddel” → 24 kilométerrel) pedig a Hunspell program. Érdekességként, a fejlesztés kapcsán a gallon váltószámának pontosítására is sor került a LibreOffice forráskódjában (l. programfolt, az eltérés 0,02% volt). A mértékegységek felismerése alapértelmezett, de a nyelvi ellenőrző Mértékegységek beállításával kikapcsolható. (Hasonló mértékegység-váltó a Microsoft Office-ban is rendelkezésre állt, de az ezt megvalósító, korábban nagy újdonságként beharangozott intelligens címkéket száműzték a Microsoft Office 2010-ből. A helyére szánt, a kijelölt szövegrészek helyi menüjén keresztül elérhető mértékegység-váltó gyakorlatilag el van rejtve a felhasználók elől körülményes használata miatt.)

Az új mondat-ellenőrzési szabályok számos durva helyesírási hiba felismerésében segítenek: ilyen hibák a „halott róla”, „el kellet mennie”, hord el az irhád!, küzd vissza magad!, vagy a köztársasági elnök újévi köszöntőjének hivatalos átiratából elhíresült tévesztések, „Isten, áld meg a magyart! Jó kedvel, bőséggel!”. (A Himnusz sorai helyesen: „Isten, áldd meg a magyart / Jó kedvvel, bőséggel”!)

A ferihegyi Liszt Ferenc nemzetközi repülőtér jogszabályban rögzített neve, a Budapest Liszt Ferenc Nemzetközi Repülőtér több hibát is tartalmaz: a repülőterek nevének köznévi tagjait kisbetűvel írjuk (AkH. 190.), a helység- és helynevet tartalmazó felsorolásokat pedig vesszővel választjuk el (AkH. 298.): Budapest, Liszt Ferenc nemzetközi repülőtér, vagy Liszt Ferenc nemzetközi repülőtér, Budapest. A Földrajzinév-bizottság elvetette a magyartalan, illetve helyesírási hibás nevet, földrajzi helyesírási hibaként kiemelve még a Ferihegy védett földrajzi név elhagyását (ami jelenleg is érvényes földrajzi név, Budapest egyik városrésze), helyette a kormány javaslatát maximálisan tiszteletben tartva a Liszt Ferenc Nemzetközi Repülőtér, Budapest–Ferihegy elnevezést javasolta. A megfelelő indoklást is tartalmazó határozat azonban nem készülhetett el, mert a bizottság több tagját, köztük az elnököt felmentették, többeket elbocsátottak a munkahelyükről, köztük Mikesy Gábor nyelvészt, az OSOR.eu-n is szereplő Vingis szabad szoftveres állami térinformatikai rendszer egyik fejlesztőjét. A két hivatalos magyarázat szerint azért, mert a minisztériumoktól delegált bizottsági tagok nem kérték ki a tárcák véleményét, vagy azért, mert nem támogatták a „kormány kinyilvánított és egyértelmű kérését”. (Azóta az elbocsátott munkatársak helyzete valamelyest rendeződött, l. Dutkó Andrással, a bizottság volt elnökével készült interjút, ami a bizottságot ért támadásokra is reagál.) A Földrajzinév-bizottság jogkörét külön kormányrendeletben korlátozták, hogy „kiemelt közérdek” esetén a magyar nyelv védelme másodlagos szempont lehessen. A rendelet egyben felmentette a bizottság tagjait, illetve minimalizálta a leendő új tagság létszámát is. Az abszurd ügy hátterét jól megvilágítja a Térinformatika-online cikke, amihez csak annyit lehet hozzátenni, hogy mi okozta az eredeti hibás javaslatot: a kormánypárti javaslattevők a jogszabályokban szereplő „Budapest Ferihegy Nemzetközi Repülőtér” névben a Budapest Ferihegyet (a repülőtér nemzetközi nevét) „Budapest Liszt Ferenccel” helyettesítették. A Földrajzinév-bizottság sárba tiprásával megszületett törvény a joganyagban szereplő különböző meghatározásokat, köztük a „Budapest (Ferihegy)”, „Ferihegy”, „Ferihegyi repülőtér”, „Ferihegyi nemzetközi kereskedelmi repülőtér” elnevezéseket egységesen az új, a bizottság által 20:1 arányban leszavazott névre cserélte le. A magyar nyelvi ellenőrző a „Liszt Ferenc nemzetközi repülőtér”, „ferihegyi Liszt Ferenc nemzetközi repülőtér”, „Ferihegy”, valamint a „Budapest, Liszt Ferenc nemzetközi repülőtér” elnevezések használatát javasolja a nyelvi szakértők által egyöntetűen elutasított hibás megnevezés helyett.

A magyar nyelvi ellenőrző mögött álló Lightproof keretrendszert afrikaans, arab, francia (Grammalecte) és orosz nyelvi ellenőrzők készítésénél is felhasználták. A keretrendszer és a magyar nyelvi ellenőrző modul fejlesztése az FSF.hu Alapítvány támogatásával valósult meg.

LibreOffice 3.3.3 és 3.4.1 Portable

Ahogy korábban már megszokhattuk (pl itt és itt) a TDF elkészítette a legújabb LibreOffice kiadásokból a hordozható (portable) változatait.

A portable változat teljes értékű LibreOffice, mely ezúttal mindkét verzióból 2-2  változatban lesz letölthető.

A standard (a kisebbik) változat tartalmazza a kínai (tradicionális és egyszerűsített), holland, angol, francia, német, magyar, olasz, japán, koreai, lengyel, portugál (portugáliai és brazil), orosz és spanyol nyelveket.

Az All language változat tartalmazza mind az 57 nyelvet, melyet a LibreOffice támogat.

A telepítés során lehetőség van – gyakorlott felhasználóknak – a nem kívánt nyelvek, szótárak, sablonok eltávolítására. Előfordulhat, hogy az eltávolításra az első induláskor kerül sor.

Mind a két változat (3.3.3 és 3.4.1) elérhető itt.

Esettanulmány: elválasztás beállítása, furcsa elválasztási hibák javítása

A LibreOffice kiváló automatikus elválasztással rendelkezik, legalábbis a Microsoft Office-hoz képest, amely nem tudja elválasztani a helyesírási szótára általa nem ismert, de amúgy helyes magyar szavakat. (Ezekből pedig sok van, ráadásul éppen a kritikus hosszú szavak, mint például agykamratágulat, fagylaltporgyártó, kakaóbabméret. Gyakorlatilag minden olyan többszörösen összetett szót, amit a helyesírás-ellenőrzője nem tud felbontani két szótári szóra, hibásnak jelez a Microsoft Word, és nem is választja el). A LibreOffice elválasztása minta alapú, ami megbirkózik a helyesírástól függetlenül minden szóval. (Még ha nem is mindig tökéletesen, például a minták még nem lettek felkészítve a vörösiszap szó elválasztására, ezért a hibás vörö-siszap kézi javításra szorul a később ismertetett módok valamelyikével.) Az automatikus elválasztás beállításához kattintsunk a szövegre a másodlagos egérgombbal, majd válasszuk ki a Bekezdés stílusának szerkesztése… menüpontot. A megjelenő beállítóablakban kattintsunk a Szövegbeosztás fülre, majd jelöljük be az Automatikusan jelölőnégyzetet. Ezzel minden ilyen stílusú bekezdésben beállítottuk az elválasztást.

A napokban egy újabb magyar vonatkozású elválasztási hibára derült fény a LibreOffice-ban (a másik a Graphite ligatúrák gyakran egalizálási hibával járó elválasztása, amivel bővebben foglalkozik a Kiadványszerkesztés LibreOffice Writer szövegszerkesztővel jegyzet): Ha a mondatkezdő „Összefoglalásként” szót az első, speciális elválasztást igénylő helyen választja el a LibreOffice, az „ÖSz-szefoglalásként” elválasztást kapjuk (tehát a szó második betűje is nagy lesz). A programhibát javító egysoros folt elkészült a LibreOffice-hoz, de hogyan kerülhetjük el az ilyen és hasonló (akár a minta alapú elválasztás említett tévedéseiként adódó) elválasztási hibákat szövegszerkesztés közben? Az egyedi (Ctrl-mínusz vagy Beszúrás » Formázási jel » Opcionális elválasztójel) és a kivételszótári elválasztásnál sajnos az Ösz-sze típusú speciális elválasztások nem adhatók meg (legfeljebb az utóbbival letiltható a hibás elválasztás, pl. az „Össze=fog=la=lás=ként” minta megadásával, l. Formátum » Beállítások » Nyelvi beállítások » Írástámogatás » Egyéni szótárak/Szerkesztés). Gyors, de sérülékeny megoldás, ha „Öszszefoglalásként”-ra vagy „Ösz-szefoglalásként”-ra írjuk át az elválasztott szót, amivel már helyes elválasztást kapunk. Hátránya, amint az sok napilap esetében megfigyelhető, hogy az elválasztás helyének megváltozása esetén a szándékosan hibásan írt szó felismerhetővé válik (a napilapoknál ez jelzi, hogy tördelőprogramjuk nem támogatja a magyar kettőzött többjegyű mássalhangzók elválasztását).
Jobb megoldás, ha csekély mértékben változtatunk a dokumentum, vagy az adott bekezdés tipográfiáján, hogy az elválasztás más helyre kerüljön: ha nem számít, akkor pár mm-rel növeljük vagy csökkentsük a laptükör szélességét, vagy módosítsuk az adott bekezdésben, hogy mennyi betű maradjon minimum az elválasztásnál a sor végén, illetve elején. Sőt, ami még szebb eredményhez vezethet, a LibreOffice-ban az ügyesebb kiadványszerkesztők vagy a modern TeX szedőrendszerek trükkjeit is használhatjuk erre a célra, igaz, kézzel beállítva: a karakterbeállítások Pozíció lapján 1-2 százalékkal szélesíthetjük vagy keskenyíthetjük a betűket, és egy tized ponttal a betűk közötti távolságot. Ezzel nemcsak elválasztási, hanem tipográfiai hibákat is javíthatunk (túl nagy szóközök sorkizárt szedésnél), feltéve, ha megmaradunk ezeknél a minimális, kevésbé feltűnő betűtorzítást és betűritkulást okozó értékeknél. Ennél már csak az lehetne kényelmesebb, ha a próbálkozásokat a LibreOffice kérésre automatikusan is elvégezné, hasonlóan egy-két DTP programhoz. Köztes megoldásként pedig már egy kényelmesebben hozzáférhető kezelőfelület is bőven megfelelne, például a tipográfiai eszköztár bővítése a jelenleg csak a Betűbűvész eszköztáron megtalálható, az alapszövegre nem használható betűköz-beállító ikonokkal.

Új Linux Libertine és Biolinum betűk

LibreOffice logó A Németh László-féle Linux Biolinum G és Libertine G betűcsalád alapját képező Libertine Open Fonts projekt új betűket is tartalmazó verzióval (5.1.3) jelentkezett. A TTF és OTF típuson túl elérhető még SVG és WOFF formátumban is. Természetesen a betűk FontForge forrása is szabadon elérhető és a GPL-nek megfelelően módosítható.

Újdonságokból

  • hibajavítások, ligatúrák pótlása,
  • a Linux Biolinum betűk árnyékolt (shadow) változatának megjelenése,
  • díszes Linux Libertine iniciálék  (magyar ékezetek egyelőre hiányoznak),
  • Biolinum Keyboard betűben megjelent a két-, és háromgombos „egér”.

A változások részletes listája itt érhető el, a betűk a SourceForge oldaláról.

LibreOffice 3.3.3

LibreOffice logó Megjelent a LibreOffice 3.3.3. Thorsten Behrens – fejlesztő és a TDF Steering Committee tagja – így fogalmazott: „A LibreOffice 3.3.3-ban sok hibát javítottunk, a programcsomag biztonságosabb lett. Ezzel a kiadással elsősorban az intézményi felhasználók igényét elégítjük ki, akiknek a stabilitás fontosabb, mint az új funkciók. A 3.3-as ág az év végéig lesz karbantartva, ezzel biztosítjuk a zökkenőmentes és biztonságos átállást a LibreOffice 3.4.x sorozatra.”

A változások részletes listáját a NEWS fájl tartalmazza. A LibreOffice 3.3.2 felhasználóinak ajánlott a frissítés.

Vajna Miklós: GSoC 2011 napló

Vajna Miklóst aligha hiszem, hogy be kellene mutatni a LibO-t nyomon követőknek. A tavalyi és az idei GSoC-on is hekkelő magyar fiatalember ezúttal – naponta frissülő – naplójában írja meg az idei GSoC keretében elvégzett munka „dokumentációját” (és hátterét).

LibreOffice 3.4 rc2

LibreOffice logó Május 27-én megjelent a LibreOffice következő – újdonságokat és hibajavításokat tartalmazó – kiadásának második rc-je. Ha semmi nem jön közbe, ez a build fog megjelenni szerdán végleges LibreOffice 3.4.0-ként.

Elérhető a szokásos platformokra:

http://www.libreoffice.org/download/pre-releases/

A hibajavítások listája itt, változások listája itt.

Bemutatkozik az Engineering Steering Committee

A Document Foundation bejelentette az Engineering Steering Committee megalakulását. Ez a bizottság koordinálja a LibreOffice fejlesztési munkálatait, és határozza meg a LibreOffice további fejlesztésének irányát.

Bemutatjuk az Engineering Steering Committee tagjait – a Membership Committee után ez a második bizottság, amely az alapítvány saját belső szabályzata alapján megalakult. Az Engineering Steering Committee 2011 elején kezdte meg a működést, de mostantól ez hivatalos. Az Engineering Steering Committee 10 tagból áll.

  • Rainer Bielefeld – QA (független)
  • René Engelhard (Debian)
  • Caolán McNamara (Red Hat)
  • Michael Meeks (SUSE/Novell/Attachmate)
  • Bjoern Michaelsen (Canonical)
  • Petr Mladek (SUSE/Novell/Attachmate)
  • Michael Natterer (Lanedo)
  • David Tardon (Red Hat)
  • Norbert Thiebaud (független)
  • Tímár András – honosítás (SUSE/Novell/Attachmate)

Az Enginering Steering Committee hetente ülésezik, telefonkonferencián beszélik meg a kiadási dátumokkal kapcsolatos kérdéseket és a fejlesztési teendőket. A telefonkonferenciákra rendszeresen meghívnak más aktív, érdeklődő fejlesztőket, illetve egy adott téma szakértőit.

A tagokat a Steering Committee jelölte ki. A 2010 szeptembere óta folyamatosan növekvő, és jelenleg közel 200 kódfejlesztő és 200 honosító és tesztelő tagot számláló fejlesztői közösség kulcsemberei kerültek ebbe a pozícióba. „Ez fantasztikus siker,” – nyilatkozta Caolán McNamara (Red Hat), – „különösen ha az OpenOffice.org projektet nézzük, ahol a külső hozzájárulók kis csoportot alkottak, és jelentős nehézségeket kellett nap mint nap leküzdeniük.”

Körülbelül 120 fejlesztő járul hozzá rendszeresen a LibreOffice kódjához. Ezek három csoportra oszthatók. 20 főfejlesztő dolgozik az új funkciókon, hibajavításokon és a csomagkészítésen. 40 rendszeres hozzájáruló dolgozik az új funkciókon, hibajavításokon és az úgynevezett „easy hacks” feladatokon. 60 hozzájáruló küld be kevésbé rendszeresen megoldásokat az „easy hacks” feladatokra és dolgozik a kód tisztításán. Rajtuk kívül kb. 80 fejlesztő küld be kódot alkalomszerűen, vagy éppen ismerkedik a rendszerrel. Nagyon hálásak vagyunk az egyetemistáknak is, akik a Google Summer of Code keretében fizetett munkát fognak végezni ezen a nyáron a LibreOffice projektben.

„Az Engineering Steering Committee feladata, hogy rendet tartson a fejlesztésben. Azonban ennek a bizottságnak teljesen más a felépítése, mint ami az OpenOffice.org projektben volt. Ott egyetlen vállalat volt felelős minden döntésért, és bár ennek előnye volt a könnyebb koordinálhatóság, a hátránya azonnal nyilvánvalóvá vált a fő szponzor kiesésével.” – mondta André Schnabel, a TDF Steering Committee tagja. „Mi olyan folyamatokat alakítottunk ki, amelyekben a vállalati szponzorok képviselhetik érdekeiket, de a közösség életképes marad bármelyikük kiesésével is. Nincs egyetlen főszponzor, akinek kilépése veszélybe sodorná a projekt jövőjét.”

A LibreOffice kiadási politikája

LibreOffice logó A LibreOffice 3.4 kiadásának közeledte miatt a Document Foundation kiadott egy közleményt a LibreOffice kiadási politikájáról. Ebben több mindenről szó van, de a legfontosabb üzenet az alábbi.

A LibreOffice az idő alapú kiadási modell mellett kötelezte el magát. Ez azt jelenti, hogy a megjelenések dátuma előre rögzített, és a fejlesztőcsapat mindent megtesz, hogy a kiadás az adott napra elkészüljön. Napjainkban a legtöbb szabad szoftveres projekt, például a GNOME, a KDE vagy sok Linux-disztribúció, szintén az idő alapú kiadási modellben dolgozik. Ennek több előnye van. Az egyik a kiszámíthatóság. A felhasználók tudják időzíteni az áttérést. A Linux-disztribúciók csomagolói tudják, mikor számíthatnak a megjelenésre. A másik előny, hogy ha szorít a határidő, a fejlesztők teljesítménye megnő. A kiadás előtti napokban mindenki teljes erőbedobással dolgozik a hibák javításán. A „kiadjuk, amikor elkészül” kiadási modellben sokszor vég nélkül húzódik ez a folyamat, mindig találnak még egy hibát, mindig előkerül még egy érdekes funkció, amit be kellene tenni a kiadásba stb.

Az OpenOffice.org is az idő alapú kiadási modellel dolgozott. Azonban nem vitték végig következetesen az elvet, sokszor heteket, hónapokat csúszott a kiadás az előre kihirdetett dátumhoz képest. Ennek az volt oka, hogy az OpenOffice.org ritkábban jelentkezett javítókiadásokkal, ezért az első .0-s kiadást akarta egyből jóra megcsinálni.

A LibreOffice ezzel ellentétben felvállalja, hogy a .0-s verzió nem lesz tökéletes (de időben kijön!). Lehet, hogy lesznek benne ismert hibák, ezeket a kiadási megjegyzésekben közlik. Az viszont biztos, hogy lesznek benne ismeretlen hibák is, amelyeket a kiadás után fognak észrevenni a felhasználók. A javítókiadások havonta fogják követni egymást. Míg a .0-s verzió az érdeklődőknek, gyakorlott felhasználóknak ajánlott leginkább, akik kíváncsiak az új funkciókra, a .1-es, de főleg a .2-es verzió már alkalmas tömeges intézményi bevezetésre, produktív környezetben való használatra is. A .3-as és azt követő verziók pedig az „atomstabil” jelzőt érdemelik ki. 🙂 A LibreOffice 3 hónap alatt 3 verziót ad ki, mindegyik kiadás előtt felfokozott hibajavítási tevékenységgel. Mire az OpenOffice.org 3.4 megjelenik – ha egyáltalán megjelenik – a LibreOffice 3.4.2 már sokkal jobb állapotban lesz, ami a javított hibák számát illeti.

A levelezőlistákon és a fórumokon sokan értetlenkedtek a fenti kiadási politikán. Többek között nem értették, hogy a .0-s verziót miért nem nevezik inkább bétának, ha nem ajánlott intézményi felhasználásra. Ezek az emberek elfelejtik, hogy intézményeknél minden valamire való rendszergazda eddig is kivárta minden szoftverből az első vagy második javítókiadást a tömeges bevezetés előtt, ez a gyakorlat nem változik. A felhasználók kockázatviselési hajlandóságuknak és igényeiknek megfelelően választhatnak a kiadások közül. A legkonzervatívabb felhasználók a .2-es vagy későbbi kiadást telepítik, ez stabil, de esetleg ezzel egy időben kijön már egy új verzió is, új funkciókkal. A skála másik végén azok a tesztelők és fejlesztők vannak, akik a napi buildeket telepítik és használják, akár az összeomlást vagy az adatvesztést is kockáztatva. A két véglet között mindenki el tudja dönteni, hogy a stabilitás és az új funkciók milyen arányára van szüksége, melyik ponton lépi meg a verzióváltást.