LibreOffice 4.0.3

 

LibreOffice Berlin, 2013. május 9. – A The Document Foundation (TDF) bejelentette a LibreOffice 4.0.3-at Windows, MacOS és Linux rendszerekre. Ez a harmadik hibajavító kiadás a LibreOffice 4.0 február eleji megjelenése óta. Sikerült megoldani az OS X Intel csomagok digitális aláírását, így a LibreOffice felhasználói beavatkozás nélkül átmegy az OS X Gatekeeper biztonsági ellenőrzésén.

Nemrég jelentették be, hogy a spanyolországi Extremadura tartomány megkezdte a szabad szoftverekre, többek közt LibreOffice-ra való átállást. 2013 végéig a 40 ezer asztali számítógépük nagy részét át fogják állítani. Számításaik szerint évente 30 millió eurót fognak megtakarítani az átállással.

Tovább nő a LibreOffice közösség. Nemrég Németországban találkoztak az Impress fejlesztői a LibreOffice Impress Sprint eseményen. A következő rendezvény az első alkalommal megrendezendő LibreOffice Bay Area Meetup lesz május 11-én, a helyszín a Hacker Dojo Mountain View-ban (Kalifornia). Az európai fejlesztők közül Bjoern Michaelsen ott lesz, lehet tőle kérdezni és segít beszállni a projektbe, illetve Simon Phipps tart egy előadást „Foundations and Empires” címmel.

A TDF és a LibreOffice évente 13%-kal növekszik az Ohloh adatai szerint. 2013 februárja óta átlagosan több, mint 100 fejlesztője van. A projekt bejelentése óta (2010. szeptember 28.) összesen 650 új fejlesztőt vonzott magához a projekt.

A fejlesztők a minőségbiztosítást sem hanyagolják el. Például Markus Mohrhard írt egy Python programot, amellyel a hibabejelentő rendszerekbe beküldött mintegy 24 500 dokumentumot tudja importálni a LibreOffice, és teszteli, hogy a LibreOffice összeomlik-e ezektől. Florian Reisinger a tesztelők dolgát könnyítette meg azzal, hogy megírta a LibreOffice Server Install GUI programot, amellyel a több LibreOffice-verzió telepíthető egymás mellé tesztelés céljából.

Ez a kiadás újabb jelentős mérföldkő a LibreOffice 4.0 stabilizációs folyamatában, elősegítve a szabad szoftverre való áttérés folyamatát.

A 4.0.3-ban javított hibák listája most a szokástól eltérően három részletben érhető el, mert az RC2-ben még találtak egy súlyos hibát: RC1, RC2 és RC3.

A cikk szerzőjéről

Tímár András 1999-ben kezdett foglalkozni a szabad szoftverek honosításával. Magalakulásakor csatlakozott az FSF.hu Alapítványhoz, ahol vezető tisztséget is vállalt. 2002 óta dolgozik az OpenOffice.org (2010-től a LibreOffice) magyar verzióin. 2011-től főállású LibreOffice-fejlesztő, jelenleg a Collabora Productivity Ltd.-nek dolgozik.

Hozzászólások

  1. A kiadás a magyar helyesírás-ellenőrzést is javítja egy kicsi, de fontos területen: a LibreOffice ismét helyesnek ismeri fel a %, §, °C toldalékolt alakjait (pl. %-nak, §-ban, °C-os), l. https://bugs.freedesktop.org/show_bug.cgi?id=62360.

  2. dr. Nagy Gábor szerint:

    Egy zavaró “apróságot” tapasztaltam, ami a legújabb, 4.0.3-as kiadásban is megvan.

    Amikor a túlméretes (>550 oldal, 835 sorszámozott és feliratozott ábra) kéziratombó PDF fájlt készítek a LibreOffice saját PDF készítő eszközeit használva, az előálló PDF fájlban véletlenszerűen egyes képaláírások elmozdulnak a helyükről és “elbújnak” a PDF készítéshez tartozó áttördelés alkalmából a hozzájuk tartozó képek, ábrák mögé. Ha egy kicsit megfogom ezeket a képeket, gyorsan kiugrik alóluk és visszaül a helyére a “felrázott” képaláírás, azonban az újabb PDF készítéskor újfent véletlenszerűen a képaláírások úgy 15-20%-a újból elbújik.

    Gondoltam egyet, és próbát tettem a BullZIP PDF programmal, ami nyomtatódriverként telepszik be a Windowsba. És láss csodát, ezzel a módszerrel minden képaláírásom a helyén maradt a frissen legyártott PDF fájlban. Ha tesztelésre anyagot kértek, elküldöm a mára 100 MB fölé hízott .ODT fájlt, amibe még be kell gyömöszölnöm további 160 ábrát, a már bent levő 675 mellé. Csak akkor küldöm, ha kéritek, feleslegesen senkit nem akarok ezzel spammelni.

    Egyelőre most a BullZIP PDF-et próbálom úgy belőni, hogy ne nagyon rontsa a PDF-be ágyazott ábrák felbontását, és pumpálom be a megfelelő helyekre a még beszúrásra váró (alkalmasint javítandó vagy cserélendő) képfájlokat.

    Ettől az apróságtól eltekintve csupán az a bánatom, hogy amint egyre nő a méret, a beágyazott képek mennyisége és a velük járó ezernyi kereszthivatkozás száma, a Writer néha félórára-órára is elmolyol a dokumentumfájl felesleges újratördelgetésével. Ez messze nem egy ideális állapot, de már a 450. oldalnál tartok a tervezett 550-ből, míg a Word 2010-nek már az első 100 oldal is sok volt.

    Tudom, használjak fődokumentumot és a fejezeteket tegyem külön-külön aldokumentumokba, vagy tegyem át LaTeX-be, de ezt majd a következő kéziratomnál tudom csak megtenni. Momentán szeretném Writerben megoldani a dolgot.

    • Kenczler Mihály szerint:

      A dokumentumod valószínűleg jó példa a LibreOffice korlátainak demonstrálására. Erős sejtésem szerint a 100+ hivatkozott ábrát tartalmazó dokumentum szerkesztésére már professzionális szoftvert célszerű használni. (Én már egy 32 oldalas, 40 ábrás prospektushoz kénytelen voltam elhagyni a LibreOffice-et. Továbbá: erre a célra a Word 201 sem eléggé professzionális. Vajha a szegény Scribus micsinálna a dolgozatoddal?)
      Még továbbá: végig szoktam nézni a javított hibák listáját. Most azt találtam, hogy “megjavult” a beágyazott táblázatok RTF-importja úgy, hogy a funkció alaposabb átdolgozásáig ez az import nem támogatott, mert a Writer összeomlik tőle.
      Namármost: ki az az, aki stílusokkal formázott, egymásba ágyazott táblázatokat akar RFT-ből importálni?! Wordből ilyen nem jön, mert nem lehet a táblázatokat egymásba ágyazni.
      Hátugye, aki 550 ábrát hivatkozik egyetlen dokumentumban, annak más ötletei is lehetnek…
      Bocs, Kedves Nagy Gábor, a problémád arról győzött meg, hogy NINCS egzotikus probléma.

    • Már fele ilyen nagy dokumentumoknál graphite (Linux Libertine) használatánál nekem is sok gondom volt úgy általában a libreoffice teljesítményével és a PDF export sebességével. Percekbe telt ameddig 250-300 oldalt és max 10-15 ábrát ki tudott exportálni. Linuxban amúgy valamivel gyorsabban ment a dolog, de még ott is lassú volt.

    • Ezzel a hibával mintha találkoztam volna én is, de mintha csak bizonyos beállításoknál fordulna elő. A keretben lévő képeknél optimális körbefuttatás van beállítva? Lehet, hogy elég PDF fájlba nyomtatni a dokumentumot (hogy újratördeljen), és utána exportálni PDF-be, ha működik az említett külső PDF-átalakításos módszer.

      A fődokumentumot érdemes kipróbálni a betöltött dokumentum fődokumentum változatának egyszerű létrehozásával: a Fájl->Küldés->Fődokumentum létrehozása menüpont kiválasztása, majd itt a fejezetcím stílus megadása után a LibreOffice létrehozza a fődokumentumot fejezetenként elmentett állományokkal, így össze lehet hasonlítani, mennyivel kényelmesebb, mint az egy hatalmas dokumentum kezelése (lényegesen gyorsabb és biztonságosabb). Ha nincs sablona az eredeti dokumentumnak, érdemes hozzáadni a Template Changer kiegészítővel, majd azután létrehozni a fődokumentumot, hogy továbbra is egy helyen (itt a sablonállományban) lehessen a stílust beállítani minden fejezet számára egységesen.

      A Graphite 2-vel (LibreOffice 3.4) jelentősen gyorsult a Linux Libertine G kezelése (bár sajnos van más problémája, pl. a ligatúrán belüli elválasztás hibás, remélem, hogy ezt sikerül hamarosan kijavítani).

      • dr. Nagy Gábor szerint:

        Kedves Laci!

        Egészen felvillanyozott, amit írtál, hogy a meglévő túlméretes doksit maga a Writer is ki tudja tolni fejezetenként aldokumentumokba. Neki is álltam, hogy leírásod alapján megtegyem. Az eredmény azonban egyelőre lehangoló:

        A fejezeteket Címsor 1 stílussal (Vázlatszintje 1) formázott bekezdések vezetik be. Ez jó és elég a Navigátor számára, és a tartalomjegyzék is simán megvan vele. Ennek ellenére a 16 számozott fejezetet úgy exportálja ki a Writer, hogy külön kerül a számozatlan előszó és bevezetés, valamint a szintén számozatlan függelék és tartalomjegyzék. Az összes többi anyag marad egy középső, dögnagy fájlban (most 106 MB), ami magában foglalja mind a 16 számozott fejezetet, tehát ott vagyok, ahogy a part szakad.

    • dr. Nagy Gábor szerint:

      Úgy tűnik, nem csak a Libre Writere felelős a tapasztalt lassulásokért és az említett torzulásokért (azaz a képaláírások olykor véletlenszerűen becsúsznak a képek mögé).

      Egy bivalyerős tanári gépen szerkesztettem át a napokban az anyagomat, reménykedve, hogy menni fog. Az otthoni és az irodai gépemen/gépeken (valamint a netbookomon) egyaránt ugyanazt a lassulást tapasztaltam, így kerestem egy erősebb gépet. A számítógéplaborjaink szerverként is szolgáló tanári gépeiben 8 GB memória és négy gyors processzor van, 64 bites Windows7 rendszerrel. Egy ilyenen fél nap alatt 500 oldalnyit tudtam ellenőrzésképp átnézni az addig elkészített kéziratból, javítottam vagy két tucatnyi ábrát, 70-80 fel nem vezetett vagy rosszul kialakított kereszthivatkozást, találtam néhány befejezetlen vagy zavaros mondatot. És csak időnként kellett egy-egy percre megállnom, amíg – biztos ami biztos – elindítottam egy egy mentést.

      Nem az .ODT fájl javult meg, mert az irodai és otthoni gépekben továbbra is csak két-három percnyi folyamatos munkát tudok végezni, és utána 1-2 óráig valamit szorgalmasan dolgozik a Writer. Mindenesetre ez talán hasznosítható információ azoknak, akik a program memóriakezelésével, a kód optimalizálásával, a rendelkezésre álló erőforrások jobb kihasználásának lehetővé tételével foglalkoznak.

      Mindenesetre a kézirat véglegesítése lassan a befejezéshez közeledik, csupán 30-40 oldal van még hátra. A sorszámozott képek száma 835 (még mindig 1000 feletti képfájl felhasználásával), a végső oldalszám pedig 580 körül várható a függelékekkel, tartalomjegyzékkel, irodalomjegyzékkel együtt. A pillanatnyi fájlméret a maradék 20 ábra beszúrása előtt 122 MB. És az említett bivalyerős gépen könnyedén szerkeszthető, ha van hozzá elegendő erőforrás, a Writer szépen kezeli.

      Csupán azt kéne megoldani, hogy normális (kétmagos, 3 GB RAM-mal rendelkező) asztali vagy noteszgépeken is képes legyen erre elfogadható kisebb lassulással.

      • dr. Nagy Gábor szerint:

        Ja azt elfelejtettem megírni, hogy az emlegetett bivalyerős tanári gépen a frissen átszerkesztett első 500 oldalt (amelyben már a helyükön vannak a képek) a Writer saját PDF készítőjével hibátlanul legyártotta a PDF változatot.

  3. Már régóta meg akartam kérdezni, de mindig elfelejtem. A telepítéskor az indító hivatkozás létrehozása asztalon és a rendszerindításkor való betöltés mellett van egy ilyen lehetőség: “Kisegítő technológiai eszközök támogatása”. Ez mit takar?

    • Vakoknak képernyőolvasó támogatása, ilyesmi. Be lehet kapcsolni a programból is, de azt a jelzést kaptuk, hogy azt a panelt nem tudja felolvasni a képernyőolvasó, míg a telepítőt igen, így jobb, ha ott is kapcsolható.

      • Köszi a választ. Viszont nem kellene ezzel kezdeni valamit? Mert én pl. tök sok embert megkérdeztem a környezetemből és senki se tudta, hogy mire jó ez a lehetőség.

  4. dr. Nagy Gábor szerint:
  5. Lehet tudni valami a Calc teljesítményproblémái kapcsán történő javításokról? Már a forkoláskor téma volt a calc teljes (motorjának) újraírása, és valamennyit javult is, de még egy egyszerűbb statisztikai táblázat esetén is rémesen lassú (és nem a gépem az oka), 2-3 táblázat párhuzamos használata esetén lassan már azon gondolkodom, hogy lehet inkább excelt kellene használjak, bár nem szeretném.
    Ami szintén idegesítő, és talán egyszerűbb lenne megoldani, az a táblázatok vagy általában a fájlok mentésével kapcsolatos. Ha valami komolyabb dokumentumot esetén beindul az automatikus mentés, akkor a többi megnyitott dokumentumot is használhatatlanná teszi arra a 30-90 mp-re.

  6. Az .rtf fájlok megnyitása még mindig lassú. A 3.4-es széria óta ez folyamatos probléma.