Page 1 of 1

File Comparator - UNICODE

Posted: 12 Feb 2009, 11:29
by zarevak
Dobrý den,
i když toto je chybka, tak se jedná spíš o doplňení funkčnosti (lepší podpora UNICODE):
- File Comparator neuznává ekvivalenci ss a ß ani na systémech, které to podporují (Windows 7)
- File Comparator nezvládá combining characters - tedy háček + C se ani nezobrazí jako Č - Notepad na Windows XP Č zobrazí.

Posted: 12 Feb 2009, 13:25
by Petr Solin
Jeste si zapomnel ligatury (fi jako jeden znak, atd.), ty to taky neumi. Obavam se, ze tohle uz jsou veci nad nase moznosti a nastesti snad i nad potreby nasich uzivatelu. Uvidime, kolik lidi na tyhle potize narazi, pripadne to budeme resit.

Kdyz si zvolis font s lepsi podporou unicode, napr. Courier New, tak uvidis misto symbolu "neznamy znak" (tecky) ty kombinujici hacky.

Posted: 12 Feb 2009, 13:35
by Jan Rysavy
Na druhou stranu se asi nemáme moc za co stydět, když to nezvládají ani specializované programy s podporou pro Unicode, jako je WinMerge.

Uvidíme, jaké budou reálné potřeby uživatelů. Vše lze samozřejmě řešit, je to jen otázkou potřebného času.

Posted: 12 Feb 2009, 14:28
by zarevak
Ligatury - měl jsem za to, že se jedná o stejnou věc jakou je ekvivalence ss a ß (btw: ligatura Ӕ != Æ a ӕ != æ :shock: )

Háčky s Courier New fungují, ale jen trochu - pokud jsou zrovna ve zvýrazněné části (jako na obrázku), tak se zobrazují zvlášť. Pokud jsou ve schodné části, tak jsou nakreslené správně.
V obou případech však blbne označování myší:
- při tažení myší zprava doleva se zobrazují znaky odpovídající pozici v řetězci a ne pozici, jak jsou nakreslené
- při tažení myši zprava doleva lze označit samotný háček. Ten je buď nakreslen (Win7) nebo se kreslí nesmysly (WinXP - nemám tu neproporcionální font, který umí samotný háček nakreslit)
- při tažení zleva doprava se za prvním háčkem nezobrazí žádný znak (jen černý obdélník)

Pravda, WinMerge tyto UNICODE blbůstky označuje za změnu, ale zobrazí háčky rozumněji: za písmenem, které bylo oháčkováno je mezera, která zajišťuje, že pozice znaku na výstupu je schodná s pozicí znaku v řetězci. Při označování je stále možné označit samotný háček.
Správné zobrazení háčků se zobrazení mezer za znakem mi přijde docela rozumné - v normálním textu by se neměly vyskytnout více jak dva combining characters za sebou (Vietnamština).

Myslím, že pro blízkou budoucnost by bylo vhodné opravit zobrazování/označování textů s combining characters. Podporu ekvivalence různých zápisů bych dodělával, až se budete nudit nebo až se ozve nějaký lingvista, kterému se to bude hodit. Tato ekvivalence by měla být nastavitelná podobně jako změny bílých znaků.

Posted: 12 Feb 2009, 18:06
by Ether
zarevak wrote:Myslím, že pro blízkou budoucnost by bylo vhodné opravit zobrazování/označování textů s combining characters. Podporu ekvivalence různých zápisů bych dodělával, až se budete nudit nebo až se ozve nějaký lingvista, kterému se to bude hodit. Tato ekvivalence by měla být nastavitelná podobně jako změny bílých znaků.
Na druhou stranu, zrovinka nějaký lingvista-perfekcionista by mohl chtít, aby měl ve všech dokumentech stejný způsob zápisu (vždy jedním znakem versus vždy více Unicode znaky) - doporučuju k tomu přiřadit volbu v konfiguraci (tedy až to bude hotové).

Posted: 12 Feb 2009, 18:38
by Raptor
Jen pro zajimavost, kolik lidi se s timto unicode problemem setkava v beznem zivote?

Co ja bych dal alespon na zakladni podporu Unicode, bez nejakych zdvojovacich blbinek a podobnych veci.

Posted: 12 Feb 2009, 19:06
by Jan Rysavy
To je přesně důvod, proč bychom chtěli počkat na reálné problémy a ty se snažit operativně řešit. Konkrétně Unicode je tak složitá problematika, že vyřešit jeho podporu do hloubky nezvládají ani firmy jako Microsoft. Viz zlepšující se podpora od Windows NT4 po Windows Vista.

Posted: 12 Feb 2009, 19:18
by zarevak
Ligatury/Slitky jsou jedny ze záludnustí UNICODE a první zmínka o nich na tomto fóru je od Jana Ryšavého zde ve vlákně o UNICODE. Já je jen zpětně vytahuji na File Comparator. 8)

Tyto fíčurky můžeme buď: (Osobně jsem pro volbu b))
a) ignorovat
b) podporovat s nedostatky systému (Notepad používá stejné API, které je dostupné ostatním aplikacím...)
--- WinXP: Notepad ligatury nezná - nenajde se žádná schoda
--- WinVista: ligatury Notepad rozbijí - najde se pouze první a pak hledání skončí
--- Win7: Notepad ligatury podporuje - schoda ss a ß plně podporována
c) plně podporovat pomocí knihoven třetích stran

File Comparator je první vlaštovka podpory UNICODE v Salamanderu a jako taková může být pokusným králíkem a ukázat problémy a záludnosti implementace podpory UNICODE v praxi. Pokud odladíme File Comparator, tak bude implementace do dalších částí Salamandera jednodušší ;)

BTW: Problematika internacionalizace software je natolik rozsáhlá, že všechny verze Windows před Windows Vista měly pro každou jazykovou mutaci fyzicky jiný zdrojový kód. 8)

Posted: 12 Feb 2009, 19:26
by Raptor
No, chapu. Je to strasne slozite, zabere to moc casu, chceme to mit perfektni, ale u toho to zustava a konkurence tyto zaludnosti zvlada uz nejaky patek. Pomineme ze nedokonale, ale zvlada. :-)

No verim ze se to nejak pohne a budeme mit podporu UTF-8/16 alespon nejakou. Zatim se porad jen placame na suchu a doufame ze se to nejak udela ;-)

Posted: 12 Feb 2009, 19:35
by Jan Rysavy
zarevak wrote:Tyto fíčurky můžeme buď: (Osobně jsem pro volbu b))
Volbu (b) bychom chtěli zvolit pro jádro Salamandera, kde slušnou podporu pro Unicode považujeme za podstatnou. V případě FC máme dojem, že je to momentálně škoda času. Co si budeme povídat, pro uživatele Salamandera je to okrajový plugin, který velká část ani nepoužívá.

Posted: 12 Feb 2009, 19:56
by zarevak
Jan Rysavy wrote:Volbu (b) bychom chtěli zvolit pro jádro Salamandera, kde slušnou podporu pro Unicode považujeme za podstatnou.
Super! Už se (jako ostatní) těším ;)
Jan Rysavy wrote:V případě FC máme dojem, že je to momentálně škoda času. Co si budeme povídat, pro uživatele Salamandera je to okrajový plugin, který velká část ani nepoužívá.
Uvažovali jste o nějakém "Customer Experience Improvement Programu"? Microsoft to teď cpe skoro všude a myslím, že to jim to přináší ovoce (alespoň co jsem koukal na některé publikované statistiky). Někdy se ukáže, že uživatelé používají aplikaci jinak než původně bylo zamýšleno :oops:

Pro mne je například File Comparator jedním z nejpoužívanejších pluginů (asi třetí až čtvrtý po PictView, UnRAR, IEViewer).

Re: File Comparator - UNICODE

Posted: 12 Feb 2009, 21:49
by vbr
zarevak wrote: ...
File Comparator neuznává ekvivalenci ss a ß ani na systémech, které to podporují (Windows 7)
...
Zdravim,
mohl bych poprosit o odkaz na nejakou specifikaci pro tuhle ekvivalenci?
Zajimalo by me, jak se toto oficialne stavi - z hlediska pravopisnych pravidel nemciny jsou to porad ruzne jednotky (s posledni upravou sice ubylo ß, ale porad zustava) - kazdopadne je zamena obema smery pravopisna chyba.
Dokazal bych si nanejvys predstavit ignorovani rozdilu pri srovnani bez ohledu na velikosti pisma, kdyz zdvojene S je kapitalkovou nahradou ß - vedle historickeho sz a nyni i v unicode standardu oficialniho velkeho ß:

ž (dec: 7838; hex: 0x1e9e) LATIN CAPITAL LETTER SHARP S


(schvalne kolik z nas ten znak vidi - ja momentalne v tomto okne ne :-)

Take pro vyhodnoceni ostreho s pro trideni je hned nekolik konkurujicich si pristupu...

Omlouvam se za mirny off topic a predem dekuju za informace.
vbr

Posted: 13 Feb 2009, 06:33
by zarevak
Tak jsem trochu prohrábl standard UNICODE a v CaseFolding.txt je definováno ß = ss (což jak píšete by se mělo využít jen při ignorování velikost písma). Ve SpecialCasing.txt je definováno UpperCase("ß") = "SS".

O ostrém S píše Michael Kaplan na svém blogu:
- What the %#$* is wrong with German sorting?
- The idea has to do more than just make sense to me (aka How S-Sharp are *you* feeling today?)

Nějaké informace o ostrém s lze najít v článku na wikipedii o ß. Je tam zmíněno, že například pro účely dělení slov je ß rozděleno na s-s. Na druhou stranu u některých příspěvků Michaela Kaplana je v komentářích reakce, že záměnou ß a ss teoreticky může dojít k záměně slov.

BTW:
- Windows 7 zobrazí velké ostré S správně a pokud ho nakopíruji do Notepadu, pak při hledání bez ignorování velikosti: ss = ß a SS = (velké ß pro ty co vidí obdélníček)
- Podle UnicodeData.txt: LowerCase("") = "ß", ale opak definovaný není. Takže UpperCase(LowerCase("")) = "SS" a LowerCase(UpperCase(LowerCase(""))) = "ss"

EDIT:
- O ekvivalenci znaků v kapitole 2.12 UNICODE specifikace
- O hledání a řazení kapitola 5.16 UNICODE specifikaci

:arrow: Tahle detabata by se nejspíš měla přesunout do vlákna o UNICODE :oops:

Posted: 13 Feb 2009, 07:36
by Jan Rysavy
zarevak wrote::arrow: Tahle detabata by se nejspíš měla přesunout do vlákna o UNICODE :oops:
phpBB bohužel neumí připojit vlákno nebo jeho část jinam, tak vlákna alespoň prolinkujeme?

Composite characters in File comparator

Posted: 13 Feb 2009, 22:51
by Jan Patera
ether wrote:
zarevak wrote:Myslím, že pro blízkou budoucnost by bylo vhodné opravit zobrazování/označování textů s combining characters. Podporu ekvivalence různých zápisů bych dodělával, až se budete nudit nebo až se ozve nějaký lingvista, kterému se to bude hodit. Tato ekvivalence by měla být nastavitelná podobně jako změny bílých znaků.
Na druhou stranu, zrovinka nějaký lingvista-perfekcionista by mohl chtít, aby měl ve všech dokumentech stejný způsob zápisu (vždy jedním znakem versus vždy více Unicode znaky) - doporučuju k tomu přiřadit volbu v konfiguraci (tedy až to bude hotové).
Od pristi verze AS (2.52b2) bude k dispozici volba pro konverzi combining diacritic marks na precomposed characters, pokud existuji, tj. konverze na Normalization Form C, pokud to dany system podporuje.
Takovy system je bud Windows 6+ nebo 5.1/5.2 s doinstalovanou normaliz.dll (soucasti napr. MSIE7, WMP11 nebo idndlpackage.EXE).

Pokud by se pouzivala Normalization Form KC, bylo by mozne srovnavat i ligatury s dvojicemi resp. trojicemi znaku. Toto je ale uz nebezpecne, protoze NFKC napriklad konvertuje take horni index 2 na obycejnou dvojku. A to uz IMHO neni moc totez.

A IMHO neni potreba lingvista - s composite characters zrejme muze prijit do styku i "bezny" uzivatel. Kdyz na Tigru (Mac OS 10.4.x) v TextEditu napisi cesky text, dostanu precomposed characters. Kdyz ale prepnu na francouzskou klavesnici, dostanu na temze stroji composite characters, a to i pro jinak bezny cesky znak é.