A The Document Foundation bejelenti a LibreOffice 6.3-at

A The Document Foundation bejelenti a LibreOffice 6.3 megjelenését, amely a LibreOffice 6-os család funkciógazdag új főverziója. Számos új és továbbfejlesztett funkciót kínál, valamint jobb interoperabilitást a zárt dokumentumformátumokkal:

  • A Writer és Calc teljesítménye egy nagyságrenddel javult a felhasználók által biztosított dokumentumok alapján: könyvjelzőket, táblázatokat és beágyazott betűtípusokat tartalmazó szövegfájlok, nagy ODS és XLSX táblázatok és az FKERES függvényt használó Calc fájlok gyorsabban töltődnek be és jelennek meg. A Calc táblázatok XLS fájlokba mentése is gyorsabb lett.

  • A szalagos felhasználói felület kompakt verziója elérhető a Writer, Calc, Impress és Draw komponensekhez. Ez több területet hagy a felhasználói dokumentumoknak, táblázatoknak és bemutatóknak a széles képernyőjű laptopokon.

  • A Calcban egy legördülő menü helyettesíti a régi Összegzés eszközt, gyors hozzáférést biztosítva a leggyakrabban használt függvényekhez. Ezen kívül mostantól a FOURIER függvénnyel diszkrét Fourier-transzformáció számítható bemeneti adattömbökből.

  • A PDF-exportálás a szabványos PDF/A-2 dokumentumformátum támogatásával bővült, ami számos szervezet számára a hosszú távú fájltároláshoz szükséges. Ezen kívül a szerkeszthető PDF-űrlapok tervezése egyszerűsödött az Űrlap menü átalakításával, a LibreOffice egyik legerősebb funkciójának továbbfejlesztése érdekében.

  • A dokumentumok mostantól anonimizálhatók, a személyes adatokhoz hasonló érzékeny információk eltávolítása vagy elrejtése érdekében, ezzel segítve cégeket vagy szervezeteket egyes szabályozásoknak való megfelelésben.

  • Windowson javult a konzolos mód támogatása, kezelhetőbb kimenettel és hibakódokkal. Ez egyszerűbbé teszi a kötegelt feldolgozást, például a nyomtatást vagy sok dokumentum átalakítását.

  • Számos területen javult az interoperabilitás a zárt Microsoft Office formátumokkal: támogatott lett a DOTX dokumentumsablonok és XLTX táblázatsablonok exportja, diagramok importálása csoportosított DOCX alakzatokból és a diagramok tulajdonságainak exportálása és importálása, javult a SmartArt importálása és exportálása a PowerPoint-beli szerkesztési képesség megőrzése érdekében, és fejlődött az XLSX kimutatástáblák interoperabilitása is.

  • A LibreOffice 6.3 új funkcióit közreműködők nagy közössége fejlesztette: a módosítások 65%-a a tanácsadói testületben jelen lévő cégektől származik, mint a Collabora, Red Hat és CIB, valamint más szervezetektől, illetve 35% egyéni önkéntesektől.

  • Ezen kívül az egyéni önkéntesek globális közössége más alapvető tevékenységekkel is foglalkozik, mint például felhasználói felület és felhasználói élmény tervezése, minőségbiztosítás, szoftverhonosítás, súgó- és dokumentációírás, valamint a szabad szoftverek és nyílt dokumentumszabványok népszerűsítése helyi szinten.

  • A LibreOffice 6.3 legérdekesebb új funkcióit összefoglaló videó elérhető a YouTube-on:

LibreOffice egyéni felhasználóknak

A LibreOffice 6.3 a nyílt forráskódú irodai felhasználás tekintetében a legújabb technológiát képviseli, és mint ilyen, az új technológiák iránt rajongókat, a korai befogadókat és tapasztalt felhasználókat célozza meg. A The Document Foundation nem biztosít technikai támogatást a felhasználóknak, noha más felhasználóktól kaphatnak segítséget levelezőlistákon és az Ask LibreOffice weboldalon.

Azon felhasználók számára, akik a személyes hatékonyságot és így a több tesztelésen átment kiadást részesítik előnyben az új funkciókkal szemben, a The Document Foundation fenntartja a LibreOffice 6.2 családot, amely az elmúlt néhány hónapban visszaportolt javításokat tartalmazza. Az aktuális verzió a LibreOffice 6.2.5

LibreOffice vállalati környezetekben

A vállalati szintű bevezetésekhez a TDF határozottan javasolja a hosszú távon támogatott kiadások, támogatási szolgáltatások, egyedi funkciók és hibajavítások tanúsított szakértőktől való beszerzését. Ezen munka eredménye visszafolyik a közösséghez, és mindenki számára elérhető lesz.

A bevezetéshez és képzéshez szükséges támogatást is tanúsított szolgáltatóktól ajánlott beszerezni, akik értéknövelt szolgáltatásaikkal a zárt ajánlatokkal azonos szintű megoldást kínálnak a vállalati informatikai vezetők számára.

A LibreOffice az érett kódbázisának, gazdag funkciókészletének, a nyílt szabványok erős támogatásának, kitűnő kompatibilitásának és a tanúsított partnerek által kínált hosszú távú támogatási lehetőségeknek köszönhetően ideális lehetőséget kínál a gyártófüggőségtől szabadulni kívánó cégek számára.

A LibreOffice 6.3 beszerzése

A LibreOffice 6.3at azonnal letöltheti az alábbi címről: www.libreoffice.org/download/. A telepítéshez szükséges operációs rendszerek minimuma a Windows 7 SP1 és az Apple MacOS 10.9. A legfrissebb LibreOffice Online forráskód elérhető Docker képfájlokként is: hub.docker.com/r/libreoffice/online/.

A LibreOffice Online alapvetően egy szerveroldali szolgáltatás, amit felhőalapú tárhely és SSL tanúsítvány hozzáadásával kell telepíteni és beállítani. Alkalmazható az internetszolgáltatók által használt felhőszolgáltatásokhoz, valamint a cégek és nagyobb szervezetek saját felhőihez egyaránt.

A LibreOffice felhasználói a szabad szoftverek hívei, valamint a közösség tagjai a The Document Foundationt támogathatják is pénzadománnyal a www.libreoffice.org/donate linken ismertetett módon.

A LibreOffice 6.3 a Document Liberation Project dokumentum konverziós könyvtárainak segítségével jött létre: www.documentliberation.org

“A The Document Foundation bejelenti a LibreOffice 6.3-at” bejegyzéshez 33 hozzászólás

  1. A teljesítmény érzékelhetően javult! Nagy köszönet érte.
    Impressben azzal az MS féle ppt(x) bemutatóval, amivel eddig szüttyögött egy darabig, nos most egy pillanat alatt betölti.
    Csak gratulálni tudok!

  2. Egy jó, önálló LO Felhasználói Fórum is kéne. Ha egyszer az Apache meggondolja magát és nem biztosít a mostani közös AOO/LO fórumnak helyet, akkor sok értékes információ fog eltűnni, megsemmisülni… Nem csak a magyar fórumról, de az angolról (és a többi nyelvű fórumról) is.

    A levelezőlisták, meg az Ask… NEM helyettesítik a jól kereshető, jól strukturált fórumokat. A levelezőlisták egy része de még az egykor létezett angol LO fórum is ad-hoc jellegű volt, vagy olyan magánkezdeményezésű dolog, amikor is egyetlen ember dönthetett a létéről. Meg is szűnt az angol LO fórum is, és a régebbi levelezőlista is. A mostani levelezőlista meg eléggé marginális.

    Én magam Fórumot nem tudok csinálni (főleg nem tudok helyet, infrastruktúrát biztosítani neki), de – ahogy most is a közös AOO/LO fórumon – segítőként egy igazi LO fórumon szívesen közreműködnék.

  3. A 6.2.6 is megjelent már. Most várom a hordozható verziókat – kipróbálásra.

    1. Jézus: azt hittem a 6.3-al új ciklus kezdődik, s a 6,2-nek vége. Kezd áttekinthetetlenné válni. .. Ma reggel töltöttem le az olasz X-es változatot a 6.3-ból. Alig várom a “rendes” portable.apps-ot. Ez borzalmas. A magyarítás gyenge és hiányos, lassabb a 6.2.5-nél. Kedvenc giga excel-file-om 6000 sor, 3500 link (könyv-lista): a Microsoft 4 mp alatt tölti be. A 6.2.5 11 mp. A 6.3, a gyorsabbnak ígért pedig 21 mp alatt. Semmi gyorsulás, semmi érdemi előny, viszont a shift+F5 kombináció, mellyel odt-formátumnál a legutolsó mentési helyre ugrom a file-ban itt eltűnt! (Atyák és Összeírtak: ez benne van a progiban, miért nem lehet a beállításokban megadni? Ha egy segítő tag nem hívja fel rá a figyelmemet, soha nem jövök rá, hogy van! (Ha már sírás-rívás: a beépített stílust miért nem írhatom felül a saját definiciómmal, mint más progokkal?) Viszont az is igaz, hogy a 6.2.5-el több általam gyakran használt stílustúltengő nagy borzalommal rendesen lehet dolgozni!

      1. Kedves László!
        Érdekes módon sebesség terén pont az ellenezőjét tapasztalom a fent leírtaknak. Nem írtad, hogy milyen rendszeren használod az alkalmazást, de ha Windows-on akkor ott lehet más is befolyásolja a megnyitás sebességét. Linux alatt én azt tudom mondani, hogy az előzőekhez képest a 6.3 pokoli gyorsan dolgozik.
        A fordítás hiányosságáról néhány példát érdemes lenne megemlíteni, jómagam eddig nem tapasztaltam problémát — az online súgóban vannak (voltak?) lefordítatlan karakterláncok, de senki nem tiltja, hogy bárki besegítsen a fordításban.
        A beépített stílusokat gond nélkül meg tudom változtatni, ezt a problémát így — én legalábbis — nem tudtam reprodukálni.
        A SHIFT+F5-ről “odt-formátumnál a legutolsó mentési helyre ugrom a file-ban” tudnál írni egy kicsit bővebben? Ezt a funkciót nem ismerem és így ahogyan leírtad nem is találtam róla igazán semmit sajnos. A Writer-ben be van ugyan állítva a shift+f5 (Szerkesztőnézet visszaállítása), de nem sikerült rájönnöm, hogy ez mit állít vissza. Netán erről a funkcióról írtál?
        A fellelt hibákat érdemes bejelenteni a fejlesztői oldalon, előbb utóbb biztosan javítva lesznek.

        1. 1. A 6.3.0 (Writer és Draw) határozottan gyorsabb az én agyonhasznált (=régen újra nem telepített) Windowsaimon is.
          2. A súgó fordítása mindig egy kicsit le van maradva a programé mögött, ez szerintem kibírható. Jellemzően az új funkcióknál fordul elő, persze.

          3. “senki nem tiltja, hogy bárki besegítsen…”, hát, tiltani nem tiltja, de nem is segíti. Kedves Bendegúz, ha lennél oly kedves, és leírnád azt a “táncrendet” kattintásról kattintásra, amelynek a végén a zember egy javaslatot eljuttat a hivatalos csatornán a fordítókhoz… A NAV-nál előbb intézem el az SzJA visszautalást.
          4. “előbb-utóbb biztosa javítva lesz…”, hááát, kontinuum számosságú tényezőtől függ, hogy mikor javítják ki a százlépéses, fejlett angol nyelvtudást és a javítási processzek részletes ismeretét követelő eljárás során bejelentett új hibát. Az évtizedek során legalább háromszor nekiveselkedtem, de mindannyiszor visszapattantam. Könnyebb és gyorsabb a hibát elviselni, megkerülni, mint bejelenteni. Nyilván a másik oldal meg az, hogy a bejelentések 99,99 százaléka unásig ismert és már beprogramozott javítású hibát tartalmaz — ha nem olyan funkciót hiányol, amely megvan a szoftverben, de az illető nem találta meg, vagy a csak nála fellelhető bonyolult körülményrendszer következménye (ld.pl. ezt a Shift-F5 dolgot…)

          1. 3. Ezzel kapcsolatban én egészen biztosan először Kelemen Gábort vagy Tímár Andrást keresném (//hu.libreoffice.org/rolunk/), de ott az FSF.hu oldal és Facebook-on is elérhetőek. Mellesleg nem vagyok meglepődve, ha nem egyszerű részt venni a fordításban… …pár éve András közzétett egy felhívást, amiben kérte a felhasználókat, hogy segítsenek a súgó aktualizálásában. Úgy emlékszem kb. hárman jelentkeztek…
            4. Nem tudom mit mondjak erre. A múlt havi nagy bugvadászat alkalmával bejelentettem néhány hibát, amiből jó pár már javításra került. De szerintem már az is valami, ha egyáltalán tudnak egy adott hibáról a fejlesztők. Persze jó lenne, ha mindent kijavítanának (akkor lenne csak igazi alternatíva MS helyett), viszont egy ilyen komplex szoftvernél ez valószínűleg soha nem fog bekövetkezni sajnos.

      2. Kedves Bendegúz, elnézést a késésért. 1. Librét kizárólag portable változatban használom, mert heppem, hogy mnidig külső adathordozóról dolgozom, több gépen szoktam (otthon+munkahely) így mindig kedvenc környezetemet használom. A sebesség-gond lehet, hogy az olasz változat nyűge, de otthoni win10 és munkahelyi win7 alatt ugyanaz. A teszt egy, kis e-könyvtáromat rejtő adatbázis, több lap, a legnagyobb 6200 könyv, melyhez kb. 3200 link tartozik. A Microsoft O. (2007) kb 3-4 sec alatt nyitja, a 6.2.5 kisebb szórással 10-12 sec, a 6.3 21 sec. Softmaker Office Calc: 8-9., a Libre 6.3: 22. 2. Stílus: normális proginál kijelölöm a szövegrészt, annak alapján definiálom a stílust. Ez Libreben is van, de nem írhatom felül vele a beépített stílust, pedig kényelmes lenne a szalagos menühöz. Lehet manuálisan definiálni, csak sokkal fárasztóbb. Bosszant, hogy Libreben nem adhatok meg egy menetben globálisan egy oldalméretet (Softm,, MicroO ez egy perc, de ez megkerülhető, mert a stílusoknál kijelölhető több, akár az összes oldalstílus, (Apache OpenO-ban nem!) s aztán törölhetőek, az összes oldal beáll az első oldal margójára. 3. Shift+F5: magam sem tudtam, hogy Libréban létezik, egy kedves szakértő hívta fel rá a figyelmet anno (szerintem Kovács Tibor urat illeti a köszönet). Csak ODT kiterjesztés mellett működik. Nekem nagyon kényelmes, ui. többnyire ABBY-Finereaderból mentett OCR-es szövegeket korrektúrázom a progival, s kényelmes, hogy mindig visszamehetek az utoljára feldolgozott oldalra. Ez a Softmakerben alapbeállítási lehetőség, a Kingsoft/WP-ben is az, ha jhól emlékszem. Agyrémnek tartom, hogy a Libre beállításokban nincs meg ez a lehetőség, amit a prog tud, miért titkolni a jót? Végül: miért nem lehet a telepített Libreből magából portable-t csinálni, s miért nem lehet szelektálni az összetevők között? Draw pl. soha, equation ed. soha stb. Egy számomra tökéletes Softmaker magyar, angol, német és francia checkerrel 120 Mb körül, a 2016-os változat 96 MB. A “teljes”2018-as portable 380 Mb. Bocs a terjengésért!

        1. Ha jól értem, akkor adott egy dokumentum, ami linkeket tartalmaz több másik dokumentumra, mint egy tartalomjegyzék. Gyanítom — és tényleg csak gyanítom –, a LibO a dokumentum megnyitása után ellenőrzi a linkeket és ezzel megy el “sok” idő. Ennek kiderítésére-kikapcsolására nem találtam beállítást, de jó lenne egy mintadokumentum is enne tesztelésére.
          Talán nem ismered — ha mégis, akkor nem szóltam — a Zim notes alkalmazást, ami esetedben sokkal hatékonyabban látná el a feladatot, mint bármelyik office alkalmazás (//linuxmint.hu/blog/2018/09/zim-jegyzetelo-extrakkal). Ne tévesszen meg a LinuxMint oldal, az alkalmazás fut Windows-on is.

          “Stílus: normális proginál kijelölöm a szövegrészt, annak alapján definiálom a stílust. Ez Libreben is van, de nem írhatom felül vele a beépített stílust”
          Erre a megoldás az Automatikus frissítés bekapcsolása. Forrás: //mek.oszk.hu/12800/12812/12812.pdf
          “Automatikus frissítés használata
          A Bekezdésstílus ablak Szervező lapján van egy Automatikus frissítés jelölőnégyzet.
          Ez csak bekezdés- és keretstílusok esetén jelenik meg. Ha ezt a jelölőnégyzetet bejelöli, a LibreOffice automatikusan alkalmazza a stílusra azokat a módosításokat, amelyeket közvetlen formázással végeztek el egy bekezdésen, melyre ez a stílus alkalmazott.”

          “Bosszant, hogy Libreben nem adhatok meg egy menetben globálisan egy oldalméretet”
          Az oldalstílusok módosításával megadhatóak globálisan az oldalméretek. Vagy másra gondoltál?

          A shift+f5-öt még most sem értem mire jó. Egy példát tudnál rá mondani?
          Az Eszközök-Testreszabás-Billentyűzet menüben megvan ez a kombináció “Szerkesztőnézet visszaállítása” néven, de nem tudom ez mit csinál és azt sem, hogy ez megegyezik-e az általad említett funkcióval?

        2. “s miért nem lehet szelektálni az összetevők között? Draw pl. soha, equation ed. soha stb.”

          Ez nagyon egyszerű: A LibreOffice egy valóban INTEGRÁLT irodai alkalmazás, míg a többi valószínűleg nem az.
          Az MS office-ban például teljesen különálló program a Word, az Excel, a PowerPoint – különálló futtatható állománnyal és beállításhalmazokkal…
          A LibreOffice-ban – ha megnézed az operációs rendszered programkezelőjében az éppen futó programokat – csakis a soffice.exe programot látod futni több példányban, akkor is, ha Writer, Calc, Impress alkalmazásokat indítottál el. Amivel elindítod (a sWriter.exe, a sCalc.exe, a sImpress.exe) ugyanazt a soffice programot indítja, csak más beállításokkal. (A “s” betű valószínűleg még StarOffice örökség.)

          Emiatt egyszerűen nem érdemes azzal foglalkozni, hogy valamelyik komponenst töröld, vagy akár ne is telepítsd, mert nem nyernél vele mérhető mértékű helyet, vagy egyéb erőforrást, hiszen a kis méretű launcher programok és a beállítások kivételével gyakorlatilag MINDENT ugyanúgy fel kell telepíteni.
          A Draw program méltatlanul mellőzött dolog (a részedről is), mert ugyan az alapvető rajzoló funkciók minden alkalmazásból elérhetők, de a Draw konfigurációban érhető el az összes funkció és lehetőség, a többiben csak korlátozottan. Célszerűbb tehát a rajzokat a Draw-ban elkészíteni, és onnan átemelni a Calc-ba, vagy a Writerbe…

          1. Még egy kis magyarázat, kicsit más szemszögből:
            Ha valóban nem telepítenéd fel az a függvény- és eljáráshalmazt, ami a Draw alkalmazás tudását adja, akkor a Writerben vagy a Calcban, vagy az Impressben sem tudnál rajzolni SEMMIT. Ugyanis működésileg és “fizikailag” is pontosan ugyanazokat az eljárásokat – illetve csak azoknak csak egy részét – használják, mint a Draw.

            És az egyenletszerkesztő se önmagában hasznos: ugyanazzal szerkeszted a Writer, vagy a Calc alkalmazásban is a matematikai formulákat. Csak maga a funkció elérhető önálló alkalmazásként is.

        3. “Végül: miért nem lehet a telepített Libreből magából portable-t csinálni, ”

          Mivel léteznek portable verziók, ez azt bizonyítja, hogy LEHET. Csak érteni kell hozzá. (Megjegyzem: én se értek hozzá.) Hiszen az újabb és újabb verziók megjelenése után kijövő hordozhatókat nem ÚJRAÍRJÁK, hanem csak megfelelően “csomagolják” ugyanabból a kódkészletből, hogy hordozható legyen.

          1. Távolról sem a saját preferenciáimat erőltetném, mert akkor azt írnám: miért nem portable alapból. Akinek nem kell így, “stabilként” használja. Egyébként a SoftmakerO. ill. a rokon AshampooO-nál bevlt lehetőségre gondoltam: a telepített progiból lehet portable-t csinálni. Nagyon kéne. A PortableApps-változat jobb az olasznál, de így is… A “remove extra languages” mellett bennehagy egy csomó lokalizációs vackot, ebből manuális 3-3500 file-t törlök ki minden alkalommal, így az “én Librém” NTFS kompresszált filerendszeren 384 Mb, s gyorsabban is indul.

        4. “mert heppem, hogy mnidig külső adathordozóról dolgozom,”

          Nagyon-nagyon veszélyes dolog (adatvesztés szempontjából). Legalább azt tedd meg, hogy időbélyeges biztonsági másolatokat készítesz a fontosabb dokumentumaidról.
          Erre írtam a fiammal együtt a timeStampBackup nevű kiterjesztést.

        5. “Bosszant, hogy Libreben nem adhatok meg egy menetben globálisan egy oldalméretet (Softm,, MicroO ez egy perc, de ez megkerülhető, mert a stílusoknál kijelölhető több, akár az összes oldalstílus, (Apache OpenO-ban nem!) s aztán törölhetőek, az összes oldal beáll az első oldal margójára. ”

          A LibreOffice fejlesztői abból a végtelenül logikus és egyszerű feltételezésből indultak ki (tényként kezelve), hogy egy normális szöveges dokumentum NEM alkalmaz oldalanként más és más oldalbeállítást (eltérő margókat, orientációt, méretet, stb.) A lehetőség természetesen erre is megvan, de “nem erre van kihegyezve”.
          Az OCR programok viszont a Word ad-hoc-nek is nevezhető oldalbeállítás stratégiáját végtelenségig kihasználva, a szkennelt dokumentumok oldalbeállítási tulajdonságainál a papír pozicionálás hibája miatt keletkező eltéréseket nem kerekítik egy átlagos értékre, hanem akár 0,01 mm-enként különböző értékeket mérve, arra is állítják be az oldalakat. Ezt a LibreOffice fájlformátuma a különböző oldalstílusok sorozatára való konvertálással lehet csak képes lekezelni. Ez annak az OCR programnak és a .doc formátumnak a bosszantó butasága, és nem a LibreOffice-é.
          Megjegyzés: Minden egyes “szerkesztő-jellegű” program a natív, saját fájlformátumát használva a leghatékonyabb, a többi fájlformátumot MINDEN EGYES megnyitáskor és mentéskor KONVERTÁLNIA kell. A konverzió SOHASEM sikerülhet 100%-os pontossággal, azonossággal. Nincs olyan, hogy “most egy idegen fájlformátumban SZERKESZTEK”.
          MINDIG a saját fájlformátumában szerkeszt a LibreOffice (is), és ezért az idegen formátumhoz kétszeres konverzió szükséges.

          1. Távolról sem a saját preferenciáimat erőltetném, mert akkor azt írnám: miért nem portable alapból. Akinek nem kell így, “stabilként” használja. Egyébként a SoftmakerO. ill. a rokon AshampooO-nál bevlt lehetőségre gondoltam: a telepített progiból lehet portable-t csinálni. Nagyon kéne. A PortableApps-változat jobb az olasznál, de így is… A “remove extra languages” mellett bennehagy egy csomó lokalizációs vackot, ebből manuális 3-3500 file-t törlök ki minden alkalommal, így az “én Librém” NTFS kompresszált filerendszeren 384 Mb, s gyorsabban is indul.

          2. Sajnos, minden igaz… de az Abby kvázi szabvány a nem túl számos magyar nyelvet is ismerő programok között. Amit a 9-es verziótól kezdve művel (14-nél tart) az kimeríti az emberiség elleni bűntett fogalmát, de még így is pontosabb layout, mint a Rediris. Ezen viszont nem tudok változtatni, ami az én — szerintem jogos — gondom, hogy mindez a trágya a Microsoft-ban, Ashampoo-ban, Softmakerbe egyszerűen felülírható: oldal-margóállítás, az egész dokumentumra. Ez akárhogy is, számomra a Libre fogyatékossága. (Az Apache-ban ez a megkerülési lehetőség sincs, tehát az emiatt nálam felejtős. Amúgy számomra a Libre bár a 4.1 óta figyelem, kissé mindig “terra incognita”, speciális, idegen logikája, logikátlansága miatt: egyetlen más proginál sem érzek olyan frusztrációt, hogy elemi dolgot nem csinál meg? Dehogy, én vagyok a hülye, mert nem találtam ki azt az egy beállítást… PL. időtlen ideje nem vagyok képes megfejteni, hogy egy görög szót kell beültetni a maygar szövegbe: ezt képként copy a pdf-ből, minden proginál a kurzorhoz, a helyére megy. A Libre/Apache egy kínlódás…

  4. Az előző hozzászólásom eltűnt, de egy dolgot kiemelnék belőle:
    “Ez Libreben is van, de nem írhatom felül vele a beépített stílust, pedig kényelmes lenne a szalagos menühöz.”

    Felül lehet írni a beépített stílust is — illetve automatikusan felülíródik –, mindössze annyit kell tenni, hogy:
    — F11
    — Jobb klikk a beépített stíluson (vagy bármelyiken)
    — Módosítás…
    — Szervező fül – Automatikus frissítés: engedélyezd
    Ha megvan, akkor minden az adott stílussal formázott bekezdésen végzett manuális szerkesztés automatikusan bekerül a stílusba is.

    1. Tudom, ismerem, csak lusta vagyok, nem szerkesztgetem őket. Ehelyett azt találtam ki, hogy kijelölöm a megfelelő formátumot (ami tehát a szövegben már “kész” van, azt elnevezem C1, C2, C3-nak. A testreszabásban ezekhez definiálom a megfelelő billentyűkombinációkat (gyakorlatilag címsor 1, címsor 2… A Softmakerben így szoktam meg. A billentyűbeállítást elmenthetem/betölthetem. Többet nincs gond vele, bármilyen más dokumentumban benne lesz a parancs. Sajnos, az “eredeti” -t nem írhatom vele felül.
      Köszönöm!

      1. Feltételezem, hogy bekezdésstílusokról van szó. Egy erre írt makróval (vagy több hasonló funkciójúval9 az abban a pillanatban aktív bekezdés közvetlen formázással megadott bekezdéstulajdonságait át tudod másolni (get-set) egy adott stílusba, akár az “eredetikbe” is.

  5. Hordozható LibreOffice: Évekkel ezelőtt már nyafogtam a PortableApps.com-on, hogy a Libreoffice-t SOKKAL könnyebb újratelepíteni, mint átmásolni — mert (akkor) több mint 20000 (húszezer!) fájlból áll(t). Most 13-14000, tehát a helyzet sokat javult.
    Rámásolni egy USB-tárolóra kb egy óra volt, most 45 perc.
    A megoldás az évekkel ezelőtt Tímár Andrástól tanult bootstrap.ini hekkelés:
    — a bootstrap.ini a {libreoffice}/program könyvtárban van, egy sima szövegfájl;
    — az utolsó sorát a telepítés után, de az ELSŐ FUTTATÁS ELŐTT át kell írni;
    UserInstallation=$ORIGIN/../profile -re, ahol a “profile” tetszőleges könyvtárnév lehet
    — sajnos, egyszer be kell állítgatni minden sajátos dolgot, nálam az utoljára szerkesztett fájlok, az automatikus javítás szótára, a sajátos paletták és sajátos alapértelmezett stílusok fontosak;
    — más gépre telepítésnél csak ezt a “profile” könyvtárat kell hordozni…
    Én, eléggé el nem ítélhető módon, mindig rátelepítem az új fresh verziót a korábbira, átírom a bootstrap.ini-t az első futtatás előtt, és az új verzió hűségesen beolvassa a változatlan “profile” könyvtárból a beállításaimat.
    A 6.3-nál még működött…

  6. Tudja valaki, hogy az User Profile könytár elérési úrvonalában miért rekedt meg a programcsomag a 4-es számnál? Ez a 4.x.x verziónak a jelzése volt régebben ( a 3-as verzióbál …/3/… volt az útvonal stringben).
    Ezután már mindig így marad? Az 5.x.x és eddig a 6.x.x verzió is erre a …/4/… útvonalra hozza létre az User Profile-t.
    (Tehát, ha jól értem, egy 4-es, egy 5-ös, egy 6-os nem hordozható verziót nem tudok buherálás nélkül telepíteni egy időben.)

  7. A “Portable.apps” változatra nálam gond nélkül rá lehetett telepíteni az újat, a beállítások megmaradtak. Az olasz X-libre esetén minden új lappal indul. Viszont mindkettőre igaz, hogy a beállításokara sok időt kell vesztegetni. A program mindét esetben tele van “lokalizációs szeméttel” mleyet csak manuálisan lehet kitakarítani, könyvtárról könyvtárra. Én kb. 4-4.500 file-t törlök ki mert pl. afrikaans ill. vietnami dolgok valamiért nem kellenek. Ezek zöme aprócska, ami pendrive-másolásnál rabolja az időt+tárhelyet. Mostani 6.3.0 X-librem 474Mb, telepítés után (annak ellenére, hogy X-libreben kiválaszthatom a telepítendő nyelvet, szótárat 750 Mb volt. Sokkal gyorsabban indul. Egyéni konfigurálásnál érdemes a billentyűkombinációkra fókuszálni, mert ezek “szállíthatók”. Sajnos — lehet hogy az X-libre hibája — ezeket a 6.3-nál ellenőrizni kell, mert egy részük talán fordítási gond miatt nem működik. Pl. ugrás/kijelölésnél “ugrás a FILE végére” helyett ugrás a DOKUMENTUM végére. Utána jó… Amúgy pl. a Calc kompatibilitása kissé javult, mert olyan xlsx-et megnyit (ha rosszul is) amit korában nem. Az odf-formátum életveszély, mert minden jól áthoz, de a képletek eltűnnek, s csak a generált értékek maradnak.
    Ugyanakkor a elképesztő bugjai mellett a 6.4-től már kompromisszumokkal de használható a program. (PL. felfoghatatlan, hogy egy felesleges objektumra (rosszul OCR-felismert vonalrészlet, vagy folt törlésekor néha a program a file legelejére ugrik, mint a 4.1-es verzióban, de nem mindig! Tévesen generált fej- vagy lábléc törlésekor pedig mindig!)

  8. “Egyéni konfigurálásnál érdemes a billentyűkombinációkra fókuszálni, mert ezek “szállíthatók”. Sajnos — lehet hogy az X-libre hibája — ezeket a 6.3-nál ellenőrizni kell, mert egy részük talán fordítási gond miatt nem működik.”

    A billentyűkombinációk kiosztása lokalizáció függvényében más és más lehet a Windowsban is (a rendszer által lefoglalt billentyűk egy részét nem lehet/nem érdemes átkonfigurálni) és a LibreOffice-ban is. Az angol fórumon más segítők néha javasolnak olyan funkciókat és gyárilag hozzárendelt billentyűkombinációkat, ami nálam abszolút nem úgy van “bedrótozva”: innen az információ.
    A saját egyéni eszköztárak is hordozhatók akár a dokumentummal, akár az User Profile-lal, csak arra kell ügyelni, hogy azonos ikonkészletet, sőt – tapasztalataim szerint – ugyanolyan ikonméretet kell használni minden gépen, ha nem akarod, hogy az ikonok szöveggé váljanak…
    És persze egyéni menüpontokat is ugyanígy lehet hordozni: fájllal, vagy profillal.
    A profillal történő hordozás természetesen felülírja a célgép összes beállításait, ha egyetlen nagy kupacként másolod át…

    “Mostani 6.3.0 X-librem 474Mb, telepítés után (annak ellenére, hogy X-libreben kiválaszthatom a telepítendő nyelvet, szótárat 750 Mb volt. Sokkal gyorsabban indul. ”
    Igen, az X-LO “telepítőjében” offline rendelkezésre áll az összes nyelvi fájl, a konfigurálásnál csak azt adod meg, hogy a LO figyelembe vegye-e, vagy sem: nem törli le automatikusan a használaton kívülieket, hiszen bármikor meggondolhatod magad…

    “Az odf-formátum életveszély, mert minden jól áthoz, de a képletek eltűnnek, s csak a generált értékek maradnak.”
    A képletszerkesztő formátumáról beszélünk, ugye? A problémát viszont nem értem… KÉP-ként marad meg a “generált” érték? Mely esetekben történik ez? MS képletet megnyitva? Az MS képleteket valóban újra kell írni. Legalábbis az általam használt LO verziók nem igazán voltak szerkesztés-kompatibilisek az MS elavult, soha nem szabványosított formátumaiból származó képletekkel.

  9. Elnézést kérek, trehány voltam, nem odt, ods. Azaz: a Calc-ban korrektül kezeli, de ha ezt a Calc-ból mentett ods-t megnyitom Micros. Exc.-ben, akkor minden tökéletes, de a képletek, melyekkel adatokat összesítek, stb. nem jönnek át, azaz csak az értékük, amit nem észrevéve nagy gondok vannak. A 6.2.4-5-nél ugyanez a helyzet, de natív MicroExc.-ben meg sem nyílt… (Ez egy elátkozott, de nekem életfontosságú nyilvántartó-file. Softmakerből ecxelbe sem nyitotta meg, de on-line filekonverterrel átkonvertálva igen.) Valószínűleg internet-linkek a gond, melyek az egyes címekre vannak “ráültetve”. Képletekkel kevés tapasztalatom van, s alapfunkciókon kívül értemét sem látom. Ez a program “földszintes usereknek” készül, akiknek nem igénye (bár egy-egy új függvény hozzátétele jót tesz az illető egójának) a profik SPSS-t használnak.

  10. “Elnézést kérek, trehány voltam, nem odt, ods. Azaz: a Calc-ban korrektül kezeli, de ha ezt a Calc-ból mentett ods-t megnyitom Micros. Exc.-ben, akkor minden tökéletes, de a képletek, melyekkel adatokat összesítek, stb. nem jönnek át, azaz csak az értékük, amit nem észrevéve nagy gondok vannak. A 6.2.4-5-nél ugyanez a helyzet, de natív MicroExc.-ben meg sem nyílt… (Ez egy elátkozott, de nekem életfontosságú nyilvántartó-file. Softmakerből ecxelbe sem nyitotta meg, de on-line filekonverterrel átkonvertálva igen.) Valószínűleg internet-linkek a gond, melyek az egyes címekre vannak “ráültetve”. Képletekkel kevés tapasztalatom van, s alapfunkciókon kívül értemét sem látom. Ez a program “földszintes usereknek” készül, akiknek nem igénye (bár egy-egy új függvény hozzátétele jót tesz az illető egójának) a profik SPSS-t használnak.”

    Akkor most már végképp nem értem… A Calc cellafüggvényekkel van baj? És ráadásul olyan alapfunkciókkal, mint az összegzés?! Ezt nehezen hiszem…
    A statisztikai függvények többsége is Excel minta alapján került be a Calcba…
    Ha saját függvényeket írtál, vagy külső adatra hivatkozol akkor azzal persze van gond, mert a makrózás alapvetően különbözik a két programban, és a külső adatok csatolása sem azonos módszert használ – ha jól tudom.

    A legnagyobb hibát viszont abban látom, hogy – ha jól értem – összevissza szerkesztgeted a dokumentumaidat mindenféle eltérő koncepciók alapján működő szerkesztőprogrammal. Ez a legbiztosabb út a dokumentum meghibásodásához, vagy teljes elvesztéséhez.

    1. A helyzet: van egy excel-file, ami az MTDA állományát leltárként rögzíti. Ennek eredete 2004… Ha kikerültek a netre, az illető file címére “rá lett ültetve” a hiperlink. A lista különböző szempontú összegzéseit egy összegzőlapon foglalom össze (=SZUM(MTDA!L2:L6242) a legbonyolultabb képlet. (Elküldhetem a file-t is, de nem lenneól nagy élmény…) Összesítenem kell, hogy hány oldal az összállomány, hány oldal van ebből a neten stb. A dolog analóg a “beszúrás / érték/ képlet” dologgal. xls-ben a dolog OK, rendben megnyitja a libréből mentettet. ods-ben, azaz a LO “táblázatos” vezérformátumából is tökéletes a konverzió, de ezek a képletek/számítások eltűnnek, helyettük CSAK A SZÁMÍTOTT érték jelenik meg. Ugyanazon a füzetben is! Ez felületes szemlélőt félrevezetve nagyon nagy kárt okoz. (A hiperlinkkezelés amúgyis zavaros: “hiperlink eltávolítása” writerben tökéletes, calcban semmit nem csinál). Tény, hogy 2004 óta a tábla sok mindent megért, s azóta is nekem ez az etalonom. A legnagyobb kárt emlékeim szerint a Lo okozta, valszeg a 4,3 változata, ami mindent teleszemetelt dátum-értelmezéssel, ami soha nem volt benne. A Softmaker doc/xls konverziója OK, xlsx-változatot MOffice nem nyitotta meg, a LO igen, interneten átkonvertálva viszont minden tökéletes lett. Amúgy szerintem az odf-gondot valami igdn primitív trehányság okozhatja, mert minden más tökéletes. A szakemberekkel meg a teljes szereptévesztés a baj: itt most szövegszerkesztő, táblázatkezelő stb. progokról beszélünk. Ezt igenis Nusika kezeli, aki pl. anyagigényléshez használja. Nusika buta, (én is) fogalma sincs a programozásról, meg NEM IS DOLGA. Rossz, elavult az Abby, rossz a Microsoft elavult formátuma. Biztos igaz, de Nusikának azt mondták, hogy x kompatibilis y-al. Mondhatni, x egy Ferrari, s azért nem jó, mert gödrök vannak az úton, de a Zaporozsec meg bírja. Megbecsülni sem merem, mennyi időt töltöttem 2004 óta inkompetens programozók hibáival… Elemi trehányságokkal: a Softmaker első 2019 redisztribúciója nem nyitotta meg a saját formátumában mentett dokumentumot. A 2016-os igen. A Lo-nak volt olyan verziója, (Portableappas) ami vírusos volt (vagy ezt írta ki a prog.), volt ami el sem indult… A LO szépen és dinamikusan fejlődött, de a központi érdemi ellenőrzés és összefogás hiánya össznépi programozói banzáj maradt, ahol pár valóban profi és lelkes (Ön természetesen az, s nem udvariasságból mondom) érdemi munkát végez, fejleszt, sokan meg az egojukat hízlalják felesleges dolgokkal, tesztek, ellenőrzés nélkül, a felhasználók bőrére. S van egy szép, lelkesen barkácsolgató közösség, s egy program, ami állandóan fejlesztődik, de megbízhatatlan, instabil, s mai napig aggódom, hogy amin tegnap dolgozom, az ma megnyílik-e, illetve mindig hálásan meglepődőm, ha működik egy amúgy beígért funkció. (Végül, elnézést a terjengésért: az én igényeim mondhatni perverzek, abby+ocr=doc, korrektúrázáshoz, de ez érdemi munka, nem köldöknéző teszt, s így több hiba is előjön. A gondok egy része az én hozzánemértésemből fakad, amiért elnézést, de sok szövegszerkesztő stb. proggal volt dolgom, s egyedül a Lo volt az, amit “menetből” megérteni, használni … A korábban érintett shift+F5 funkcióra feltehetően Ön hívta fel a fiygelmemet. Ez igen hasznos, Softmakerben WP-ben a beállításokban egyszerűen konfigurálható…) Pedig egyre jobb program lehetne…)

  11. “(=SZUM(MTDA!L2:L6242) a legbonyolultabb képlet.”

    Felkiáltójeles elválasztó karakter nincs az .ods formátumban. Ez egy .xls fájl, amit a LO-nak folyton konvertálgatnia kell megnyitáskor is, mentéskor is. És a formátumok közötti áthidalhatatlan inkompatibilitások miatt minden egyes konverziónál romolhat a helyzet. (Ezt már sokszor leírtam. )
    Egyszerűen NINCSENEK meg bizonyos tulajdonságok a régebbi formátumokban. Azokat helyettesíteni kell valami hasonlóval. Az újabb tulajdonságokat meg törölni, vagy visszabutítani kell a régi formátumba történő mentésnél. Ez semmiképpen NEM SIKERÜLHET százszázalékosan.
    És igen, vannak olyan cellafüggvények, amik nincsenek meg a másik fajta programban. Mindegyikben van többlet is, hiány is. De a SZUM() nem ezek közöl való, az valóban alapfüggvény. Ha az nem működik, akkor ez vagy a konverzió hibája, vagy más képletekkel, hivatkozásokkal, dokumentum-struktúrával összefüggő hibajelenség..

    De a leírás hyperlinkes részét végképp nem értem. Hol, és miért szerepelnek hyperlinkek az összegző képletekben? A fájlban vannak jelzésként hyperlinkek, és csak azokat az értékeket kell megszámolni vagy összegezni, ahol van? Ezt az egyszerű SZUM() függvény biztosan nem tudja. Ha magukat a hyperlinkeket kell megszámolni a tatományban üres cellák között, akkor a COUNTA(), Egyébként a COUNTIF(), SUMIF() függvények jöhetnek szóba. (Elnézést, hogy angol függvényneveket használok)

    .

    “Nusika buta, (én is) fogalma sincs a programozásról, meg NEM IS DOLGA. ”

    Persze, a programozás nem dolga. De az dolga lenne, hogy a LibreOffice használatát megtanulja, és programot ne úgy használja, mintha mechanikus írógép, vagy MS Office lenne. (Nálunk is van/volt több Nusika is)
    Az MS az azonnali, ad-hoc formázásokra hegyezte ki a programja működését, LibreOffice esetében előre kell tervezni dolgokat, stílusokat. Ez nem biztos, hogy a Nusikák dolga: jól elkészített sablonokkal – amelyekben már ott vannak a szükséges stílusok, és ki van alakítva a dokumentum váza – lehet nekik segíteni.

    Szívesen megnézem a fájlt – bár nem ígérem, hogy segíteni is tudok.

    1. A borzalom: //fszek-my.sharepoint.com/:x:/g/personal/reiszl_fszek_hu/EcXZCG-rgrpAhWj6R0yAUxsBz2sKcwWUoyl8_h3-iYpyoQ?e=tSulgb. xls-re tökéletesen konvertálható Libréből, Softmakerből. Softmaker xlsx Libre korrektül megnyitja, s konvertálható xls-be onnan is.
      A hiperlink teljes félreértés, egyszerűen az adott könyv címére van “ráültetve” hogy kattintva táblázatból is induljon. Képletekben semmi szerepe. A bajom nem az, ha valami valamit nem tud, de akkor ne ígérje. Ha nusikák azt látják, hogy egy prog ment …-ben, joggal tételezik fel, hogy azt korrektül teszi. Ha nem képes rá — bármiért — akkora “szakembör” hívja fel a figyelmét. Ha én nem tudok csapot szerelni, az kínos (béna is vagyok), de addig, amíg nem adom ki magam szerelőnek, addig nem számít. Ha a kihívott szerelőszaki kioktat arról, hogy rossz a csaptelep, rossz a vezeték stb. s az ő eszköze a legjobb, míg minden más nem — viszont a csap nem műxik, az igenis gond. Elég sok LO-jellegű progival volt — van — dolgom, de csak az LO-nál (néha az az OO is) érzem magam agyonfrusztrálva, átverve. A Softmaker office -LO rokonsága egyértelmű, de ott semmi ilyen gondom nincs. Amúgy az is egy teszteletlen, ostobán bugos, amit egy kicsit szokni kell. Előregyártott sablonokat nem tudok kialakítani, mert kötetenként más-más minden, stílusokat, billentyűkombinációkat kreálgatok egységesen oldalszám, bekezdés formázásához. Nem a programozóval, meg nem Nusikával van baj, ha mindegyikük a maga szerepkörében marad, s esetleges hibáit nem a másikra akarja tolni. Sok, nehézkes, de általában primitív dolog OCR-es anyagot korrektúrázni s csak a hatékonyság számít. Márpedig ha “A” progiban Nusi 3 kattintással megold mindent, akkor uő “B” progiban nem makrót fog írni, sablonokat kerülőutakat tervezni, hanem … Bocs a terjengésért.

  12. Még csaknem 2 órát libréztem…
    “Felkiáltójeles elválasztó karakter nincs az .ods formátumban. Ez egy .xls fájl, amit a LO-nak folyton konvertálgatnia kell megnyitáskor is, mentéskor is. És a formátumok közötti áthidalhatatlan inkompatibilitások miatt minden egyes konverziónál romolhat a helyzet.”
    Inkriminált file xlsx-ből elmentve ods-be Microsoftból. Ugyanez az ods file megnyitva Microsoftból kifogástalan, képletek, számok MINDEN OK. Ugyanez az ods file megnyitva LO-ból: a file tökéletes, ahogy kell, MINDEN OK, konverziós hiba nincs. Persze, az LO hibátlan, az ods-export filtere hibátlan, csak épp az eredmény rossz — ami a program kiválóságát mutatja, s ez csak akkor jelentkezik, ha NEM lLOban nyitjuk meg. LO forever, nincs menekvés a csapdájából?

    1. Frissíted a hivatkozásokat a megnyitás után? A programokban – a LibreOffice Calc-ban is – van olyan lehetőség, hogy az idegen formátumokban, és/vagy az idegen szerkesztővel szerkesztett fájlokban nem végzi el megnyitás után automatikusan az újraszámolást, a beállításoktól függően persze. Ilyenkor erőltetni kell az újraszámolást.

      A fájlodat egyébként letöltöttem .ods és .xlsx formátumban is, és UTÁNA megnyitottam azokat. Mindkettőben ott voltak a képletek a B oszlopban, de nem mindenhol volt azonos az eredmény a C oszlopba fixen bevitt számokkal.
      Megnyitottam mindkét fájlt LO 6.1.6, LO6.2.5 és LO6.3.0 verziókkal is. Utóbbiak X-LO verziók. Ha a hivatkozott tartományban változtattam az adatokon, szépen frissült az eredmény is.

  13. Szóval: a letöltött file a mindennap használt (MOffice nyilvántartásom, xlsx-ben. A linkeknél (elnézlst, itt a Softmaker-tapasztalatok keverednek). Az xlsx-formátum a gond. A frissítés mindig/automatára van állítva, de a “csak kérés” opciót használva sincs változás. Az MSO-t mindkét program jól nyitja, de ha ebben a formátumban mentek, az MSO-ban nem nyílik meg. Azt gondolom, hogy a link url-ként felfogva körül lehet a gond, mert a “linketlen” állomány rendben. Softmakerben mentett xlsx-et LO tökéletesen nyitja, azt xls-be mentve minden rendben MSO-val. Szóval az LO bemeneti konverzója rendben. MSO-ból akár xlsx, akár ods-file rendben nyit, ment. Viszont ha LO-s ODF-et nyitok meg MSO-ban, akkor jelentkezik az eltűnt képlet. Gyakorlatilag mint mikor beszúrásnál választhatunk, értéket vagy képletet szúrjunk be. Ugyanez nem jelentkezik, ha LO-ban xls, tehát a régi formátumot használjuk, vagy akár csak arra konvertálunk át. Azt már csak zárójelben jegyzem meg, hogy pl. Softmaker-MSO-LO viszonylatában az odt sem korrekt: az MSO-é jó, a Softmaker formátumhibás, ami azért érdekes, mert ez elvileg “szabad” és kompatibilisnek szánt. A doc és xls verziókkal nincsenek gondok oda-vissza egyiknél sem!

Vélemény, hozzászólás?

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