[mpeg-OTspec] OFF "cv01"-"cv99", and a more general question

[Peter Constable]

Some months back in discussing this feature proposal, I showed screenshots of apps that were presenting the kind of UI in question. I don't recall now what all they were. I know that Apple's typography palette implements this kind of UI for an AAT equivalent of the cvXX feature, and that some SIL apps do as well (for AAT and Graphite equivalents of cvXX).

The only way to support this alternates scenario with single substitution lookups would either require separate features for each alternate, or a parameterized feature in which you index into a list of multiple type 1 lookups rather than index into a single type 3 lookup with multiple glyphs. The latter would be more awkward than a single type 3 lookup and you'd still have the UI issues. The former would still entail the UI issues if you want to provide the best user experience and be more complicated to implement. The only way to avoid the UI issues associated with type 3 lookup behavior is a separate feature for each alternate with no assumed relationship at all between them, and IMO that would entail really terrible UI.


Peter


-----Original Message-----
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of John Hudson
Sent: Friday, March 13, 2009 12:52 PM
To: Peter Constable
Cc: Thomas Phinney; karstenluecke; mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] OFF "cv01"-"cv99", and a more general question

Peter Constable wrote:

> In the intended usage scenarios for cvXX, I can see more than one 
> feature being applied to the same text, but I would not expect more than 
> one feature to have lookups affecting any given character. E.g. if cv01 
> is used for variants of "a", then I would expect all the variants of "a" 
> to be accessed using cv01 rather than having some variants of "a" 
> accessed using cv01 but other variants of "a" accessed using a different 
> cvXX feature.

So, with the option of using type 3 substitutions, the <cvXX> features 
are like precisely targeted versions of the <salt> feature.

That is certainly a reasonable theoretical model, but my concern is 
that, to my knowledge, no one has actually tried to implement <salt> 
type 3 lookup support at the application UI level (unless SIL have done 
it). And the process by which the user would select from the enumerated 
variants on offer in each feature seems far from clear. It has been more 
than a decade now since type 3 lookups were included in the GSUB spec, 
and neither MS nor Adobe has tackled the UI implementation problems.

I had imagined that the <cvXX> features would be spec'd in such a way as 
to avoid this implementation issue, providing one-to-one substitutions 
for different variants in different features (although that comes with 
the same interactivity issues as the <ssXX> features).

John Hudson


-- 

Tiro Typeworks        www.tiro.com
Gulf Islands, BC      tiro at tiro.com

I'm like that Umberto Eco guy, but without
the writing.   -- anonymous caller


------------------------------------

Yahoo! Groups Links