File Comparator - UNICODE
File Comparator - UNICODE
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í.
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í.
- Attachments
-
- filecomparator.png (10.15 KiB) Viewed 15478 times
-
- soubory.zip
- oba dva testované soubory
- (242 Bytes) Downloaded 424 times
-
- ALTAP Staff
- Posts: 1112
- Joined: 08 Dec 2005, 09:13
- Location: Novy Bor, Czech Republic
- Contact:
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.
Kdyz si zvolis font s lepsi podporou unicode, napr. Courier New, tak uvidis misto symbolu "neznamy znak" (tecky) ty kombinujici hacky.
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
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.
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.
Ligatury - měl jsem za to, že se jedná o stejnou věc jakou je ekvivalence ss a ß (btw: ligatura Ӕ != Æ a ӕ != æ )
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ů.
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ů.
- Attachments
-
- fígl zachování pozice znaků ve WinMerge
- winmerge.png (1.12 KiB) Viewed 15443 times
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é).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ů.
Ελληνικά rulez.
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
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.
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.
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.
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
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
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
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á.zarevak wrote:Tyto fíčurky můžeme buď: (Osobně jsem pro volbu b))
Super! Už se (jako ostatní) těšímJan Rysavy wrote:Volbu (b) bychom chtěli zvolit pro jádro Salamandera, kde slušnou podporu pro Unicode považujeme za podstatnou.
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ýšlenoJan 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á.
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
Zdravim,zarevak wrote: ...
File Comparator neuznává ekvivalenci ss a ß ani na systémech, které to podporují (Windows 7)
...
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
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
Tahle detabata by se nejspíš měla přesunout do vlákna o UNICODE
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
Tahle detabata by se nejspíš měla přesunout do vlákna o UNICODE
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
phpBB bohužel neumí připojit vlákno nebo jeho část jinam, tak vlákna alespoň prolinkujeme?zarevak wrote: Tahle detabata by se nejspíš měla přesunout do vlákna o UNICODE
-
- Plugin Developer
- Posts: 707
- Joined: 08 Dec 2005, 14:33
- Location: Prague, Czech Republic
- Contact:
Composite characters in File comparator
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.ether wrote: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é).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ů.
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 é.