Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Missing locl romanian magic https://bugzilla.redhat.com/show_bug.cgi?id=455981 ------- Additional Comments From [EMAIL PROTECTED] 2008-07-22 06:40 EST ------- (In reply to comment #5) > So, apparently both U+015E-U+015F, U+0162-U+0163, and U+0218-U+021B can still > all be used for Romanian. With the extra string attached to U+0218-U+021B > that > they should be used when a distinct shape with comma below is needed. So > you're still allowed the U+015E-U+015F, U+0162-U+0163 glyphs to write > Romanian > apparently. Microsoft took about 7 years to include U+0218-U+021B in *some* Windows XP fonts, which happened only after Romanian got into the EU :) Some XP fonts (Georgia, Courier) still don't have the proper glyphs, even after the update [http://www.microsoft.com/downloads/details.aspx?familyid=0ec6f335-c3de-44c5-a13d-a1e7cea5ddea&displaylang=en] (google "EU font expansion update if that ugly link doesn't work). The result is that documents using the pre-Unicode 3.0 encoding (U+015E-U+015F, U+0162-U+0163) still dominate. > > It should be done because locl is an *optional* font feature. > > I thought it was obligated if a language was passed to the renderer (but I may be wrong on this). Currently Uniscribe (the XP renderer) doesn't honor it at all. At least in XP SP3. > > Adobe introduced ROM/locl because they (and 99% of commercial fonts) remap > > "t with cedilla" to "t with comma" regardless of locale > > That's just bad, t with cedilla _is_ used sometimes. I think it was even > proposed a long time ago to be used in French for when a t sounds like /s/, > like "relaţion" (didn't catch on unfortunately :-) ). Unicode itself mentions > Semitic transliteration (but I guess that needs a lot of other glyphs those > fonts don't have). I agree it's bad. *Very few* commercial fonts have a proper "t with cedilla". Verdna and Tahoma are only significant ones. Everything else follows the Adobe standard. You can check commercial fonts at Linotypes' website. Below is a link that restricts the search to fonts that support the Romanian characters: [http://www.linotype.com/featuresearch?cf[]=adobece&cf[]=euro&cf[]=latinext] You have to enter a test string yourself, since that doesn't go in the URL. Use: aăâiîsştţ€sștț. > So far I've only found three Adobe fonts with Romanian glyphs and two didn't > have the locl rule, so it looks like Adobe doesn't do it often either. They > all have indeed t with comma below in the place of t with cedilla. If you > have > documents with mixed diacritics you can blame it on that practice, _not_ the > absence of locl rules in the font. You probably looked at old fonts. All the Pro fonts they are currently shipping have complete support for Romanian, with a "t with cedilla" substituted by the comma variant regardles of locale, and with a ROM/locl feature that *additionally* substitutes "s with cedilla" with "s with comma". Vista C-series fonts have exactly the same feature set, as you pointed out. [http://en.wikipedia.org/wiki/Romanian_alphabet#Adobe.2FLinotype.2FVista_de-facto_standard] > Also, one thing I'm asking myself is: why doesn't Gentium have locl rules (or > ccmp rules)? It's a more recent font compared to Doulos and Charis, so the > SIL > people seem to have changed their minds about it, and I'd like to know their > reasons before changing anything in DejaVu. You need to ask them. IMHO, their implementation of the remapping via ccmp violates the OpenType 1.4 standard: ccmp should *not* depend on the langage. > > So, short conclusion: how it's dealt with it seems to just depend on the > foundry that made the fonts, and it also seems to depend on who you ask. So > far, I haven't seen enough yet to be sure that a locl rule is needed. The are some variations, but 99% of commercial fonts follow the Adobe standard. Check on Linotype's website! Unfortunately you cannot check for locl there. But the Romanian locl issue has be debated to death on typophile forums, and the opinion leaders there (fokes that run foundries) follow the Adobe standard, locl included. > Also, don't always assume commercial fonts have it right. As said above, the > same fonts have t with comma below in place of t with cedilla, together with > a > s with cedilla, which is the worst thing you can do here. Adobe fonts look ok with locl on. Adobe assumed that Microsoft would implement locl sooner rather than later. InDesign CS3 supports locl in it's own renderer. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ Fedora-fonts-bugs-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
