- From: Jonathan Kew <jfkthame@gmail.com>
- Date: Wed, 1 Jun 2016 10:22:19 +0100
- To: www-style@w3.org
On 1/6/16 09:35, Levantovsky, Vladimir wrote: > *On*Tuesday, May 31, 2016 11:30 AM Chris Lilley wrote: > > > Let me amplify and restate these points: > > On 2016-05-31 06:57, Andrew Cunningham wrote: > > It would be fairly quick and easy for google to add support for > font-language-override > > > Supporting font-language override would not only increase spec > compliance, it would be the path of least effort > > I am not sure why font-language-override is really needed, can’t a > developer simply define a span with another language tag [the one which > behavior one wants to mimic]? Won’t the end result be the same ? > > Depending on complex mappings from @lang to OpenType lang is a lot of > work, currently being done for you by font designers. This is a > duplication of effort and a maintenance burden; just support > font-language-override. It is there for a reason. > > OpenType maintains its own language tag system where the mappings in > most cases are 1:1 and in some cases are n:1, but I wouldn’t consider it > a complex mapping – as far as user is concerned, there is always a > straightforward mapping from a content language tag to the OT language > tag. It is _far_ from complete. Last I checked, the OT spec mentions somewhere between 4-500 ISO639 language tags. What about the other 7000-plus? (And that's without even considering complications like regional variants.) > Changing the content language tag, e.g. by defining a span with a > different tag, should do the trick. Changing the content language tag just to get the right shaping is not an adequate solution. For one thing, it requires changing the content HTML to achieve something that should be possible purely through styling. More significantly, it means you then have content with _incorrect_ tagging, which will break any other process (e.g. spell-checking, hyphenation, machine translation, text-to-speech, language-sensitive search and archiving, etc., etc.) that depends on having _correct_ lang tagging. We want to be able to have properly lang-tagged content, and render that content with appropriate shaping. In the absence of an _exhaustive_ and universally-supported BCP47-to-OpenType mapping, or something like that -- which would be a huge and difficult undertaking -- the font-language-override property allows authors to produce the correct rendering without requiring them to corrupt their content to achieve it. FWIW, even https://www.microsoft.com/typography/otspec/languagetags.htm itself says: # If information is available to an application declaring the language # of text content, then the application may make use of that to select # a default language system tag to be applied when displaying that # text. It is preferable, however, to give users control over the # choice of language system tag to be used. ... recognizing that while the language of the content (as recorded, for example, by language tagging) may provide a useful default, it is inadequate as the ultimate determinant of OpenType rendering behavior. JK
Received on Wednesday, 1 June 2016 09:22:54 UTC