Jak: word joiner/no-width no brake/CTL support?

[Sei]

Problem jest następujący i stary jak świat: zrobić niepodzielną spację, która do tego przy justowaniu tekstu będzie zmieniała szerokość.
Znalazłem następujące rozwiązanie: wstawić no-width no brake albo word joiner (nie będę próbował tłumaczyć na polski, bo jeszcze bardziej pokaleczę język) co w praktyce oznacza, że dwa słowa/znaki przyległe z obu stron tych znaków są "sklejone". Wtedy widzę to na przykład tak: "Ala ma kota i<word joiner><spacja><word joiner>psa". Przy takiej konstrukcji łącznik "i" w zdaniu nie zostanie mi nigdy na końcu linii, a przy justowaniu tekstu spacja międzu "i", a "psa" zmienia swoją szerokość.
Dalsze poszukiwania pozwoliły mi stwierdzić, ze wstawianie no-width no brake we Writerze jest proste (przepraszam za menu po angielsku, ale mam nową wersję OO i nie ma jeszcze tłumaczenia na polski):
Insert (Wstaw)=> Formatting mark (Znaki formatowania?)=> no-width no brake
Problem jest taki, że tej opcji w menu nie ma jeśli nie jest włączona zaawansowana edycja tekstu: Tools/Narzędzia=>Options/Opcje=>Language Settings/Ustawienia języka?=>Languages/Języki => zaznaczyć pole "Enabled for Complex Text Layout (CTL)". I tu powstaje problem bezpośrednio tego pola nie mam. Coś podobnego to zakładka rozwijana lista CTL, na której wyświetlony jest język Hindi i która jest nieaktywna.

P.S. Chyba, że istnieje rozwiązanie pozwalające automatycznie przenieść pojedyncze znaki z końca linii na początek następnej linii? Może jest jakaś opcja w formatowaniu akapitu podobna do zezwolenia na dzielenie wyrazów.

[Jan_J]

AFAIK aktualnie nie ma dobrego sposobu na elastyczne odstępy klejące.

Sposób z uleastycznieniem spacji NBSP (u+00a0) byłby optymalny, ale dawno temu został odrzucony przez opiekunów OOo. Patrz https://issues.apache.org/ooo/show_bug.cgi?id=89129.

Sposób z ZWJ (u+2060) jest w zamyśle dobry, ale wskutek nieudanej obsługi tego znaku w algorytmie składania akapitu efekt bywa komiczny. Patrz burzliwa swego czasu dyskusja u nas http://forum.openoffice.org/pl/forum/vi ... p?f=8&t=63, w której zresztą miałeś okazję brać udział.

Do dziś tak jest. W załączeniu dokument z ZWJ-tami. Niby dobrze, ale jeśli do wyróżnionego wiersza wstawisz spację, to słowo z ZWJ-tem cofnie się z następnego wiersza do bieżącego. Jest ewidentny błąd w rachunkach przy obliczaniu wypełnienia wierszy.

useZWJ.odt

(11.19 KiB) Pobrany 322 razy

W bieżącej liście życzeń LibreOffice jest “paragraph-level justification”. Patrz np. http://numbertext.org/linux/LibOConf2011_DTP.pdf oraz https://bugs.freedesktop.org/show_bug.cgi?id=38159. Jego realizacja dałaby LO znaczną przewagę nad konkurencją. W takim przypadku byłaby duża szansa, że problem elastyczności się rozwiąże -- czy to z użyciem NBSP, czy ZWJ. Ale terminów nie ma, jest tylko pomysł.

[Minio]

W bieżącej liście życzeń LibreOffice jest “paragraph-level justification”. Patrz np. http://numbertext.org/linux/LibOConf2011_DTP.pdf oraz https://bugs.freedesktop.org/show_bug.cgi?id=38159. Jego realizacja dałaby LO znaczną przewagę nad konkurencją. W takim przypadku byłaby duża szansa, że problem elastyczności się rozwiąże -- czy to z użyciem NBSP, czy ZWJ. Ale terminów nie ma, jest tylko pomysł.

Skoro potrafią to LaTeX i Scribus, to znaczy, że istnieją już open source'owe algorytmy do wykonywania tej czynności. Czyli najtrudniejsza praca jest już wykonana. Teraz trzeba tylko te algorytmy zaimplementować w LO.

Czy ktoś się może orientuje, ile za zlecenie implementacji takiego algorytmu w LO mógłby wziąć dobry programista? Oczywiście nie mówimy o dokładnych kwotach, tylko przedziałach.
Zastanawiam się, czy nie udałoby się zorganizować jakiejś zrzutki na ten cel. W końcu wszyscy byśmy na tym skorzystali.

[Jan_J]

Skoro potrafią to LaTeX i Scribus, to znaczy, że istnieją już open source'owe algorytmy do wykonywania tej czynności. Czyli najtrudniejsza praca jest już wykonana. Teraz trzeba tylko te algorytmy zaimplementować w LO.

“Od zawsze” było tak, że dobrze wyszkolony i inteligentny zecer potrafił przewidzieć, w jaki sposób sterować odstępami, tak by wiersze w całym akapicie miały w miarę jednolity wygląd (czasem działo się to ze szkodą dla tekstu, o ile płacono mu od wiersza -- ale to już inna historia). W składzie komputerowym pojawiły się trudności, jak to zasymulować algorytmicznie.

O ile wiem, pierwszym, który rozwiązał problem składania akapitów jako całości, wraz z przenoszeniem wyrazów i łączeniem liter w ligatury, był Donald E. Knuth na początku lat 80-tych XX wieku. Jego algorytm, zastosowany w TeX-u, do dziś jest niedościgniony. Ciekawe, że od początku był on licencjonowany jako Public Domain. Całkiem niedawno jego idee zostały wykorzystane w ramach systemu Adobe InDesign.

Ani Scribus, ani Quark Xpress, nie mówiąc już o pakietach biurowych, czegoś takiego nie mają.

Oczywiście, elastyczna spacja klejąca jest osiągalna w każdym z tych programów, choć nie zawsze w oczywisty sposób. Była kiedyś ciekawa dyskusja na temat tego symbolu i jego użycia na grupie pl.com.dtp; zamieszczam link: http://www.digipedia.pl/usenet/thread/81/405635.

<edit>
Algorytm Knutha zaimplementowany w JavaScript: patrz http://www.bramstein.com/projects/typeset/
Czyli przeglądarki WWW właściwie też już by mogły...
</edit>

[Minio]

Jan_J: OK, być może dostępność tego algorytmu w Scribusie sobie wymyśliłem (lub coś źle zrozumiałem). Niemniej główne pytanie pozostaje ważne i bez odpowiedzi:
skoro odpowiedni algorytm już istnieje i każdy może go podejrzeć, to pozostaje „tylko” zaimplementować go w LO; ile orientacyjnie coś takiego mogłoby kosztować?

Wydaje mi się, że między innymi na tym polega siła oprogramowania o otwartym kodzie źródłowym — jeżeli brakuje jakiejś funkcji, to możesz sam ją napisać, lub — jeśli nie potrafisz — zapłacić komuś, kto zrobi to za Ciebie.

Oczywiście, elastyczna spacja klejąca jest osiągalna w każdym z tych programów, choć nie zawsze w oczywisty sposób.

W odniesieniu do LO/AOO: masz na myśli dyskutowaną tutaj i w linkowanym wcześniej wątku technikę ZWJ+spacja, czy coś innego?

[Jan_J]

O justowaniu akapitu jako całości

[...]być może dostępność tego algorytmu w Scribusie sobie wymyśliłem (lub coś źle zrozumiałem).

Scribus ma kilka rzeczy wzorowanych na TeX-u, potrafi też składać ramki, których wypełnieniem zajmuje się TeX.
Od czasu do czasu w różnych miejscach pojawiają się wpisy, jakoby Scribus był też wyposażony w algorytm justowania na poziomie akapitów. Ale w dokumentacji nic o tym nie ma, a Ile razy sprawdzam Scribusa, to też nic takiego w nim nie widać.

O elastycznych odstępach

masz na myśli dyskutowaną tutaj i w linkowanym wcześniej wątku technikę ZWJ+spacja, czy coś innego?

w OOo/LO obecnie żaden sposób nie jest skuteczny. W Scribusie i w TeX-u spacja klejąca jest elastyczna. Chyba że użyjemy sztywnej spacji -- jest ona całkiem innym obiektem.

O opłaceniu programisty
Co nieco wiem o algorytmach, ale nie jestem zawodowym programistą; nie znam ani technik szacowania pracochłonności takiego przedsięwzięcia, ani aktualnych stawek.

[Sei]

Dziękuję za odpowiedzi.
Pamiętam poprzednie dyskusje o twardych spacjach i wnioski, że "tak się nie da". Po prostu ostatnio przypadkiem trafiłem na informacje o tych znakach, a że nie mogłem tego u siebie "uruchomić" to myślałem, że coś źle robię. Informacje na jakie trafiłem o tych znakach dotyczyły chyba starszych wersji OO. Czy to znaczy, że kiedyś to działało i przestało czy po prostu nigdy naprawdę nie działało?
W każdym razie pozostaje trzymać się "twardej spacji" i się z tym pogodzić.

Co do pełnego uleastycznienia twardej spacji to bym się jednak przychylał do stanowiska opiekunów OO. Czasem mi się zdarza jej używać np. przy ręcznym wypunktowaniu. Wtedy taka spacja wstawiona po np. myślniku powoduje, że tekst zaczyna się zawsze w tym samym miejscu. Wiem, że można to zrobić automatycznym wypunktowaniem ze znakiem, ale często tak jest dłużej. Szczególnie przy pojedynczych i krótkich listach. Inny przypadek to odstęp np. między liczbą, a jednostką (było to wspomniane w tamtej dyskusji, ale w innym kontekście). Jeśli spacje przy justowaniu linijki się mocno wydłużają to według mnie dziwnie wygląda np.
"23______ mm" zamiast
"23 mm". Choć to może kwestia gustu.

Jeszcze co do załączonego pliku ZWJ. Rzeczywiście następuje cofnięcie, ale czy nie jest to dość szczególny przypadek? Może mi powiedzieć jak wstawia się te znaki?

[Jan_J]

@ twarda spacja i jej szerokość.
Jasne, że w zwrotach "10~000", "24~m", "jak napisał W.~M.~Krukowski" i "a~u~nas stara bieda", a przynajmniej w ich docelowej wersji, winny znaleźć się różne rodzaje spacji. Czy system, którego używamy, sprzyja takiej specjalizacji?
UNICODE zna pojęcia spacji o stałej szerokości: em-space, en-space, thinspace, hair-space itp. W tym także standardowe spacje na 1/3 i 1/4 firetu. Natomiast spacja niełamliwa U+00A0 nie ma w standardzie określonej szerokości.

@ jak to kiedyś było
Przyznam, że tu akurat nie pamiętam. Ale sądzę, że raczej nie działało.

@ ZWJ i wypełnianie linii
Nie, to nie są specyficzne sytuacje. Zasadność użycia ZWJ wiąże się z tym, że ma on nigdy nie wystąpić na końcu wiersza. Zaś przytoczony plik -- z durnowatą oczywiście zawartością -- ilustruje sytuację, kiedy jednoliterowiec z doklejonym ZWJ (chcemy go przecież skleić z tym, co następuje po nim) zostaje siłą przepchany do poprzedniego wiersza, i to dlaczego? a bo w tym poprzednim wierszu włożyliśmy coś, więc zrobiło się w nim ciaśniej. Bzdura. Na dodatek taki felerny wisielec kończy wiersz właśnie ZWJ-tem, co przeczy sensowności jego stosowania.

W kodzie ustanawiającym przełamania wierszy w bloku akapitowym uwzględnienie ZWJ-tów jest potraktowane bardzo topornie; wygląda mi wręcz na doraźną łatę, która trzyma się tyle lat.

@ jak wstawić ZWJ
Sprawdzałem skuteczność użycia odpowiednich znaków UNIKODU w dokumentach OpenOffice. Nie ma w tym momencie wygodnego interfejsu, ale łatwo sobie wyobrazić: skróty klawiszowe użytkownika, skrót klawiszowy pakietu, a nawet wpis w menu. W razie potrzeby także zmiana układu klawiatury, co jest od Writera niezależne.

[Sei]

Dziękuję za odpowiedź.
Czyli właściwie tak jak już kiedyś zostało wykoncypowane: trzeba się trzymać "twardej spacji" w jej obecnej postaci i na razie nic więcej nie da się z tym za bardzo zrobić.

[SledgehammerPL]

UWAGA UWAGA! ROZWIĄZANIE PROBLEMU spacja niełamliwa rozciągliwa!!!

Kolega z początku miał rację ale nie był dość zdeterminowany - rozwiązanie jest banalnie proste:

Otóż wchodzimy do Narzędzia/Opcje/Ustawienia językowe/języki/

zaznaczamy złożony układ tekstu (CTL) i z listy wybieramy Brak (nie wiem czy ma to znaczenie, ale Brak brzmiało najsensowniej)

zamykamy Opcje i w polu Wstaw/Znacznik formatowania pojawiają się dodatkowe opcje między innymi łącznik nierozdzielający zerowej szerokości - wstawiamy go miedzy literę i spację np. "i<łącznik><spacja>dlatego".

Być może jest to U+2060 ale nie wiem jak go wywołać z klawiatury (Windows) bo ALT+2060 daje ♀

Nie mniej jednak ten łącznik da się używać w kopiuj wklej (czyli <spacja>o<spacja> => <spacja>o<łącznik><spacja>) daje doskonałe efekty

Peany na moją cześć proszę wysyłać na facebooka ;D
https://www.facebook.com/Tomasz.Brzezin ... 8646998964

[Jan_J]

Pean peanem, piałbym chętnie, ale problem pozostaje.
Chodzi o to, że gdy taki wiersz zbliża się do krytycznej gęstości tekstu, skład głupieje. Dopisanie czegoś dodatkowego, np. zwykłej spacji, ale może to być też litera, sprawi, że zamiast przerzucić część tekstu do następnego wiersza (co by go rozgęściło), raczej przerzuca część tekstu Z NASTĘPNEGO wiersza do bieżącego -- przeładowując go ponad miarę. To znaczy, że metoda działa, ale zawodzi w szczególnych przypadkach.
W naszych starych wątkach znajdziesz pliki testowe prezentujące ten błąd. Jest on również zgłoszony na bugzillę Libre. Ale do usunięcia trzeba by przepisać algorytm składu, a na to brak chętnych.

[SledgehammerPL]

W zasadzie tak, ale nie do końca - zauważyłem, że problem pojawia się głównie wtedy, kiedy algorytm musi rozstrzygnąć dylemat - czy ma to wyglądać ładnie czy bezwarunkowo nie dzielić. Szczególnie gdy kolumna jest wąska i nie bardzo jest jak rozstrzelić tekst np. "zdecydowanie i szybko" - a kolumna jest na tyle wąska że zmieści się tylko "zdecydowanie i" - no i jak rozstrzelić jeden wyraz? Wtedy algorytm wybiera "ładnie" i zostawia "zdecydowanie i". (można go zmusić robiąc CTRL+ENTER i faktycznie wygląda to szpetnie - ale zgodnie z zasadami. Niemniej jednak w normalnym tekście tylko raz na chyba 340 razy zrobił źle - ale tam też lepiej wyglądałoby gdyby zostawił na końcu jedną literę.

Najważniejsze - że w ogóle da się wstawić ten cholerny znak, bo szukałem metody cały dzień, a kolega z pierwszego posta naprowadził mnie na właściwy kierunek.

[Astur]

Chodzi o to, że gdy taki wiersz zbliża się do krytycznej gęstości tekstu, skład głupieje.

Czy ta "krytyczna gęstość tekstu" ma jakąś miarę, którą można zdefiniować? Chodzi mi o wprowadzenie do makro warunku badającego ową krytyczność.

W wypadku "niekrytycznym" istotna część makra wyglądałaby tak:

Kod: Zaznacz cały

dispatcher.executeDispatch(document, ".uno:InsertZWNBSP", "", 0, Array())
dim args3(0) as new com.sun.star.beans.PropertyValue
args3(0).Name = "Text"
args3(0).Value = " "
dispatcher.executeDispatch(document, ".uno:InsertText", "", 0, args3())

..a w wypadku "krytycznym" - tak:

Kod: Zaznacz cały

dispatcher.executeDispatch(document, ".uno:InsertNonBreakingSpace", "", 0, Array())

[Jan_J]

Chodzi o to, że gdy taki wiersz zbliża się do krytycznej gęstości tekstu, skład głupieje.

Czy ta "krytyczna gęstość tekstu" ma jakąś miarę, którą można zdefiniować? Chodzi mi o wprowadzenie do makro warunku badającego ową krytyczność.

Tak, ma.
W przypadku spacji o założonej minimalnej szerokości chodzi po prostu o to, czy dany ciąg „zmieści się” w wierszu. Owa minimalna szerokość może być „naturalną” szerokością spacji (w wydawnictwach normatywnych często jest zalecana wielkość em/3), albo wielkością „naturalną” zredukowaną o pewien czynnik.
Na dodatek przy zastosowaniu zaawansowanych technik fontowych (kerning, ligatury) oraz znaków opcjonalnych (np. łączniki przy przenoszeniu) szerokość tesktu nie jest równa sumie nominalnych szerokości znaków.
Te obliczenia we Writerze zaimplementowano w sposób uproszczony, co sprawia, że niektóre znaki (jak ZWJ) prowadzą do błędnego szacowania i przegęszczania tekstu w wierszu.
Wszystko to jest sprzężone dość głęboko z algorytmem składu, więc nie bardzo wierzę w efektywną naprawę za pomocą makra.