Azonban mit is jelent mindez a Linux-felhasználók számára? Semmit! Ha ez akkora mérföldkő a fejlesztésben, akkor vajon miért nem vesznek ebből semmit sem észre a Linux-felhasználók? Azért, mert a Linux-disztribúciók 2006 óta élvezhetik a GStreamer-támogatást, amelyet a Novell alkalmazásában dolgozó Radek Doulík készített, és amit később, a RedHat szupersztárja, Caolán McNamara látott el javításokkal.

Az igazi kérdés azonban az: miért hívja fel magára a StarDivision a figyelmet egy funkció elkészítésével kapcsolatban, amellyel több, mint 4 évet késett, miközben tovább folytatja a közösségi fejlesztők elidegenítését a projekttől?

Lekésni a bulit

A GStreamer a jelentős vállalati befektetések ellenére sok kézben van, és szemmel láthatóan a hagyományos nyílt forrású szoftverfejlesztési modellt követi.

Annak ellenére, hogy nyilvánvaló volt, hogy a GStreamer a megfelelő háttérrendszer, a StarDivision fogta magát, és elment mellette, és úgy döntött, hogy a JMF-et támogatja. Bár mára elismerik, hogy ez nem volt a megfelelő választás. De mégis, hogyan történt ez?

• 2004. augusztus: a StarDivision elkészítette a Java Media Framework (JMF) támogatást a Solarishoz és a Linuxoz. Ezzel egy időben bejelentették, hogy DirectX-támogatást is készítenek, ami nagyszerű, de ezzel a Linux másodrendű platformmá degradálódott.
• 2004. november: észrevették, hogy ez a megoldás nem lesz megfelelő a Linuxok számára, és figyelmen kívül hagyva Michael Meeks GStreamerre vonatkozó javaslatait, elkezdték a Xine támogatását előkészíteni. Ez valóban jó próbálkozás volt, azonban a Xine használata ütközött a GPL-licenceléssel. Ezidőtájt a StarDivisiont elkezdték bírálni, hogy nem a Javat választja, mivel annak használata házon belül technikailag nyilván egyszerűbb lett volna.
• 2005. február: világos lett, hogy nincs minden rendben. Ekkor születtek javaslatok a Xine és az MPlayer kapcsán, de GStreamer még mindig nem volt sehol.
• 2005. április: Ebben az időben a Helix fejlesztői küldtek be kódot, amit orvosolná ezt a problémát, de ez sosem került be a fejlesztői fába.
• 2006. Radek beküldte a GStreamer támogatás első részét, és hamarosan sikerült kiadni valamit, ami valóban működött is. A Linux-disztribúciók rendkívül gyorsan elkészítették az ooo-build (go-oo) fejlesztői ágból kivett GStreamer-támogatás implementációit. Ez azt jelentette, hogy lehetett egy prezentációban pl. ogg fájlokat lejátszani. Ekkor igazából egy beégetett GStreamer-implementáció készült el, nem pedig egy háttérrendszer kiválasztására alkalmas keretrendszer.
• 2006-2010. Négy éven keresztül a Novell fejlesztői azt javasolták a StarDivisionnek, hogy vegye át a GStreamer-támogatást a go-oo projekt által javasolt LGPLv3 licenc használatával, vagy átruházott szerző joggal (amit a go-oo projekt kevésbé szeretett volna).
• 2010. július:A StarDivision bejelentette, hogy újraírta a kódot.

Hibás érvelés minőséggel kapcsolatban

Egyesek úgy próbálnak érvelni ugyanannak a forráskódnak egy másik, többletfunkciókat tartalmazó ága ellen, hogy a nagybetűs Minőségre hivatkoznak. Nyilván ezt, a csak egy irányban alkalmazható érvelést kell alkalmazniuk, mert különben saját magukat is támadnák. Az ooo-build természetéből adódóan több funkcióval (és hibajavítással) rendelkezik, mint az eredeti fejlesztési ág. Az az érvelés azonban nem túl jó az olyan funkciók esetében, mint a médialejátszás, hiszen a GStreamer-integráció rendkívül stabil (legalábbis bejelentett hiba nincs vele kapcsolatban). De vajon valóban jobb lesz-e a termék minősége, ha nincs médialejátszás a termékben? Tényleg sokkal jobb, hogy nincs semmi, mintha lenne valami?

A minőségre történő hivatkozás másik típusa hasonló célt szolgál, és azt sugallja, hogy az ooo-build hibajavításai borzalmas minőségűek. Ehhez többnyire hozzáfűzik, hogy mindez azért fordulhat elő, mert nincs egy megfelelően lassú és bonyolult minőség-ellenőrző folyamat. És természetesen ott van a hatalmas FUD, amit a programozni nem tudó közösségi emberek terjesztenek, miszerint a kód annyira bonyolult, hogy csak az eredeti fejlesztő tud hozzányúlni.

Természetesen érdekesek az érvelések, de vajon egy kód, ha valóban jó minőségű, akkor miért csak az eredeti programozó tud hozzányúlni? (Mellesleg a kód felülvizsgálata és gondozása hosszabb távon sokkal értékesebb, mint a fekete dobozos tesztelés.) A kód valóban bonyolult tud lenni, de közel sem módosíthatatlan. A FUD-háború közepette azonban sosem jelent még meg egyetlen olyan mérőszámokon alapuló, tényszerű elemzés, amely szerint a hibajavítások valóban rosszak, ez csupán feltételezés.

Természetesen a go-oo fejlesztői sokkal több hibát javítanak, mint amennyit beletesznek a rendszerbe és ezeket a javításokat rendszeresen el is küldik a fő fejlesztői ágba. Ugyanakkor nem mindig olyan könnyű felismerni, hogy mi számít jó kódnak. Úgy látszik ez attól függ, hogy melyik cég írja a kódot, hiszen ha StarDivision tulajdona a kód, akkor az jó minőségű, ha pedig nem, akkor ugyanaz a kód rossz minőségű.

Közösség növekedése

Természetesen ugyanazt a kódot titokban megírni, majd bejelenteni annak elkészültét, nem éppen a fejlesztési közösség épülését szolgálja. Milyen érzés lehet úgy dolgozni a egy fejlesztési projektben, hogy a valószínűleg az általam írt kódot újra fogják írni? Így talán mondani sem kell, hogy a GStreamer újraírása nem az a fajta reklám, amelyre szükség van ahhoz, hogy embereket csatlakozzanak a fejlesztői közösséghez. Ha egy kódon titokban dolgoznak, majd rádobják magasról a közösségre, akkor nem nagyon lehet arra számítani, hogy valaki belenéz, szakértő szemmel értékeli azt, vagy esetleg  a későbbiekben dolgozik rajta. Ez az irány nem egy nyílt és befogadó OpenOffice.org projekt fele vezet.

Sokkal szórakoztatóbb, hogy van egyfajta titkos szövetség a fejlesztésben részt nem vevő üzleti partnerek részvételével, akik stratégiai tanácsot adnak a StarDivision vezetőinek. Érdekes stratégia, hogy ezeket a cégeket ruházzák fel a döntéshozatalra, és nem azokat, akik részt vesznek a fejlesztésben. Ugyancsak érdekes, hogy az új GStreamer-támogatás egyetlen rejtett kódtömb, ahol a tíz forrásmodul fájlneve történetesen az ooo-build ágban lévőével megegyezik, miközben teljesen eltér a windowsos vagy a xine megoldástól. Valószínűleg mindez a véletlen játéka.

De kicsoda?

A többször StarDivision néven említett szervezet annak ellenére, hogy más és más cégek tulajdonolták, általában külön szervezeti egységként működött. Az Oracle felvásárlása azonban csak most záródott le teljes mértékben, mégis egyszerűbb StarDivisionként hivatkozni rájuk. Enyhén szólva szégyen, hogy azt a jó nyílt forrású fejlesztési gyakorlatot és tapasztalatot, ami Sun felvásárlása révén az Oracle háza tájára került, sosem tudták ebben a szervezeti egységben hatékonyan bevezetni.

Az OpenOffice.org magasra teszi a mércét a szoftverkorlátozások innovációjában: a StarDivision nem csak birtokolni akarja a beérkezett kódot, de azt kizárólagosan akarja birtokolni.

Üzleti modell

Nyílván komolyabb üzleti érdekek állhatnak az egész mögött, mint ami látszik. Nem is biztos, hogy üzleti szempontból, információ hiányában megfelelően értékelni lehet a helyzetet, de talán elemezhető, hogy mik az előnyei és hátrányai a belső fejlesztésnek a szabad licencű fejlesztéssel szemben:

A meglévő kód elfogadásának és használatának előnyei:

• nem kerül semmibe,
• a StarDivision fenn tudja tartani jelenlegi szerződéseit és el tud adni újakat,
• a közösség nem darabolódik szét,
• a fejlesztők a munkájukra tudnak koncentrálni,
• nincs az a látszat, hogy az erőforrások pazarlása folyik.

A kód újraírásának előnyei:

• Kizárólagos kódtulajdonlás: bárki, akinek szüksége van e kis kódrészlet jogaira, csak hozzánk fordulhat, nincs szabadon licencelt alternatíva.
• Macsó magatartás: verjük meg a szemüveges gyereket, hadd tudja, hol a helye!
• Más nem jut eszembe…

Ez nem azt jelenti, hogy a StarDivision vezetése aktívan rosszindulatú, sőt ők biztosan rendkívül értelmesek, ezért valószínű, hogy rengeteg előnye vannak annak, hogy a kódot újraírták. Léteznie kell értelmes oknak, de vajon mi az? Valóban megéri a fejlesztési előforrások szétforgácsolása és elfecsérlése, a meglévő, tesztelt és működő kód újraírása és a közreműködők elküldése csak azért, hogy biztosítva legyen a StarDivision tulajdonjoga? Ez valóban a nyíltságot jelenti? Mennyire valószínű, hogy a külső fejlesztők fogják újraírni és kijavítani az OpenOffice.org kódbázisának nagy részét a következő évtizedben csak azért, hogy hígítsák a StarDivision kizárólagos tulajdonrészét?

Ez nem egy kompetitív anyagnak készült, nem arról van szó, hogy mondjuk a Novell Edition évekkel a StarDivision fejlesztői előtt jár, de az bizonyos, hogy a legjobb szoftverek akkor készülnek, ha mindenki összefog, és a különböző cégeken belül dolgozó fejlesztők együttműködnek, hogy mindenki számára egy jobb OpenOffice.org készülhessen.

Összegzés

Igazából nem hír, hogy a StarDivision újraírt egy, a közösség által fejlesztett kódrészletet, amelyet majd 6 hónap múlva fog megjelentetni, az OOo 3.4-ben. A hír azonban rámutat egy zárt, titkos és haszontalan fejlesztési folyamatra. Természetesen ilyen jellegű, semmit mondó hírek továbbra is várhatók, ha a vezetés elveszti a hitét a közösségben, és inkább az erőforráspazarlást támogatja a közös munkával szemben. Ebben az esetben a következő lépés elég egyértelmű: még több erőforráspazarlás fog történni.

Sajnálatos módon ennek mellékhatása, hogy a fejlesztési tennivalók egyre sokasodnak és újabb falakat húz azok közé, akiknek érdeke a kódbázis jobbá tétele. Az OpenOffice.org csak erősödhet, ha az összes közreműködő együtt dolgozik. A közös munka alatt pedig az átlátható, tisztességes szabályok által meghatározott közreműködést kell érteni, nem pedig a hátsó szobákban zajló titkos megállapodások kuszaságát. Nehéz optimistának lenni a StarDivision jövőjével kapcsolatban, pedig éppen most kezdik komolyabban venni a Linux-integrációt, ami alapvetően igenis jó dolog.

Valamilyen szinten szomorú látni olyan 2500 sor kód újraírását, amelyet nem kellett volna újraírni. Jelenleg az ooo-build 673 ezer sornyi patchet tartalmaz, így ez a kódnak csupán 0,4%-át érinti.

Ez az írás többek között azért született, mert a bejelentés oldalán törölték számos Novell fejlesztő hozzászólását, akik reagálni próbáltak bizonyos ott elhangzott kijelentésekre. Később a hozzászólások ismét engedélyezve lettek, és az érvek között ismét felbukkant a minőségre való hivatkozás. Erre csak azt lehet mondani, hogy a teljesen cserélhető médiaalrendszer, ahol választani lehet a Xine, az MPlayer, a JMF és a GStreamer között, elhibázott ötlet. Ezért került kötött módon a GStreamer-támogatás  a kódba. Ámbátor igaz, hogy a patchként való kezelés miatt a go-oo-ban korlátozott volt a lehetőség a kód refaktorálására.

A hozzászólásokból látszik, hogy nem ez az első eset, hogy valamit a StaDivision újraírt. Erre a sorsra jutott a GStreamer mellett a 64 bites Linux verzió, a natív Mac verzió, a gyorsabb indítás, a solver, az egymás melletti lapmegjelenítés, az élsímítás, az SVG-támogatás. A gyors körlevélfunkció pedig még várat magára. Vajon mikor lesz mindebből elege a fejlesztői közösségnek?

Ez a bejegyzés Michael Meeks blogbejegzései alapján készült.

Az FSF.hu Alapítvány 2009-ben kiírt Szabad Szoftver Pályázat 2009 pályázatán 7 pályaművet támogatott mintegy 3 millió forint összeggel, köztük a „Hasznos OpenOffice.org kiterjesztések fejlesztése” elnevezésű pályázatot is. A pályázat célja olyan kiterjesztések megírása, amely az OpenOffice.org közösség által régen hiányolt funkciókat valósít meg.

A kiterjesztésekről
A „Munkafüzet-dokumentumok lehetséges hibáinak felkutatása” kiterjesztés fejlesztése; Az ellenőrzés többek között ezekre a területekre terjed ki: Azon szövegként tárolt számok jelzése, amelyek képletekben kerültek felhasználásra; Számot tartalmazó cellák, amelyeket egyetlen képlet sem használ fel; Üres cellák, amelyet referenciaként használtak fel.
A kiterjesztés elérhető az OpenOffice.org Extension webhelyről:
http://extensions.services.openoffice.org/en/project/validator

Figyelőablak (Watch Window) fejlesztése Calc programhoz; A figyelőablak segítségével a kiválasztott cellák értékei és az értékek változásai egy külön megjelenő, mindig látható ablak segítségével a felhasználó számára is jól követhetővé válik.
A kiterjesztés elérhető az OpenOffice.org Extension webhelyről:
http://extensions.services.openoffice.org/en/project/watchwindow

Diagram készítő (szervezeti, gyűrű, venn és piramis diagramok támogatásával) kiterjesztés fejlesztése.
A kiterjesztés elérhető az OpenOffice.org Extension webhelyről:
http://extensions.services.openoffice.org/en/project/diagram

A pályázat keretén belül készült kiterjesztések forráskódja elérhető lesz ezen a helyen:
https://ooop.svn.sourceforge.net/svnroot/ooop/

Hibajelentést igénylése a következő linken lehet tenni:
https://sourceforge.net/apps/trac/ooop/wiki ]]> http://www.openoffice.hu/2010/09/palyazat-2009-hasznos-openoffice-org-kiterjesztesek-fejlesztese/feed/ 0 http://www.openoffice.hu/2010/08/ket-uj-kiterjesztes-az-openoffice-org-calc-programhoz/ http://www.openoffice.hu/2010/08/ket-uj-kiterjesztes-az-openoffice-org-calc-programhoz/#comments Tue, 03 Aug 2010 06:30:43 +0000 KAMI http://www.openoffice.hu/?p=1186

Elkészült két kiterjesztés, amelyek az OpenOffice.org Calc programjához nyújt – reményeink szerint – hasznos adalékot.

1) Watch Window
A Watch Window kiterjesztéssel megjeleníthető a figyelőablakban minden olyan cella, amelynek változásait követni szeretnénk függetlenül attól, hogy éppen melyik cellákat látjuk.

A kiterjesztés letölthető:
http://extensions.services.openoffice.org/en/project/watchwindow

A kiterjesztés telepítés után elérhető:
Calc: Eszköz – Detektív – Figyelőablak megjelenítése menüből.

2) Validator
A Validátor egy OpenOffice.org kiterjesztés, amely a kiválasztott szabályok alapján ellenőrzi a cellákat.

A kiterjesztés letölthető:
http://extensions.services.openoffice.org/en/project/validator

A kiterjesztés telepítés után elérhető:
Calc: Eszköz – Detektív – Validátor menüből.

Próbálja ki ezeket a kiterjesztéseket és visszajelzéseivel, új ötletekkel vagy bármilyen más módon járuljon hozzá a kiterjesztések továbbfejlesztéséhez.

A kiterjesztéseket Hornyák Tibor és Szalai Kálmán készítette együttműködésben a Szegedi Tudományegyetemmel és az OxygenOffice Professional Csapattal.

Támogatta a Free Software Foundation Hungary Alapítvány a Szabad Szoftverek Magyarországi
Népszerűsítéséért és Honosításáért, a Projekt 2009 keretein belül megítélt támogatással.

A munka még nincs kész, hiszen a meglévő kiterjesztések – felhasználói visszajelzések alapján történő – továbbfejlesztése mellett hamarosan jelentkezünk a vállalt feladatoknak megfelelően a Draw programhoz szánt kiterjesztéssel is.

Jó Calcolást!

Több száz nemzetközi fejlesztő, multinacionális döntéshozó, nagy nevű hazai és nemzetközi előadó érkezik Budapestre szeptember elején, hogy részt vegyen a világ talán legrangosabb nyílt szoftveres eseményén, az éves nemzetközi OpenOffice.org konferencián. A konferencia három napján az egész világ Budapestre figyel majd, hiszen a kis fejlesztő cégek és az OpenOffice.org mögött álló, nyílt szabványokat támogató multinacionális vállalatok – IBM, Oracle, Novell, Google – erre az alkalomra szokták időzíteni fontos bejelentéseiket. Ráadásul az idei jubileumi év rendkívül sikeres volt: a szoftver újabb változatait több, mint 157 millióan töltötték le.

Az eseményt a magyarországi Nyílt Dokumentumformátum Szövetség szervezi. A plenáris ülésnek a Parlament ad otthont – szimbolikus helyszín, hiszen számos civil szervezet, vállalat évek óta küzd azért, hogy a hazai közigazgatásban, az oktatásban, az állami szférában a nyílt ISO szabvány ODF, nyílt dokumentum formátum és általában a nyílt szabványok, valamint az ezekre épülő szoftverek a helyükre, az államigazgatási és intézményi felhasználók gépeire kerüljenek.

Az OpenOffice.org Konferencia 2010 rendezvény 2010. augusztus 31-től és szeptember 3-ig kerül megrendezésre, a konferencia fő helyszíne a Közép-európai Egyetem lesz.

Az OpenOffice.org Konferencia 2010 honlapja

Regisztráció a konferenciára

A legutóbbi fejlesztések arra irányultak, hogy a Numbertext moduljai bekerüljenek az Unicode CLDR nyelvi adatbázisba, ahol a Numbertexthez hasonló RuleBasedNumberFormat (RBNF) nyelvi leírások már helyet kaptak.

A Numbertexthez kidolgozott Soros nyelv előnye, hogy az összetett feladatok, mint a pénzegységek átalakítása is egyszerűen leírható vele. A svéd nyelv esetében a pénznem (illetve váltópénze) többesszáma mellett a pénznem nemére is figyelni kell, ami meghatározza a szám alakját. Egy új pénznem hozzáadása egy plusz programsort jelent csak a svéd Numbertext leírásban, pl.:

SEK:(\D+,.*) $(\1: cardr, svensk krona, svenska kronor, cardn, öre, öre)


A nyelvi adatbázis szinte minden modulja tartalmaz pénznemre vonatkozó információt, szemben az Unicode CLDR-rel. Az angol és a thai számok és pénznemek átalakítására létezik már ISO szabvány (az Office Open XML DollarText és BAHTTEXT mezőformátumkódjai, illetve a BAHTTEXT táblázatkezelő függvény), úgyhogy érdemes ezt más nyelvekre kiterjeszteni. E célból a Numbertext be lett jelentve az Unicode CLDR hibabejelentőjében, illetve bővült a svéd Numbertext modul, hogy összehasonlítható legyen az RBNF leírással. Az eredmény: a svéd RBNF leírás 199 szabályt tartalmaz, a Numbertext 92 szabályt, miközben több minden van benne: a pénznemek átalakítása (CHF, CNY, EUR, GBP, JPY, SEK, USD), három új nagyságrend (triljon, triljard, kvadriljon), és súgó függvény (help). A svéd modul referenciaként szolgál arra is, hogyan lehet a pénznemhez megadni a számok megfelelő nyelvtani alakját (pl. az előző programrészletben szereplő cardr és a cardn a számátalakításhoz használt függvények nevei, amelyek a pénznem és váltópénz neme alapján változnak).

A 0.9-es változatban változott a római számok leírása is. Szemben az IBM ICU RBNF leírásával, ami minden nagyságrendhez külön adja meg az 1000-szeres szorzást jelölő felülhúzást a római számoknál, a Numbertext leírás ezt egy egysoros függvénnyel intézi el:

(overline:.*)(.) $1\2̅ # a rekurzív függvény: minden betű után felülvonás (U+0305) karakter


A teljes Soros program csak 15 szabályt tartalmaz, szemben az IBM ICU ekvivalens RBNF leírásának 60 szabályával:

__numbertext__
1:(.)(.)(.) \1
2:(.)(.)(.) \1\1
3:(.)(.)(.) \1\1\1
4:(.)(.)(.) \1\2
5:(.)(.)(.) \2
6:(.)(.)(.) \2\1
7:(.)(.)(.) \2\1\1
8:(.)(.)(.) \2\1\1\1
9:(.)(.)(.) \1\3

(overline:.*)(.) $1\2̅


Pl. 3000000 = M̅M̅M̅

A Roman_2 modul (az első római számos modul a rugalmasabb zárójelezést használja a nagyobb számok jelölésére, l. NUMBERTEXT.org) az előző példára épít, de a dupla felülvonás helyett (ami a Firefoxban megjelenik, l. a NUMBERTEXT fejlesztőkörnyezet segítségével) mást alkalmaz: a szám elé és mögé húzott függőleges vonalat, ami százszoros szorzást jelent a hagyományos római jelölés szerint, például |C̅C̅C̅C̅C̅| az ötvenmilliót (500×1000×100). Azonban a rómaiak időnként rövidebb, zárójelhez hasonló görbe vonallal különböztették meg a számokat a szövegben, ami félreértésre, vagy legalábbis félremagyarázásra adhatott okot. A leghíresebb ilyen eset Sulpicius Galbáé, aki Tiberius római császár anyjától, Livia császárnétól (aki a saját fiával kevésbé volt jóban) |C̅C̅C̅C̅C̅| sestertiust örökölt, az örökség legnagyobb részét. Az akkor már trónra került Tiberius császár viszont rövidebb és görbe vonalakat látott a végrendeletben a szám körül, így az összeg századrészét, C̅C̅C̅C̅C̅ sestertiust hagyta csak jóvá. A vita eredményeként még ezt sem kapta meg Sulpicius Galba, de 8 év hispániai száműzetése során túlélte Nerót is, majd mintegy három hónapig uralkodott császárként Rómában, mielőtt meggyilkolták. (Forrás: 1, 2.)

A Numbertext fejlesztés kapcsolódik az FSF.hu Alapítvány támogatásával folyó OpenOffice.org fejlesztési és honosítási projekthez, például a Numbertext segítségével kiváltható és az angolon kívül más nyelvekhez is elkészíthető lesz az MS Office ordinal, CardinalText, OrdinalText, DollarText mezőformázása az OpenOffice.org-ban.

A Graphite az OpenType-hoz mérhető, sőt több szempontból annál jobb vektoros betűkészlet-formátum. Míg a teljes OpenType-támogatásra még várni kell, az OpenOffice.org-ban már most használhatunk Graphite betűkészleteket. A betűkészlethez egy OpenOffice.org eszköztár is készült, amivel még egyszerűbben kapcsolhatók be a következő tulajdonságok:

Ligatúrák: az f-ligatúrákat általánosan használják a nyomdai kiadványok. Alapértelmezés szerint a Magyar Linux Liberation G betűkészlet a szokásos ff, fi, fl, ffi, ffl mellett az fj, ffj betűsorozatot is nyomdai jelre cseréli ki szövegszerkesztés közben. Ha beállítjuk, a ritkább st és ct ligatúrákat is helyettesíti a Graphite betűkészlet.

Kiskapitális. Az irodai csomagok kiskapitális betűformázásával szemben a Magyar Linux Libertine G valódi kiskapitálist ad a tulajdonság bekapcsolásával. A kiskapitális betűk is négy változatban érhetők el: álló, dőlt, félkövér és félkövér dőlt (ez az OpenOffice.org szokásos karakterformázásával állítható be).

Ugráló számok: különböző kiadványokban gyakran használt, kisbetűs szöveghez jobban illeszkedő számok. Az ugráló számok számjegyei alapértelmezés szerint – szemben a nem ugráló számokkal – nem azonos szélességű térközt foglalnak el (ez módosítható, l. később).

Az eredeti Linux Libertine betűkészletben alapértelmezett német umlautos Ä, Ö és Ü betűvariánsok érhetők el ezzel a tulajdonsággal. (A Magyar Linux Libertine-ben az elterjedtebb variáns az alapértelmezett.)

Automatikus ezrestagoló: a Graphite betűkészletek saját leíró nyelvvel rendelkeznek. A GDL (Graphite Description Language) segítségével az is megadható, hogy a számok a megfelelő ezrestagolókkal kerüljenek automatikusan kiegészítésre. A szám beírása közben változik az ezrestagoló (nem törő keskeny szóköz, U+202F) pozíciója: 10 000, 100 000 stb. A kapcsoló háromállású: alapesetben az ezrestagoló csak 5 számjegytől, vagyis 10 000-től jelenik meg, de beállítható a táblázatok számára a négy számjegy is (pl. 1 000).

Számelhelyezés: a táblázatba kerülő számok számjegyeit is érdemes oszlopba rendezni az olvashatóság miatt, amit egyenlő helyfoglalású karakterekkel lehet elérni. Alapértelmezés szerint ez a beállítás a számoknál a betűkészletben (kivéve az ugráló számoknál, ahol a számok csak a szélességüknek megfelelő helyet foglalják el). Mind az ugráló, mind az alapértelmezett számoknál megváltoztatható ez a tulajdonság, hogy a szövegben egalizált, a táblázatokban pedig oszlopokba rendezett számjegyeket használhassunk.

A perjellel elválasztott számok alapértelmezés szerint kisebb számokból álló törtté alakulnak (max. 4-4 jegyű számok esetén).

A számok és a latin ábécé betűit valódi felső és alsó indexszé alakíthatjuk e tulajdonság bekapcsolásával. Ezzel pl. a szövegszerkesztő hamis kicsinyített lábjegyzetindexeit tipográfiailag helyes méretezett számokra cserélhetjük.

A betűkészlet még egy másik különleges megoldást nyújt az indexek használatára: ha egy számjegyet vagy nem ékezetes betűt a kalap (^) vagy az aláhúzás (_) jel előz meg, felső, illetve alsó indexű jellé alakul. Így elég a cm^2, vagy H_2O karaktersorozatot begépelni, hogy megkapjuk a cm²-t vagy H₂O-t (sőt, a Linux Libertine eredeti megoldásának köszönhetően az Unicode alsóindex-karaktert követő felsőindex-karakter nem utána, hanem az alsó index fölé kerül, így tudományos jelöléseket is megadhatunk).

A betűkészlet a számok előtt elhelyezkedő (kis)kötőjelet automatikusan mínuszjellé (U+2212) alakítja.

A betűkészlet használatáról: a Graphite tulajdonságok a betűkészlet nevével állíthatók be, egy kettősponttal elválasztva az OpenOffice.org-ban. A tulajdonságok et jellel elválasztva, azonosítószám-érték párokkal adhatók meg. Például a kiskapitális azonosítója a Magyar Linux Libertine G-ben a 200, az ugráló számoké 202, mindkettőt bekapcsolva a betűkészlet neve Magyar Linux Libertine G:200=1&202=1. A Tipográfia eszköztár használatával és a karakterstílusok frissítésével nincs szükség az azonosítók közvetlen használatára.

A Tipográfia eszköztár a fenti beállításokat a kijelölt szövegre, annak hiányában az aktuális bekezdés bekezdésstílusára állítja be. Az eszköztár az Eszközök->Kiterjesztéskezelő segítségével telepíthető, majd az OpenOffice.org újraindítása után a Nézet menü Eszköztárak menüpontjával kapcsolható be.

Sajnos az automatikus elválasztás alapból nem működik a Graphite betűkészletekkel az OpenOffice.org 3.2-ben. A javítás a tervek szerint bekerül az OpenOffice.org 3.2.1-be. Addig az eszköztár biztosít egy megoldást az elválasztás bekapcsolására az OpenOffice.org 3.2-ben, de ez erősen erőforrás-igényes, így gyengébb teljesítményű gépen érdemes az elválasztást csak a nyomtatás vagy PDF-be exportálás előtt bekapcsolni. Mivel a ligatúrákon belüli elválasztás is hibás a Graphite betűkkel, frissítsük a legújabb magyar OpenOffice.org szótárat, ami letiltja a ligatúrákon belüli elválasztást (az OpenOffice.org 3.2.1 FSF.hu-s kiadása elképzelhető, hogy ezen is javítani fog). A kisebb hiányosságok ellenére a magyar eredmény a kiadványszerkesztők szintjére emeli az OpenOffice.org-ot.

A közelmúltban dolgozták át az OpenOffice.org MS Word exportszűrőjét (WW8), amely a bináris .doc fájlformátum mentéséért felelős. Ez jó alapot képez további fájlformátumok, például az RTF exportszűrőjének modernizálására is. Az OpenOffice.org jelenlegi RTF exportja sok kívánnivalót hagy maga után, ezért nagy várakozásokkal tekinthetünk a korszerű WW8 ilyen irányú kiterjesztésére.

Kínai helyett újra magyar

Az OpenOffice.org 3.2-ban előre beállított kínai nyelv megzavarta az automatikus nyelvmegállapítást a célnyelvet nem tartalmazó Numbertext függvényhivatkozásoknál. A Numbertext Calc-kiegészítő új változatában már csak a dokumentum nyugati nyelve számít.

Java programkönyvtár

A Numbertext fejlesztés újdonsága a Java nyelvű változat elkészítése, és Java jar programkönyvtárként való kiadása. A fejlesztés célja, hogy a Numbertext széles körben elterjedjen, támogatva olyan jövőbeli fejlesztéseket is, mint a szöveges számozási típusok (pl. első, második, harmadik; egy, kettő, három) hozzáadása az OpenOffice.org Writerhez (l. OpenOffice.org 92730-as hibajegy). Svéd nyelvű példa a jar programkönyvtár használatára:

$ java -jar numbertext.jar -l sv_SE 1-10
ett
två
tre
fyra
fem
sex
sju
åtta
nio
tio


Thai módosítás

A thai tudományos akadémia 1982-es thai nagyszótárának (hivatkozás) és a thai Wikipédiának (l. 101, 501), valamint az OpenOffice.org 83490-es hibajegyének megfelelően a 01-re végződő thai számokban เอ็ด szerepel a หนึ่ง helyett.

Ez különbség a Microsoft Excel BAHTTEXT (a magyarban BAHTSZÖVEG) függvényéhez képest, ami az Office Open XML szabvány szövege szerint a thai konvenciót követi (ami úgy látszik, nem egyezik meg a thai nyelvi standarddal). A mellékelt ábra a thai 1, 31 és 101 számok átalakítását mutatja számnév + “Baht pontosan” alakban a Microsoft Excel 2007-ben (BAHTSZÖVEG) és OpenOffice.org Calc 3.2-ben (MONEYTEXT).

Új nyelvi modulok

Két új nyelvi modult tartalmaz a kiadás. A héber modul Alex Bodnaru munkája. A másik modul a helyenként megkövetelt banki magyar számírás, ami kiírja az egyet is az ezer és a száz elé. Használatához a modul kódját (hu_HU_2) kell megadni:


=NUMBERTEXT(1100; "hu_HU_2") → egyezeregyszáz

=MONEYTEXT(1100; "HUF"; "hu_HU_2") → egyezeregyszáz forint


Sorszámok

Az angol, francia, magyar, német és thai nyelvek esetében lehetőség van a sorszámokra alakításra is a MONEYTEXT függvény segítségével. A péznem helyett megadott „ord” a sorszámnevet, az „ord2” az angolban a sorszámrövidítéseket adja vissza.


=MONEYTEXT(9; "ord") → kilencedik

=MONEYTEXT(9; "ord"; "en") → ninth

=MONEYTEXT(9; "ord2"; "en") → 9th


Súgó

Nemcsak a sorszámok, hanem a nyelvtani nemek (mint a francia modulban az “ord-fem” és “ord-mas”) és egyéb nyelvi sajátságok kezelésére is szükség lehet az “ord”-hoz hasonló paraméterek létrehozásával. Segítségképpen az angol, magyar és német nyelvi modulhoz rövid súgó készült, ami a “help” paraméterrel olvasható ki:


=NUMBERTEXT("help") →
Functions: ord (ordinal numbers)
Extra language modules: hu_HU_2 (formal numerals)

=NUMBERTEXT("help";"en") →
Functions:
ord (ordinal numbers, eg. "first")
ord2 (ordinal abbreviations, eg. "1st")
Extra modules:
en_US_2 (subunit as decimal fraction: "USD 20.25" -> twenty and 25/100 dollars)


Az OpenOffice.org egyik legfájóbb hiányossága, hogy nem támogatja még az OpenDocument szabványban szereplő táblázatstílusokat. Ehhez kapcsolódóan elindult egy olyan fejlesztés is, aminek célja, hogy megoldást nyújtson több táblázat egyidejű és egyszerű átformázására. Mielőtt elkészülne egy OpenOffice.org-kiegészítő, az első eredmények helyet kaptak a jegyzet makróprogramozással foglalkozó fejezetében is: ugyanis olyan egyszerű megoldást sikerült találni az összes, vagy csak a megadott stílusú táblázatok átformázására, hogy makróprogramozási példának is megfelelt.

Letölthető a jegyzet OpenDocument formátumú forrása is, amiből megismerhetők a még nem dokumentált megoldások (például keretstílusok használata a margóra helyezéshez, vagy a háttérképként beillesztett piros lénia a szakaszcímek és az azt közvetlenül követő bekezdések behúzása helyén), illetve az is kiderül, hogy az ábrák rajzolásához nincs szükség semmilyen speciális segédeszközre: az OpenOffice.org Writer elég pontos és robusztus ahhoz, hogy tökéletes (a PDF-kimenetben pedig tökéletesen kereshető szövegtartalommal rendelkező) ábrák készüljenek vele. A jegyzetben használt és ismertetett stílusok alapján elkészül hamarosan egy magyar sablonállomány is (de a stílusok akár a jegyzetből is átmásolhatók).

A fejlesztéseket az FSF.hu Alapítvány támogatja. További információk olvashatók az FSF.hu Alapítvány blogján (például a legújabb OpenOffice.org-foltokról, amelyek javítják a táblázatok és ábrák feliratozását) és ezen az oldalon.