- From: Andrew Cunningham <lang.support@gmail.com>
- Date: Wed, 4 Nov 2009 10:24:20 +1100
- To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Cc: Peter Constable <petercon@microsoft.com>, LTRU Working Group <ltru@ietf.org>, www-font <www-font@w3.org>, Håkon Wium Lie <howcome@opera.com>, www-style <www-style@w3.org>, Jonathan Kew <jonathan@jfkew.plus.com>, Stephen Zilles <szilles@adobe.com>, "Adam Twardoch (List)" <list.adam@twardoch.com>
- Message-ID: <9d70cb000911031524s4625d144g1b5d00c586778c9f@mail.gmail.com>
I'll start by saying that I tend to work with lesser used languages on the Web, and my comments will reflect what I see as their needs. 2009/11/2 "Martin J. Dürst" <duerst@it.aoyama.ac.jp> > > The more interesting question is how to deal with Macedonian, assuming that > Macedonian uses the same typographic conventions and variants as Serbian. > There are several possibilities: > > a) Browsers automatically activate the "SRB" "language system" for texts > labeled lang='mk' (or mk-*) > > b) There's a way in CSS to say: use "SRB" for this text. The selector part > already exists, the question is just how to create the property part, and > where to allow it (@font-face and/or general rules). This could look > something like: > :lang(mk) { opentype-language-system: 'SRB' } > > c) Same as b), but without exposing OT tags, essentially saying: Use the > same conventions as for Serbian. This could look something like: > :lang(mk) { typographic-convention-same-as: 'sr' } > (property names are overly long and descriptive on purpose; instead of 'sr' > in the above example, 'sr-Cyrl' may be more appropriate) > > I'd argue that b) is a better option. Its easy to see what language systems individual fonts use, whereas c) is dependant on the web browsers implementing very comprehensive data sets. They will need to know about macrolanguages and language collections. The data they'd have to implement would need to be more complete that what is published in the OT spec. For example there is the language system Karen (KRN/kar), and web browsers would need to know that kar is a language collection, and what languages fall into that collection. Assuming that all Karen languages can share an OT language system. Then there are all the languages that are covered by BCP47 that have no defined OT language system but may be able to use an existing language system instead. I'd even suggest that for a range of languages just indicating a language system in CSS is not enough. For deploying minority language content on the web suing a font like Charis SIL, currently we have to resort to recompiling the font with different default features to get it working as we need in web browsers. I currently have four versions of the font in use. Being able to specify which OT language system a font should use is critical, but insufficient by itself. There is also a need to be able to specify specific alternative glyphs and be able to control various features in the OT font in order to be adequately able to support minority languages. The advantages of c) over b) would be that it is less dependent on a > specific font technology, and it may be easier on the users, who don't have > to learn yet one more kind of tag. c) isn't scalable; and b) by itself isn't fully scalable. Personally, I think adding additional connect to the IANA registry to make the system workable would be a huge task. >From the point of scaleability, CSS extensions that would allow 1) to specify the language system and language script AND 2) the ability to control/specify specifc alternatives and features within specific opentype fonts would be crucial to minority language support. Andrew -- Andrew Cunningham Vicnet Research and Development Coordinator State Library of Victoria Australia andrewc@vicnet.net.au lang.support@gmail.com
Received on Tuesday, 3 November 2009 23:25:03 UTC