Žodis „penktadienis“ skiemenuojamas neteisingai

[Rimas Kudelis]

Žodį „penktadienis“ siūloma labai keistai skiemenuoti: pe-nk-ta-dienis. Ar tai nebus hyph_lt_LT.dic failo trūkumas?

[Laimonas Vėbra (laimis)]

Hm, pagal:
https://wiki.openoffice.org/wiki/Documentation/SL/Using_TeX_hyphenation_patterns_in_OpenOffice.org

sugeneravau naują failą tikėdamasis, kad repozitorijoje jau pasenęs. Bet gi ne, beveik identiškas; pattern'ai nekeisti jau eilę metų.

Vienintelis skirtumas, kad hyphen-2.8.8 po koduotės dar įterpia dvi eilutes antraštėje:
LEFTHYPHENMIN 2
RIGHTHYPHENMIN 2

Na ir gal reikėtų pabandyti su utf-8 (matyt laikas jau ir perkonvertuoti)?
Prikabinu utf-8 variantą.

[Laimonas Vėbra (laimis)]

 Automatinis skiemenavimas LibreOffice'e veikia, atrodytų, korektiškai. Jei labai susiaurini paragrafą, tai tuomet po dvi raides ir skiemenuoja: „pe-nk-ta-die-nis“, bet šiaip skelia ten, kur ir tikiuosi.
O keistai siūlo skiemenuoti per Tools->Language->Hyphenation; nepagaunu sistemos.

[Rimas Kudelis (rq)]

Manyčiau, kad kaip tik tas rankinis skiemenavimo variantas yra aktualesnis, nes būtent jis parodo, kuriose vietose GALĖTŲ būti atskiriami skiemenys.

Dėl upstream failo – tu iš čia ėmei:
http://mirror.datacenter.by/pub/mirrors/CTAN/language/hyph-utf8/tex/generic/hyph-utf8/patterns/tex/hyph-lt.tex ?

Beje, ar yra koks nors įrankis, galintis parodyti, kuriomis taisyklėmis remiantis, vienas ar kitas žodis būtų suskiemenuotas?

Beje, žodį „penklinė“ irgi skiemenuoja gan kvailai: pe-n-klinė. Nežinau, koks yra jo teisingas skiemenavimas, bet tikrai manau, kad ne toks.

[Laimonas Vėbra (laimis)]

Upstream failą ėmiau iš kažkurios oficialios CTAN repozitorijos; kaip jau rašiau, jis tiesiog nebuvo keistas jau eilę metų. Ir šis toks pats: keistas tik 2008'ais (po 2000'ųjų) ir tai tik kosmetiniai keitimai (ne taisyklių).
Sutinku, kad rankinis skiemenavimas keistas (bent jau neaiški sistema, kodėl siūlomi tokie kreivi variantai), tačiau tai veikiausiai ne hyph, bet Libre problema, jei jau automatinis skiemenavimas veikia korektiškai.
Dėl hyph įrankių nieko negaliu pasakyti; net nesigilinau į taisykles, nors esu beveik įsitikinęs, kad jose nėra problemos. Tokie akivaizdūs TeX skiemenavimo taisyklių trūkumai jau seniai būtų pastebėti (reiklesnė publika ir tam buvo bene 20 metų) ir pataisyti, juolab, kad automatinis skiemenavimas, naudojant tas pačias taisykles, veikia korektiškai.
Gal kada rasiu laiko užmesti akį į Libre kodą, ką tas rankinis skiemenavimas daro skirtingai nuo automatinio.
Beje, ar bandei su utf-8 variantu, kurį prikabinau?

[Rimas Kudelis (rq)]

Rankinis skiemenavimas manau vis dėlto yra hyph problema, o LibO tiesiog parodo, kurioje vietoje hyph taisyklės leidžia skelti žodį (kas automatinio skiemenavimo metu galbūt ne visada matosi, o galbūt yra to paties LibO kokiu nors būdu optimizuojama).

Su tavo failu berods nieko nebandžiau, nors nesu tikras.

O gal yra kokia nors konsolinė arba GUI programa, kuri galėtų suskiemenuoti tekstą, pasinaudodama hyph taisyklėmis? Būtų manau geriausia su tokia pabandyti. Aš iki šiol turiu tokią seną 16 bitų programėlę pavadinimu „Skie-muo“. Tai va gal yra kažkas panašaus, tik šiuolaikiško ir legalaus? :)

[Laimonas Vėbra (laimis)]

Skiemenuoti gali tas pats hunspell hyphen, kurį naudoja LibreO ir kt.:
http://sourceforge.net/projects/hunspell/files/Hyphen/2.8/

Yra pavyzdinė konsolinė programėlė. Pabandžiau su utf-8 hyph_lt_LT.dic:
> example.exe -d hyph_lt_LT.dic words.txt

Penktadienį siūlo skiemenuoti:
penk=ta=die=nis
 - penk=tadienis
 - penkta=dienis
 - penktadie=nis

Čia pirma eilutė — visi skiemenys, o toliau variantai, kaip siūlo skiemenuoti.

Penklinę:
pen=kli=nė
 - pen=klinė
 - penkli-nė

Pabandžiau su LibreO esančiu hyph_lt.dic (ISO8859-13) ir...:
pe=nk=ta=dienis
 - pe=nktadienis
 - penk=tadienis
 - penkta=dienis

:-)
Tai matyt tikrai hyph failo trūkumas arba pačio hyphen klaida (nes nerandu reikalavimo, kad taisyklės būtų utf-8).
Išsprendžiama naudojant utf-8 hyph failą, kurį prikabinau.

[Rimas Kudelis (rq)]

2015.03.23 22:52, Laimonas Vėbra rašė:
>
> Penklinę:
> pen=kli=nė
> - pen=klinė
> - penkli-nė

argi tai teisingas skiemenavimas?

[Laimonas Vėbra (laimis)]

Lyg ir nematau prieštaravimų:
http://www.vlkk.lt/lit/nutarimai/rasyba/zodziu-kelimas.html

[Rimas Kudelis (rq)]

Gal verta tą failą sukomitinti į repozitoriją?

[Laimonas Vėbra (laimis)]

Pridėjau, kaip papildomą (matyt ne visur utf-8 gali tikti ir veikti). Bet klaida liko neaiški; reikia belstis pas hunspell'ą (hyphen)...

[Rimas Kudelis (rq)]

Manau, jog du failus turėti neverta – juk pakeisti jo koduotę ir perrašyti antraštę yra labai nesudėtinga, ir prireikus tai galima automatizuoti.

Dėl klaidos priežasties: iš pradžių aš įtariau, kad gal šią klaidą „paslepia“ tavo minėtosios dvi eilutės failo antraštėje:
LEFTHYPHENMIN 2
RIGHTHYPHENMIN 2

tačiau jas pašalinus, skiemenavimo rezultatas nekinta, tad ši teorija atkrenta (kadangi example teko kompiliuotis, tai padariau tai virtualioj mašinoj):
rq@lubuntu:~/hunspell-hyphen$ ./example lt-LT/hyph_lt_LT.utf-8.2 words.txt
penk=ta=die=nis
ne=penk=ta=die=nis
pen=kli=nė
ne=pen=kli=nė

Kita teorija: tu sakei, kad skiemenavimo taisyklės iš esmės nesiskiria tarp seno ir naujo failo, bet tai netiesa: pakonvertavus iso-8859-13 failą į utf-8 ir palyginus jį su utf-8 failu repozitorijoje, diff'as gaunasi gan nemažas – apie pusantro tūkstančio eilučių, tarp kurių ir štai šios:
-enk4la
-eno1
-ens4
-4enta
+e2n1k
+en3k4la
+e5no1
+e4n1s4
+4en3t2a
+e4n1t

Tuo tarpu paleidus skiemenavimą ir skiemenavimui naudojant pakonvertuotąjį iš ISO-8859-13 failą, rezultatas vis dar yra netinkamas:
./example lt-LT/hyph_lt_LT.dic.utf-8 words.txt
pe=nk=ta=dienis
ne=pe=nk=ta=dienis
pe=n=kli=nė
ne=pe=n=kli=nė

Tad manau, jog esamą ISO-8859-13 failą reikėtų tiesiog pašalinti iš repozitorijos, joje paliekant tik UTF-8 failą. Jeigu matysim, jog tam yra būtinybė, nesunkiai parašysime skriptą, kuris repozitorijoje esantį UTF-8 failą konvertuos į ISO-8859-13.

Beje, tuo pačiu siūlyčiau failą pervadinti iš hyph_lt_LT .dic į hyph_lt.dic, nes mūsų kalba neturi oficialių valstybinių dialektų.

[Laimonas Vėbra (laimis)]

Tiesiogiai konvertuoti NEGALIMA, nes taisyklės turi skaičiukus, kurie, kaip suprantu, reiškia baitų skaičių. Būtent todėl tu gauni kitokias taisykles tiesmukiškai perkodavęs. Jei nori konvertuoti TeX taisykles teisingai, tai daryti reikia pagal:
https://wiki.openoffice.org/wiki/Documentation/SL/Using_TeX_hyphenation_patterns_in_OpenOffice.org

Na, o dėl dviejų failų, tai motyvacija tokia: yra senesnių ofisų, kurie tikrai gali neveikti su šviežiu hyphen; net toje pačioje nuorodoje nurodyta, kad yra/buvo problemų su utf-8 šviežiausiose OO3 (dar palyginus nesenose ) versijose. Matyt iso failas gali būti naudojamas ir dar kur kitur, tad dar kurį laiką negriaukim to, kas ligi šiol veikė (ar buvo naudojama). Tuo labiau, kad reikia pataisyti pačio hyphen klaidą.

[Rimas Kudelis (rq)]

Klysti dėl skaičiukų. Nelyginis skaičius reiškia, kad žodį kelti galima, o lyginis - kad negalima. Didesnis skaičius turi prioritetą prieš mažesnį.

Rimas

On 2015 m. kovas 27 d. 09:36:23 EET, "Laimonas Vėbra" <email address hidden> wrote:
>Tiesiogiai konvertuoti NEGALIMA, nes taisyklės turi skaičiukus, kurie,
>kaip suprantu, reiškia baitų skaičių. Būtent todėl tu gauni kitokias
>taisykles tiesmukiškai perkodavęs. Jei nori konvertuoti TeX taisykles
>teisingai, tai daryti reikia pagal:
>https://wiki.openoffice.org/wiki/Documentation/SL/Using_TeX_hyphenation_patterns_in_OpenOffice.org
>
>Na, o dėl dviejų failų, tai motyvacija tokia: yra senesnių ofisų, kurie
>tikrai gali neveikti su šviežiu hyphen; net toje pačioje nuorodoje
>nurodyta, kad yra/buvo problemų su utf-8 šviežiausiose OO3 (dar
>palyginus nesenose ) versijose. Matyt iso failas gali būti naudojamas
>ir dar kur kitur, tad dar kurį laiką negriaukim to, kas ligi šiol veikė
>(ar buvo naudojama). Tuo labiau, kad reikia pataisyti pačio hyphen
>klaidą.

--
Rimas

[Laimonas Vėbra (laimis)]

Ir vis tik perkoduoti tiesiogiai negalima. O tai reiškia, kad taisyklėse (ir kiek matau, kad būtent taisyklių skaičiukuose: pradžia ir ilgis) įsiūta koduotės specifika, o konkrečiai multibaitiniai reikalai.

hyphen substrings.pl:
# 8 bit or UTF-8 character length (calculating right start position for discretionary hyphenation)
sub enclen {
    my $nonchar = 0;
    my $len = length($_[0]);
    if ($encoding eq "UTF-8") {
        # length of an UTF-8 string equals to the count of the characters not started with '10' bits
        for ($i = 0; $i < $len; $i++) {
            if ((ord(substr($_[0], $i, 1)) >> 6) == 2) { $nonchar++; }
        }
    }
    return $len - $nonchar;
}

[Laimonas Vėbra (laimis)]

Atrodo pagaliau supratau, kur iš tikrųjų yra bėda. :-)
Originalus ispell-lt hyph_lt_LT.dic failas suponuoja, kad jis yra hyphen formato, tačiau iš tikrųjų jis tėra TeX pattern failas, lygiai toks pats, koks guli čia:
http://tug.org/svn/texhyphen/trunk/hyph-utf8/tex/generic/hyph-utf8/patterns/txt/

Taigi, norint, kad jis būtų hyphen formato ir tvarkingai veiktų LibreO ir kt, kur naudojamas hunspell'o hyphen, prieš tai būtina jį praleisti per hyphen'o substring.pl

[Rimas Kudelis (rq)]

> Ir vis tik perkoduoti tiesiogiai negalima.

Klysti, galima. :)

> O tai reiškia, kad taisyklėse (ir kiek matau, kad būtent taisyklių skaičiukuose: pradžia ir ilgis) įsiūta koduotės specifika, o konkrečiai multibaitiniai reikalai.

Ne, skaičiukai reiškia tai, ką aš sakiau. Hyphen distribucijoje doc aplanke yra failas tb87nemeth.pdf. Jo antrame puslapyje tai aiškiai aprašyta. Štai grafinis paaiškinimas:
http://images.devs-on.net/Image/hNdDGcyJOUwiZyF2-Region.png

O štai – tekstinis:
The hyphenation patterns can allow and prohibit hyphenation breaks on multiple levels. Figure 1 shows the pattern matching on the word ‘algorithm’. The T E X English hyphenation patterns 4l1g4, lgo3, 1go, 2ith and 4h1m match this word and determine its
hyphenation. Only odd numbers mean hyphenation breaks. If two (or more) patterns have numbers in the same place, the highest number wins.

> hyphen substrings.pl:
> # 8 bit or UTF-8 character length (calculating right start position for discretionary hyphenation)
> sub enclen {
> my $nonchar = 0;
> my $len = length($_[0]);
> if ($encoding eq "UTF-8") {
> # length of an UTF-8 string equals to the count of the characters not started with '10' bits
> for ($i = 0; $i < $len; $i++) {
> if ((ord(substr($_[0], $i, 1)) >> 6) == 2) { $nonchar++; }
> }
> }
> return $len - $nonchar;
> }

Nežinau, kam šita funkcija naudojama, bet ji skaičiuoja UTF-8 eilutėje esančių simbolių kiekį, remdamasi UTF-8 koduotės struktūra – pirmasis simbolio baitas niekada neprasideda bitais 10, tuo tarpu visi tolesni simbolio baitai visada prasideda būtent šiais bitais: https://en.wikipedia.org/wiki/UTF-8#Description . Remiantis šia savybe, simbolių kiekį eilutėje galima apskaičiuoti, suskaičiuojant visus baitus, kurie prasideda kitokia nei 10 bitų seka.

[Laimonas Vėbra (laimis)]

Aš matau, kad TeX skiemenavimo pattern'uose gali būti naudojamos replacement taisyklės (nežinau ar jos standartinės/leidžiamos TeX'e, ar ne), kai eilutės pradžia ir ilgis (skaičiukai) *PRIKLAUSO* nuo (multibaitinės) koduotės. Tokios taisyklės, jų pavyzdžiai, beje, pateikti ir tavo paminėtame pdf''e (Sojka’s non-standard hyphenation extension; Extended hyphenation patterns).
O iš substrings.pl kodo aiškiai matyti, kad tuomet įsijungia mano jau minėtas utf-8 eilutės ilgio skaičiavimas; eilutės pradžios ir ilgio skaičiukai/skaičiavimas priklauso nuo (multibaitinės) koduotės .
Todėl ir teigiu, kad negalima (nereikėtų) perkoduoti dic failo koduočių tiesiogiai; jei tokios TeX taisyklės ateityje būtų naudojamos lietuvių kalboje, tai toks konvertavimas sugriautų hyphen failą.

[Rimas Kudelis (rq)]

Vis tiek manau, kad klysti:

For example, the pattern zuc1ker/k=k,3,2 represents the hyphenation of Zucker. This means the non-standard hyphenation subregion will be replaced by k=k, where the = indicates the break point with a hyphen. The subregion begins at the 3rd character,
and contains 2 characters (ck).

Ir konkrečiai apie UTF-8:

Unicode character encoding
Unicode is the basis for internationalization [3] Thanks to the unambiguous start positions of the multibyte-characters, Liang’s algorithm works perfectly with the UTF-8 Unicode encoding. Subregion parameters of non-standard hyphenation patterns use Unicode character (not byte) positions and lengths.

Mano manymu, būtų mažų mažiausiai abai kvaila ir nepatogu, jeigu skiemenavimo taisykles iš tikrųjų reikėtų perrašinėti priklausomai nuo koduotės. Manau, jog vengrai, kurie tą skiemenuoklį darė, tikrai apie tai pagalvojo laiko. :)

[Laimonas Vėbra (laimis)]

Na, taip, esu neteisus, pagaliau supratau: substrings.pl utf-8 kodas naudojamas skaičiuojant eilutės simbolines pozicijas ir ilgį, kai pattern'ai yra utf-8 koduotėje ir kai jie verčiami į hyphen formatą. T.y. įrankiui reikia žinoti, kad tai multibaitinės eilutės ir atitinkamai skaičiuoti eilutės simbolių pozicijas ir ilgį. Jei turime jau galutinį hyphen'o formatą, tai nieko skaičiuoti tiesiog nebereikia (jau suskaičiuota) ir galima jį tiesiog perkoduoti (iso <-> utf8).
Taip, tikrai galime perkoduoti, nors vis tiek manau, kad kurį laiką geriau būtų platinti/laikyti abu failus (dėl jau minėtos priežasties, kad senesniuose OO su utf-8 gali veikti nekorektiškai). Kita vertus, turėti du galutinius failus yra neblogai ir dėl vieno praktinio aspektėlio: nesigauna tiesmukiškai perkoduoti failą, nes antraštėje įrašyta koduotė. Reikėtų ją perrašyti, tad negali readme tiesiog paprastai nurodyti, kad „jei netinka utf-8, tai iconv it“.

[Rimas Kudelis (rq)]

Todėl ir sakiau, kad galima paruošti paprastą skriptą (two-liner'į ?) šitam darbui atlikti.

Nors su šiandieniniais tempais (tiek naujų softo versijų leidimo, tiek mūsų repozitorijos augimo nebuvimo) aš galvočiau, kad gal tos senos versijos nėra tokios jau aktualios... :)

[Laimonas Vėbra (laimis)]

Bet šitą skriptą reikėtų leisti kažkam, kas atsisiųstų paketą. Skriptas galutiniame pakete, kurio sandar yra apibrėžta (hyp dic failas ir readme) tai jau nebelabai distribucinio/galutinio paketo praktika (analogiškai juk galima būtų pasakyti, susigeneruokit ispell-lt dict patys :-)).
Na, o dėl senų versijų, tai dar palaikomi Ubuntu 10.04 LTS, 12.04 LTS (šitas, tai dar kelis metus) su OO3. Taigi, ne tik teoriškai, bet dar ir praktiškai gali būti naudojančių, tai šiaip griauti, jeigu galima negriauti, manau, nereikėtų.

[Rimas Kudelis (rq)]

Na taip, tačiau juk galima tą skriptą leisti kaip vieną oficialaus release skripto žingsnių – tokiu atveju repozitorijoje būtų vienas failas, o distribuciniame/galutiniame pakete – jau du. Galbūt netgi galima netgi juos abu į tą patį OpenOffice.org plėtinio paketą supakuoti. O jei ir negalima, tai galima pakuoti tik ISO-8859-13 failą, buildinimo metu jį sukūrus iš UTF-8 failo. Arba galima laikyti tik ISO-8859-13 failą, tačiau tvarkingą ir atnaujintą, o vėliau jį perkoduoti į UTF-8, kai tai jau nesudarys problemų. Bet kuriuo atveju nemanau, jog repozitorijoje turėti du failus, atliekančius tą pačią funkciją, kai jų tarpusavio perkodavimas trivialus. Juo labiau turint omeny, kad jie lyg ir turėtų būti beveik vienodi, tačiau kažkodėl nėra.

[Laimonas Vėbra (laimis)]

Dabar tie failai repozitorijoje beveik vienodi; rašiau, koďėl mūsų iso failas 'pagedo' ir pataisiau. Taigi, teisingas būdas būtų praleisti pattern'us(iš TeX repo) per hyphen'o substrings.pl kiekvienąsyk generuojant hyph žodyną. Šia prasme nėra skirtumo ar perkoduoti iš vieno failo ar sugeneruoti iš karto abu, nes vistiek laidose būtų pageidautina (per)generuoti failus iš išorinio source'o, kurio mes nekontroliuojam. Bet kokiu atveju (iki laidos ir makefile'o pataisymo, galutinio sprendimo) dabar mūsų repo yra 2 galutiniai hyphen failai, su kuriais turi veikti teisingai.

[Antanas Budriūnas (antanasb)]

UTF-8 variantą įsidėjau į Scribus ir kol kas skiemenavimo klaidų nematau, o pastebimai pasitaisė –

pe-nktadienis => penk-ta-die-nis
stude-ntas => stu-den-tas
paremdam-as => paremda-mas

[Rimas Kudelis (rq)]

Visi bugai seniai perkelti į GitHub. Čia juos uždarau.