przystajnik

Czy to już? LibreOffice 6.2.0

Na wiele rzeczy czekamy z utęsknieniem, ale chyba na pierwszym miejscu w sercu każdego z nas jest LibreOffice. Tak można wnioskować po krytyce jaka spada na ten projekt za przeróżne zaniedbania. A to nowa wersja wychodzi za późno, a to za wcześnie, a to nadal źle renderuje docx. Lub wygląda tak jak OpenOffice 20 lat temu. Aż tu nagle pojawia się LibreOffice 6.2.0 i… No do czego by się tu przyczepić?

LibreOffice i akcenty w interfejsie

Pomyśleć tylko, że jest z 15 lat temu do wyboru mieliśmy jedynie wiodący pakiet biurowy, OpenOffice i gdzieś tam przemykało wspomnienie o dniach chwały Lotusa lub StarOffice. Na Linuksie to było nawet prościej – tylko OpenOffice. I nagle budzimy się w rzeczywistości z LibreOffice na pulpicie oraz multum innych pakietów biurowych (OnlyOffice, WPS Office, SoftMaker FreeOffice).

LibreOffice 6.2.0 jest wydaniem przełomowym nie tylko ze względu na numerację. Zawiera wiele poprawek i usprawnień które zbliżają go do oczekiwań użytkowników. A czego oczekiwaliśmy? Zmian w interfejsie? Proszę bardzo.

Nowy tryb Tabbed (alias Notebookbar) to niemal spełnienie marzeń wszystkich tęskniących za wstążką. To temat rzeka, bo taką drogę przebył też interfejs programu. Różne próby „ucywilizowania” go doprowadziły nas do stanu, gdzie w miarę sami możemy decydować na ile wstążka ma wyglądać jak chcemy (Tabbed, Groups oraz Contextual). Ale już samo grupowanie funkcji w kartach powinno nas cieszyć. Jak na konserwatyzm LibreOffice to niemal nowa jakość.

Jednak poprawki wizualne we wszystkich komponentach pakietu to nie wszystko. Użytkownicy KDE ucieszą się z lepszej integracji ze swoim ulubionym środowiskiem. Dodatkowo wszystko będzie wyglądało o niebo lepiej na wyświetlaczach HiDPI. Poprawiło się działanie importu i eksportu prezentacji, wektory renderują się tak jak należy. Dokumenty tekstowe przyjmują dane z arkuszy (wklejanie tabel), poprawiła się obsługa wyrażeń regularnych. Menu kontekstowe stały się bardziej kompaktowe i przejrzyste. Oraz inne niuanse.

Czy to oznacza, że poza wyglądem niewiele się zmieniło? Nieprawda. Poprawki i dodatki to znaczący krok naprzód i staną się one udziałem każdego z nas. Innymi słowy, każde znajdzie coś dla siebie.

Aby zainstalować program możemy podążać za działem Download na stronie projektu. Znajdziemy tam paczki deb i rpm. A niekiedy wystarczy zaczekać na aktualizację repozytoriów (Ubuntu/Mint):

sudo add-apt-repository ppa:libreoffice/ppa
sudo apt-get update
sudo apt-get install libreoffice

 

Post navigation

14 comments for “Czy to już? LibreOffice 6.2.0

  1. pavbaranov
    8 lutego, 2019 at 23:29

    „Użytkownicy KDE ucieszą się z lepszej integracji ze swoim ulubionym środowiskiem” – tzn. jakiej?

  2. Angry Penguin
    8 lutego, 2019 at 23:50

    Zacytuję:

    KDE 5 + Qt5

    Two new VCL plugins (qt5 and kde5) have been
    implemented (with the KDE5 plugin extending the Qt5 one) to provide
    integration into KDE Plasma 5 and other Qt5-based desktop environments,
    mainly implemented by Katarína Behrens (CIB) and Jan-Marek Glogowski
    (City of Munich).

    If the kde5 and the gtk3_kde5 plugins are installed, the desktop detection will now prefer the kde5 one. The qt5 plugin must be explicitly selected via SAL_USE_VCLPLUGIN=qt5, as it’s never selected automatically.

    Currently implemented features include:

    Native widget rendering

    Native Plasma file and folder picker

    Native menus including Plasma global menu integration

    Dual screen support

    System clipboard integration

    Basic native drag’n’drop

    Basic accessibility support (Samuel Mehrbrodt, CIB)

    Bugs and missing features are tracked via the KDE meta bug tdf#102495.

    Technical note: The qt5 plugin implements two rendering paths:
    an experimental QPainter based one and the Cairo based one, which is
    also used by all other Unix plugins. The kde5 plugin uses only the Cairo rendering path. The qt5
    plugin defaults to the QPainter rendering path, but it’s possible to
    force the Cairo path using the environment variable
    SAL_VCL_QT5_USE_CAIRO.

  3. adamserce
    9 lutego, 2019 at 3:42

    Paczki *.deb ze strony polskiej:
    https://pl.libreoffice.org/pobieranie/

  4. pavbaranov
    9 lutego, 2019 at 11:56

    Thx. To znam, myślałem, że @salvadhor wynalazł jakieś inne.
    A szczerze, to jak na razie nie zauważyłem większej różnicy pomiędzy SAL_USE_VCLPLUGIN=qt5 a gtk3_kde5, ale zbyt krótko jeszcze LO6.2 u mnie działa.
    Pamiętać należy, że na systemach, gdzie LO „zobaczy” Plazmę qtk3_kde5 zostanie zastosowany domyślnie. Plugin qt5 trzeba zawsze ręcznie ustawić (np. w /etc/profile.d/libreoffice-fresh.sh/zsh).
    Zdaje się, że którykolwiek z tych pluginów należy również ustawić w środowiskach innych niż Plasma, a wykorzystujących Qt5 jako podstawę swojego działania (np. LXQt, Lumina, Liri) jeśli się chce ten efekt osiągnąć, bowiem inaczej LO będzie chciało wystartować z VCLPLUGIN=gtk3, a jeśli tego nie znajdzie w systemie (raczej mało prawdopodobne), następne w kolejce będzie gtk2, a jeśli i tego nie znajdzie, to tzw. gen (wygląd lekko podobny do aplikacji napisanej w java).

  5. icywind
    9 lutego, 2019 at 14:48

    Aby zainstalować program możemy podążać za działem Download na stronie projektu. Znajdziemy tam paczki deb i rpm. A niekiedy wystarczy zaczekać na aktualizację repozytoriów (Ubuntu/Mint):

    Można również skorzystać z flatpakowej wersji którą znajdziemy w repozytorium flathub 🙂

  6. Angry Penguin
    10 lutego, 2019 at 0:15

    No tak, ale jeżeli twoja dystrybucja oferuje już aktualizację do LO 6.2 to lepiej wykonać aktualizację w ten sposób. Jeżeli nie to zostają paczki .deb lub .rpm – kolejna preferowana droga. Dopiero kiedy system nie obsługuje .deb ani .rpm lub paczki nie chcą się zainstalować z różnych względów wówczas dopiero ja bym myślał o Flatpak. No bo po co „dociągać” od groma zbędnych zależności, kiedy mamy już je w systemie?

  7. gambu00
    10 lutego, 2019 at 20:30
  8. pavbaranov
    11 lutego, 2019 at 9:25

    Jeśli appimage, to – w warunkach polskich – polecam raczej skrypt, który z deb stworzy AppImage. W przypadku oficjalnych wersji LO AppImage, by je mieć w polskiej wersji językowej musimy ściągnąć tzw. full version, z wszystkimi paczkami językowymi, co najczęściej nie jest potrzebne. Proponowane rozwiązanie umożliwia budowę appimage LO „pod siebie”.
    Więcej: http://linux-pavbaranov.blogspot.com/2017/12/zbuduj-sobie-libreoffice-appimage.html
    (działa, wielokrotnie wypróbowane; skrypt ma też możliwość budowy wersji developerskich, można zatem dość wcześnie albo zobaczyć co w nadchodzących, albo uzyskać funkcjonalność, której nam brakuje nawet we fresh, a akurat jej potrzebujemy).

  9. Piotr
    12 lutego, 2019 at 10:02

    Libre Office to ciekawy projekt. Jednak ma problemy z dokumentami M$ Word, szczególnie zawierającymi grafikę, tabelki itp.

  10. zbgns
    12 lutego, 2019 at 11:35

    W drugą stronę jest pewnie jeszcze gorzej… To już polityka monopolisty, żeby nieułatwiać konkurencji zadania i niedopuścić do pełnej zgodności z konkurencyjnymi pakietami.

    Z drugiej strony, z tą kompatybilnością LO Writer vs. MS Word wcale według mnie sprawa tak źle nie wygląda. Nawet jeśli się coś rozjeżdża, to zwykle trochę i da się to stosunkowo prosto poprawić. Coś takiego występuje nawet w obrębie MS Office w różnych wersjach. Kiedyś otwierałem taki trudny dokument Worda w LO Writer, WPS Office i jeszcze czym (chyba Only Office) i wszędzie pojawiły się błędy w odczycie, przy czym te w LO Writer były najmniej uciążliwe. Także z dużą nieufnością odnoszę się do opinii, że np. WPS Office jest bardziej kompatybilny z MS Office. Wrażenie zgodności wynika chyba głównie z podobieństwa interfejsu (te same skróty klawiaturowe, podobna notacja przy wyrażeniach regularnych), a nie z wiernego odwzorowywania dokumentów z MS Offica.

  11. pavbaranov
    12 lutego, 2019 at 23:05

    A o którą wersję Kolega ma na myśli?
    Dodatkowo – standardem OTF. Niech zatem łaskawie MS pochyli głowę. Mimo swej hegemonii.

  12. Piotr
    13 lutego, 2019 at 9:39

    Mam na myśli tę najnowszą wersję LO i dokumenty doc (MS Word 97-2003). W przypadku nowszych docx jest chyba podobnie. Prosty tekst nie sprawia problemów, ale już wstawione grafiki, tabelki itp. powodują błędy formatowania. Niekeidy można poprawić. Jednak gdy ktoś np. prześle nam taki dokument, to nie wiemy jak wyglądał w oryginale.

  13. zbgns
    13 lutego, 2019 at 12:17

    Ale tu chyba błąd jest już w założeniu wysyłającego dokument. Jeśli zależy mu, żeby wygląd dokumentu (a nie tylko treść tam zawarta) odpowiadał temu co sam przygotował i widzi u siebie, to powinien użyć formatu, który daje realne szanse na uzyskanie takiego samego efektu wizualnego u odbiorcy. Format .doc lub .docx (podobnie jak .otf) nie ma takiej cechy, więc nawet jeśli wiadomo, jakiego oprogramowania będzie używał odbiorca, to i tak nie można bezkrytycznie zakładać, że u odbiorcy taki dokument zinterpretuje się identycznie. Przykładowo, plik może być utworzony z wykorzystaniem fontów, których nie ma zainstalowanych na komputerze u odbiorcy. Bardziej adekwatne byłoby skonwertowanie dokumentu np. do formatu .pdf.

  14. pavbaranov
    13 lutego, 2019 at 21:33

    Zgłoś zatem bug na stronie MS by otworzyli format doc. Inaczej się nie da.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »