[Bug 455981] Missing locl romanian magic

bugzilla at redhat.com bugzilla at redhat.com
Tue Jul 22 10:40:38 UTC 2008


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 gaburici at cs.umd.edu  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.




More information about the Fedora-fonts-bugs-list mailing list