Re: [Ltru] font features in CSS

Andrew Cunningham <lang.support@gmail.com> Tue, 03 November 2009 23:24 UTC

Return-Path: <lang.support@gmail.com>
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE28C3A68F3 for <ltru@core3.amsl.com>; Tue, 3 Nov 2009 15:24:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+rBeeyDhn3G for <ltru@core3.amsl.com>; Tue, 3 Nov 2009 15:24:02 -0800 (PST)
Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id E6CDF3A6864 for <ltru@ietf.org>; Tue, 3 Nov 2009 15:24:01 -0800 (PST)
Received: by pxi1 with SMTP id 1so4825748pxi.32 for <ltru@ietf.org>; Tue, 03 Nov 2009 15:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jMCJlx/NmlqgVcCOGcodsISzqVx4brQAwY/0mlrXZpU=; b=WAqoQ9yOMIE9eu70Z1aa+OEHhuiGBStcsgMZU60Z6uTOGew6NzfO0HFt0FGDK2SwMX jSvvvrwsSujbu2JqnsEzPZtrsKrMhlxeIjHctTLKehBBzVd9sJ5LtAD/AgZPtkU+7dEO zwMHNT13IGKGThJGQEYUS0TZLbyKcMpNkTdkE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kCqSaarx62HJ1hCKOLKCSkNAdL0OARdyVhzkdXSISQQcDNFFhW/DY/zMRhpuR5tPLq WzOTHmm4weqINMMfBpfomZ7MbuWkv9N08Bb3la4UJL0DkIao9CTSXy1bG5fWrUXvZEhv jhs5lUn8VvYveyHSvqF+UnuVbZEuoZ1HkJS8o=
MIME-Version: 1.0
Received: by 10.140.126.7 with SMTP id y7mr35739rvc.103.1257290660734; Tue, 03 Nov 2009 15:24:20 -0800 (PST)
In-Reply-To: <4AEEAB47.7060708@it.aoyama.ac.jp>
References: <19173.46660.701817.726727@gargle.gargle.HOWL> <CE2F61DA5FA23945A4EA99A212B157951D6CCD59B9@nambx03.corp.adobe.com> <49CB1917-6A69-448A-B619-644F8730940C@jfkew.plus.com> <4AEA91E9.4020708@twardoch.com> <4AEAB1E3.50305@it.aoyama.ac.jp> <9d70cb000910301502se5053c5qbfa3562dbcbd850a@mail.gmail.com> <BF2262AF099A70419F68A17FF6338DF40440B8B6@TK5EX14MBXC141.redmond.corp.microsoft.com> <BF2262AF099A70419F68A17FF6338DF40440B96F@TK5EX14MBXC141.redmond.corp.microsoft.com> <4AEEAB47.7060708@it.aoyama.ac.jp>
Date: Wed, 04 Nov 2009 10:24:20 +1100
Message-ID: <9d70cb000911031524s4625d144g1b5d00c586778c9f@mail.gmail.com>
From: Andrew Cunningham <lang.support@gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary="000e0cd28b3c36682004777fcb2b"
Cc: Jonathan Kew <jonathan@jfkew.plus.com>, www-font <www-font@w3.org>, Håkon Wium Lie <howcome@opera.com>, www-style <www-style@w3.org>, Stephen Zilles <szilles@adobe.com>, LTRU Working Group <ltru@ietf.org>, "Adam Twardoch (List)" <list.adam@twardoch.com>
Subject: Re: [Ltru] font features in CSS
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2009 23:24:03 -0000

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