quality of OpenType Layout tag registry

[Michelle Perham]

Hi Steve,
There has been very little traffic lately on the OpenType discussion list. It's fairly informal. Several years back the OpenType specification was standardized through ISO as the Open Font Format. There is a separate list for discussions on the OpenFont Format. It's a yahoo group: mpeg-OTspec at yahoogroups.com. Discussions on that list are more formal and changes to the spec. need to be made according to ISO guidelines. It's a bit complicated, but I wanted to provide you a little more information. The specifications aren't just owned by Microsoft, they are owned by the community.

Michelle


-----Original Message-----
From: Steve White [mailto:swhite at zipcon.net] 
Sent: Monday, August 08, 2011 2:16 PM
To: Michelle Perham
Subject: Re: quality of OpenType Layout tag registry

Hi Michelle,

Thanks for writing back!

As it happens, you are the second person this week to have made this suggestion.

I may do so, but I'm a bit hesitant, as my energies are very divided at this time.  I'm have some difficulty justifiying to myself yet another mailing list discussion ... 

Oh.  I should at least tell you who I am.  

My main connection with typography (beyond an old general interest), and the thing that brought me to write, is that I'm the current administrator of GNU FreeFont.
For what it's worth, I personally insist on the interoperability of that product with those of your fine company.

Cheers!


On  8.08.11, Michelle Perham wrote:
> Hi Steve,
> Sorry for the delay in getting back to you. This ended up in my junk mail.
> 
> I'd recommend you share your thoughts with the OpenType discussion list. 
> 
> Details on joining can be found here:
> http://www.microsoft.com/typography/otspec/otlist.htm
> 
> Michelle
> 
> -----Original Message-----
> From: Steve White [mailto:swhite at zipcon.net]
> Sent: Friday, July 29, 2011 2:58 AM
> To: Typography Site Comments
> Subject: quality of OpenType Layout tag registry
> 
> Hello!
> 
> I have been researching the applicability of various OpenType feature tags.
> My primary source is Microsoft Typography's
> 	OpenType Layout tag registry
> 	http://www.microsoft.com/typography/otspec/ttoreg.htm
> 
> While this is an invaluable resource, it's pretty spotty.  I think it would be a great help to the whole font industry to improve it. 
> It is toward this end that I am writing.
> 
> I went through each entry, mainly trying to determine to which script each tag was applicable.  A couple of days ago I updated a Wikipedia page with my inital findings:
> 	
> http://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_Typ
> ographic_Features I'm not satisfied with that, but it's a start.
> 
> I'll first outline some ideas that might make this whole thing more comprehensible, then just dump a list of tag issues at the bottom.
> 
> Basically all the "script" dependencies cited fall into two categories, writing mode (such as horizontal, rtl, ltr), and natural language scripts.
> One big source of confusion seems to be the unfortunate connection of writing modes with scripts.
> 
> In any case it would be best to clarify this, and try to be consistent with terminology.
> 
> modes vs scripts
> ----------------
> 
> All of these seem to be best considered writing modes:
> 	vertical vs horizontal
> 	left-to-right vs right-to-left
> 	cursive (somtimes "connecting")
> 	monospaced vs proportional
> 
> Text in a document might switch modes for any script.  
> That is, mode is a concept orthogonal to writing script.
> 
> Now, ltr and rtl are always considered *modes* or *contexts*.
> 
> But also, cursive/connecting dependency ought to be thought of as a mode. 
> While Arabic is essentially written in a cursive way, many other 
> scripts
> *can* be, and it is possible to present Arabic in a non-connecting form.
> Several features ought to be applicable generally in a cursive context.
> 
> Likewise, while some scripts such as Chinese are usually written in a monospaced mode, they aren't always, and most scripts *can* be monospaced. 
> Some features would be best activated according to this mode determination.
> 
> It would be best to say, Arabic script is by default in cursive mode, and Chinese in monospaced, but make it clear those features are activated by the current mode, rather than by the script.
> 
> You might think this suggestion amounts to breaking a standard.
> But I would say, the standard is unclear, and has been therefore implemented in inconsistent ways, partly in attempts to address these very issues.
> 
> sets of scripts
> ---------------
> The main sets of scripts cited are
> 
> 	all
> 	bicameral
> 	Indic
> 	Khmer (often with additions)
> 	CKJ(V)
> 	Kanji
> 	Kana
> 
> The notations don't always use the same terminology, and are sometimes unclear and a few are just wrong.  See notes below.
> 
> One thought concerning Indic/Khmer:  There are unclear notes such as "similar to Devanagari" or "Khmer and others".
> 
> Would a division of Indic scripts into 
> 	Devanagari-based 
> 	Brahmi-based
> be useful?  One could then just list elsewhere the scripts meant to fall in each category.  Of course there is overlap and mixing, but maybe that could be caught in the "Indic" umbrella.
> 
> Regarding CJKV, many of the feature tags address the issue that Chinese characters may appear in documents of any of these languages often with localized forms, while others address the overall style of writing in rectangular blocks.  It might be good to make this distinction clearer.
> 
> 
> That's all for now!
> Cheers!
> 
> -------------------------- dump of notes --------------------------- Mostly looking at "Script Sensitivity"
> 
> Sometimes says "Can apply to nearly every script" others say "None".
> Would be better to apply consistent verbiage.
> Often it's clear that the notion of writing mode has been confused with writing script.  Sometimes it looks as if the author is just guessing...
> 
> font
> ----
> The word "font" appears in this context, apparently by mistake.  I think in every case, "script" is the right word.
> 
> halt, hwid: "Used only in CJKV fonts", hkna, vkana: "Applies only to 
> fonts that support kana (hiragana and katakana)"
> 	Should say "Kana scripts" (Japanese or Ainu)
> ital: "note that many non-Latin fonts contain Latin as well"  
> Inappropriate
> mgrk: "apply to any font..."
> nalt, palt: "Used mostly in CJKV fonts"
> pkna: "Japanese fonts"
> qwid, twid: "Generally used only in CJKV fonts" 
> 
> inappropriate tech detail
> -------------------------
> cv01 - cv99: The text fails, at great length, to sum up what these tags do.
> 	The description of the table field names is inappropriate here.
> 	A summary should be provided, and the bulk of this text re-thought
> 	and put elsewhere, and perhaps a reference to that could also be
> 	provided here.
> ss01 - ss20: not as bad, but similar complaint
> size:	again, going into how many bits things have... is inappropriate here.
> 	put low-level implementation details elsewhere, and just refer to them.
> 
> individual tags
> ---------------
> abvf says "Required in Khmer" should be "Required in Indic"?
> calt, swsh says "not ... ideographic" ... why?
> 
> cpsp: says "not connecting, e.g. Arabic" should say "bicameral"
> case: says "European ... esp ... Spanish" should say "bicameral"
> smcp: says "bicameral" goes on to define the term and give a list of scripts.
> unic: "(same)"
> 
> init, medi, fina: say "any alphabetic"  --why make that distinction?
> 
> curs, jalt: say "any cursive script"  --perhaps cursive mode.
> 
> fwid: says "any ... with monospaced forms" does that mean CJK?
> pwid: says "mostly CJKV" can it be for any other script?  
> 
> fwid, hwid, qwid, twid: being either GPOS or GSUB -- I don't get this..
> 
> nalt, pwid: "Used mostly in CJKV fonts, but can apply to European scripts."
> 	Why not just say, "no script sensitivity"?
> qwid, twid: "Generally used only in CJKV"  [? could it be others?]
> 
> nlck: "Kanji" maybe clearer "Japanese Kanji" (or could it be any 
> Kanji?)
> 
> ordn: "applies mostly to Latin script"  What else? [On further consideration,
> 	I think this lookup doesn't usually make much sense with Unicode
> 	fonts.  Would have been better as an application function.]
> 
> pref: Complex description, listing four scripts... see comments about 
> Indic
> pstf: Also complex, but doesn't list one of those listed in pref...
> 
> rlig: "Applies to Arabic and Syriac. May apply to some other scripts."
> 	Which?  why not just say it's generally applicable?
> 
> ruby: says "only to Japanese".  Is this right? Suggest CJKV.
> 	The W3C says "typically East Asian".
> 	Wikipedia says Chinese and Japanese. 
> 
> smpl, trad: say "only to Chinese and Japanese". Shouldn't it be CJKV?
> 	This really applies to Chinese characters, wherever they may appear.
> 
> valt, vert, vrt2: say "applies only to scripts with vertical writing modes"
> 	Well... many scripts can be written vertically.
> 	This should not be a determination of the script but of a writing mode.
> 
> opbd: "not applicable in vertical mode".  Why? (makes sense for lfbd 
> and rtbd)
> 
> zero:	a silly feature anyway...but come on...it should apply only to the
> 	single character 0x0030.
> 
> 
>