[mpeg-OTspec] Re: [OpenType] RE: Proposal: deprecate ReqFeatureIndex

[Sairus Patel]

John,

>Sairus, can I clarify that the objection to which you refer was an 
>objection to the wording of the feature description, and not to the 
>feature, correct?

Correct.

>That said, I don't object to your proposed rewording of the <rclt> to 
>match the softer requirement statement of other 'required' features such 
>as <rlig>, on the assumption that in practice it will be interpreted in 
>the same way

Great.

> And I agree with you that the ReqFeatureIndex is just daffy.

It was probably a good idea in the days before the current layout model was developed, but right now, yes, it doesn't serve any purpose that I can see and sort of comes in the way of things.

Sairus

---
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of John Hudson
Sent: Tuesday, August 21, 2012 4:10 PM
To: opentype-migration-list at indx.co.uk
Cc: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] Re: [OpenType] RE: Proposal: deprecate ReqFeatureIndex

  
Sairus wrote:

> (In fact, this was specifically the objection to the recent 'rclt' proposal; see recent thread "rclt feature -- minor concern" http://tech.groups.yahoo.com/group/mpeg-OTspec/message/803.)

Sairus, can I clarify that the objection to which you refer was an 
objection to the wording of the feature description, and not to the 
feature, correct? It seems to me that there is something of a 
philosophical difference here, because I interpret your objection to 
mean that you don't believe there should be any feature that could not 
be turned off by a suitably expert user. But in fact we have a whole 
host of such features that perform essential script shaping, and which 
if they are to be disabled must be done so via Unicode control 
characters with more or less well defined expected results. As someone 
who has had to make the kind of tables to which you refer by 
illustration, I can say that there is almost always a mechanism by which 
one can affect the layout one wants, regardless of whether a particular 
piece of software provides a means to actually turn a particular OTL 
feature on or off.

I proposed <rclt> because I and other designers are producing type 
designs that rely for intended display on contextual substitutions, and 
that may be anything from less-than-beautiful to actually unreadable if 
these substitutions are turned off. In some respects, I think the 
OpenType assumptions of script required, language exception, and 
typographic optional layout are misleading, because the category of 
design required features does not fit neatly onto the structure. This is 
the category where we're increasingly working.

That said, I don't object to your proposed rewording of the <rclt> to 
match the softer requirement statement of other 'required' features such 
as <rlig>, on the assumption that in practice it will be interpreted in 
the same way: as something that most software will not provide a means 
to turn off, and that -- crucially -- is independent of <calt> feature 
control.

And I agree with you that the ReqFeatureIndex is just daffy.

JH

-- 

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

The criminologist's definition of 'public order
crimes' comes perilously close to the historian's
description of 'working-class leisure-time activity.'
- Sidney Harring, _Policing a Class Society_