W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: [Ltru] font features in CSS

From: Andrew Cunningham <lang.support@gmail.com>
Date: Wed, 4 Nov 2009 10:24:20 +1100
Message-ID: <9d70cb000911031524s4625d144g1b5d00c586778c9f@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:22 GMT