“LibreOffice 6.1.1” bejegyzéshez 15 hozzászólás

  1. Sajnos a LO 6.1.1. sem lett gyorsabb – mind ahogy azt a 6.1.0-nál is jelezte már Kenczler Mihály .

    Az itt a hírekben is elérhető “Első lépések LibreOffice 6.0 kötet” ODF dokumentumot (amire nem foghatjuk rá, hogy rosszul strukturált, hobbi-felhasználói fércmű lenne) a LO6.1.1 másfél perc (90 s!) alatt nyitja meg a gépemen a LO, amiből most a teszt kedvéért a normál, permanensen telepíthető 32 bites változatot telepítettem.

    (Nem szokásom az ilyen friss verziók fix telepítésével fárasztani magam, míg ki nem próbáltam azokat hordozható verzióban. Most is azzal kezdtem, de gyanakodtam, hátha a hordozható változat problémája csak a lassúság…)

    Ugyanezen a gépen, ugyanezzel az operációs rendszerrel (Win7 prof 64 bit 8 GiB RAM) a HORDOZHATÓ (szintén 32 bites) LO 4.4.7 verzió 10 s (tíz másodperc!!!) alatt végzett.

    1. …Bocsánat, nem Kenczler Mihály, hanem Gajárszki László jelezte a sebességproblémát a LO 6.1.0 megjelenéséről szóló hírben…

  2. Ha már megemlített Kovács úr, akkor elvégeztem a sebességteszteket.
    Megerősítem, hogy ugyanazon a gépen ugyanazt a fájlt a LO6.1.1 lényegesen lassabban tölti be, mint (nálam) a LO5.4.7.
    A “lényegesen” viszont sokkal kisebb különbséget, illetve alacsonyabb arányt jelentett nálam.

    “Getting Started 6.0” ODT (22 MB, erősen formázott) dokumentum betöltődése:
    LO6.1.1 50 mp
    LO5.4.7Portable 24 mp
    Körülmények: Win10 Pro 64b, 4 GB RAM, Intel i5 750 (2,7 GHz) (kb. 8 éves asztali konfig)
    Végrehajtás: a programot a telepítés után elindítottam, hogy túl legyen az első indításon.
    A dokumentumot a Totalcommanderből “ráejtettem” a másodszor elindított, és betöltődött LO megnyílt ablakába. Azt az időt mértem, amely a ráejtéstől a dokumentum betöltődött, görgethetővé, majd szerkeszthetővé válásáig eltelt (megjelent a szövegkurzor, és be lehetett szúrni egy szóközt a szövegbe).

    Megjegyzem, hogy a szélsőségesen nagy méretű, és-vagy szélsőségesen erősen formázott, és-vagy erősen strukturált dokumentumok minden szoftverbe meglehetősen lassan töltődnek be. Nekem a mért idők szokásosnak, elviselhetőnek tűntek, más, hasonló dokumentumokra is várni kell, amíg a LO “hozzákészülődik”.

    1. Miután a cégnél – többek között a jelzett hibák miatt is – még a LO 4.4.7 változatot használjuk, ezért én ahhoz hasonlítottam a sebességet (tehát nem elírás a részemről). A LO nálam is futott már, amikor a Fájl – Megnyitás paranccsal betöltöttem a kérdéses dokumentumot. Nyilván a HDD sebességétől és a gép egyéb elemeinek jellemzőitől is függ az abszolút sebesség, sőt akár még az arányt is meghatározhatják részben a LO-tól független jellemzők, de azért a kétszeres arány sem túl biztató.

      Mi lehet vajon az oka?

  3. Nem értem én sem ezt a lassúságot a LO-nál a legújabb 6.1.1 verzió sem gyorsabb. Ugyanazt a dokumentumot persze nem ugyanolyan kiterjesztéssel az MS Office gond nélkül megnyitja egy pillanat alatt és simán akadás nélkül lehet görgetni is oda-vissza, a LO már a betöltésnél lassú görgetni szinte nem is lehet csak a szélén a csúszkákkal lehet lefelé menni a dokumentumban, de úgy is szaggat és a mentés is lassú a program szinte lefagy 20-30 másodpercre. A két dokumentum bitre megegyezik csak az egyik verzió a LO-ban van elmentve a másik pedig MS Office kompatibilis kiterjesztésben. Ja és a dokumentum csak 12mb bele se merek gondolni mi lehet egy 100mb-os dokumentummal, szerintem meg se nyitná.

    1. “Ja és a dokumentum csak 12mb bele se merek gondolni mi lehet egy 100mb-os dokumentummal, szerintem meg se nyitná.”

      Nem mindegy, hogy mitől 12 MiB méretű az a dokumentum, és hogy milyen formázási módszereket és strukturális elemeket használ. A beágyazott képeket mindenképpen optimalizálni kell még a dokumentumba történő beillesztés előtt. A kézi (közvetlen) formázások helyett a stílusokat kell használni, jól átgondolt szerkezetben. És itt kell megemlíteni, hogy a MS formátumok soha nem lehetnek “bitre azonosak” egy ODF dokumentummal. Vannak olyan tulajdonságok, amelyek a másik fájlformátumban egyszerűen nem léteznek, vagy egészen más alapokon nyugszanak. Emiatt a konverzió sem lehet soha 100%-os pontosságú.

      Az OpenOffice / LibreOffice egyébként mindig is lassabb volt a MS Office-nál – ezzel együtt lehet, és kell élni -, de most a LO a régebbi önmagához képest lett SOKKAL lassabb.

      1. Egyébként 100 MiB-nyi szöveget nem lehet beírni, de még összeollózni sem rövid idő alatt. Az ilyen nagy méretet általában a beszúrt képek okozzák.

        Jó példa a képek fölösleges túlméretezésére az angol fórumról:

        A dokumentum – amit csak Google drive-ről tudott belinkelni a felhasználó a túlzott méret miatt – három képet tartalmazott, ebből kettő 3,48 x 1,91 cm fizikai méretűre(!) lett zsugorítva a dokumentumban. A zsugorítás viszont NEM VÁLTOZTATJA meg a kép eredeti pixel- (bájtokban számított) méretét, ami 50 MiB volt darabonként. Némi optimalizálás után az eredetileg 150 MiB-os dokumentum mérete – észrevehető minőségromlás nélkül – 77 KiB-ra (IGEN!) csökkent.

        https://forum.openoffice.org/en/forum/viewtopic.php?f=29&t=94918&p=452865

        1. – kicsit offtopic –
          Nem tudom, mióta van a LO-ban ez az optimalizálás, én a 6.x ágnál vettem észre, de nagyon fontos.
          Valahol fel kellene tüntetni azt a 200 dolgot, amelyeket észben kell tartani, amikor a zember 20 oldalnál nagyobb, strukturált, dokumentumot csinál — akármiben, nemcsak LO-ban. Az egyik a stílusok kizárólagossága, a másik a bittérképes képek optimalizálása, a harmadik a Windowsba beépített betűtípusok használata, és így tovább.

          1. “Windowsba beépített betűtípusok használata”
            Már hogy csak azokat célszerű használni, vagy éppen azokat kerüljük??? Mi a LibreOffice-szal szállított DejaVu családot használjuk elsősorban – műszaki dokumentumokhoz, ahol a valódi alsó/felső indexek használata széleskörűen szükséges és ezzel a fonttal lehetséges is.

            Calc dokumentumban nem lehet ugyanis a formázással alsó/felső indexbe helyezett karaktereket másik cellába hivatkozni anélkül, hogy ne kellene az eredményt mindig újraformázni. Ezekkel a fontokkal pedig lehetséges – a valódi alsó/felső index karakterek segítségével).
            Nos, ezzel a fontcsaláddal nekünk eddig semmiféle problémánk nem volt. Ha szükséges, be lehet (és be szabad!) ágyazni a dokumentumba, vagy a PDF exportba… Igaz: nem Graphite típus, de ez azt is jelenti, hogy nincsenek fölösleges “meghibásodó, gyakran elavuló alkatrészek”…)

          2. “másik a bittérképes képek optimalizálása”

            Igen, azzal csúnyán túl lehet terhelni a programot (a processzort, a memóriát), akár már néhány óriási bájt-méretű képpel is. De hát ez annyira logikus és egyszerű alapdolog, hogy nem kell sehová “felírni”: ezt TUDNI kell minden számítógép használónak… Hogy a szélességi és hosszúsági pixel adat összeszorozva bazi nagy számot ad, azt meg még hárommal kell szorozni, hogy a színeket leírhassuk. Ennyi bájtnyi memória kell a csomagolt fajtájú, de a munkához “kibontott” kép összes adatának ideiglenes tárolásához a memóriában. És processzor idő a kicsomagoláshoz, meg az aktuális nagyítás adatainak kiszámításához. Mert ha nagyon lekicsinyítjük a képet, akkor “el kell dobálni” pixeleket, ha nagyon felnagyítjuk, akkor meg kell többszörözni a pixeleket – mert üres pixel nem maradhat a képernyőn, és egy képpont a kijelzőn csak egy pixelt (vagy többnek a “számított átlagát”) képes csak megjeleníteni.

            1. Ja: …és semmivel nem lesz jobb egy A4-es oldal negyedrészére összezsugorított, majd kinyomtatott kép attól, hogy tizen-huszon-sok pixeles kamerával készült, és “biztos, ami biztos” mind az összes eredeti pixelt belezsúfoljuk a dokumentumba…

    2. Muszáj megjegyeznem, hogy a LO 6.1.x (Writer) jól észrevehetően gyorsabban működik, mint a korábbi, pl. az 5.x változatok. A betöltődés az lassú, igen.
      Javult pl. egy nagy dokumetumban a körbefolyatott keretek “lökdösése” (a pozíció léptetése kurzorral), ami azért a kurzor nyomva tartásával még mindig messze nem tud lépést tartani, a gomb elengedése után a keret még tesz 8-10 lépést…

      1. A HUP-on annyi információt találtam, hogy a digitális aláírások betöltéskori ellenőrzése az oka a lassulásnak.
        https://hup.hu/cikkek/20180927/libreoffice_6_1_2#comments

        Akkor megint lőttek a cégnél a frissítésnek… Maradunk a 4.4.7-nél. (Az 5.4.7-re történő frissítés más okok miatt maradt el.) Otthon próbálkozok az újjal (most már a 6.1.2-vel).
        Engem nem zavar a sok angol nyelven hagyott menü és opció szöveg (a fórumok miatt eleve többet van nálam angolra állítva az UI, de a kollégáim sajnos morognának azok miatt is…
        A lassulás miatt pedig… – azt meg nem is írom ide, hogy mit mondanának.

Hozzászólás a(z) Kovács Tibor bejegyzéshez Kilépés a válaszból

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük