FW: Proposals for mark selection

[Levantovsky, Vladimir]

Thank you, Kamal!

I am forwarding your email the list for AHG consideration - to be
discussed at the conference call on Oct. 29.

Best regards,
Vlad

-----Original Message-----
From: Mansour, Kamal 
Sent: Friday, October 24, 2008 3:11 PM
To: Sergey Malkin; Levantovsky, Vladimir; Behdad Esfahbod; Michelle Hill
Cc: Thomas Phinney; Peter Constable; Mikhail Leonov; Greg Hitchcock;
Daniel Fenwick; John Hudson; mpsuzuki at hiroshima-u.ac.jp; Eric Muller;
Terence Dowling; Sairus Patel; Simon Daniels; David Berlow; Adam
Twardoch; Peter Lofting; Julio Gonzalez
Subject: Proposals for mark selection

In June, Monotype presented the second version of the proposal entitled
"Enhancement to mark-attachment functionality" to be included in the OT
Spec 1.6. The proposal addressed the problem of not being able to select
a particular set of marks as 'visible' within a given lookup. In the
current version of OpenType, one can make visible all marks, no marks,
or one mark-attachment class. The Monotype proposal seeks to make
certain subsets of marks visible by allowing any lookup to access more
than one mark-attachement class simultaneously. The corresponding
extensions to data structures were devised to be limited to the lookup
level and to maximize backward compatibility.

In September, Sergey Malkin submitted a counter proposal that seeks to
provide the same functionality (i.e., accessing a select set of marks
with a
lookup) by introducing  changes at the level of the GDEF table. Under
this scheme, one will be able to define coverage sets of marks at a
global level
(GDEF) which are then referenced at the lookup level as needed.

While the logic of the two proposals differs, they both provide the same
functionality to programmers of OpenType tables. The Monotype proposal
seeks to achieve the results by making microscopic changes to lookups,
while Sergey's proposal introduces  macroscopic changes to the GDEF. In
either case, the aim is to reference desired subsets of marks at will.

At this point, we will need to choose one or the other. Here are some of
the factors to consider in choosing: the level of difficulty in
implementation, backward compatibility, concomitant changes to data
structures in GSUB and GPOS tables, indirect benefit to other aspects of
OT processing.

I hope that having to make a choice will not result in indecision.

Kamal


On 2008.9.9 22:49, "Sergey Malkin" <sergeym at windows.microsoft.com>
wrote:

> Hi,
> 
> I am attaching detailed description of the change I proposed during 
> our meeting, which is using globally defined mark glyph sets instead 
> of mark classes.
> 
> Again, sorry for this delay. I hope you will look at this now and give

> your feedback.
> 
> Thanks,
> Sergey
> 
> -----Original Message-----
> From: Levantovsky, Vladimir 
> [mailto:Vladimir.Levantovsky at MonotypeImaging.com]
> Sent: Monday, September 08, 2008 12:46 PM
> To: Behdad Esfahbod; Michelle Hill
> Cc: Thomas Phinney; Peter Constable; Mikhail Leonov; Greg Hitchcock; 
> Sergey Malkin; Daniel Fenwick; John Hudson; 
> mpsuzuki at hiroshima-u.ac.jp; Eric Muller; Terence Dowling; Sairus 
> Patel; Simon Daniels; David Berlow; Adam Twardoch; Mansour, Kamal; 
> Peter Lofting; Julio Gonzalez
> Subject: RE: OpenType meeting on September 8th
> 
> Behdad,
> 
> Thank you very much for your comments. I agree that using all reserved

> bits is unnecessary and keeping them for future extensions is
desirable.
> I modified the proposed specification text (attached) to reflect this
change.
> 
> You also suggested that
> "
> * If the proposed flag MultipleMarkAttachmentTypes=0x10 is set, then 
> it indicates that a subtable of mark-attachment types that should be 
> made simultaneously accessible (i.e. 'filtered in') throughout this 
> lookup is present at the end of the lookup table.  If 
> MarkAttachmentType is non-zero, that type is also filtered in.
> "
> 
> We agree that it is a benefit to allow non-zero MarkAttachmentType 
> co-exist with the multiple attachment types; however, we believe it 
> would be easier for implementers (both for new engine implementations 
> and for font developers) if the processing of the existing single 
> MarkAttachmentType and the new MultipleMarkAttachmentTypes would be 
> mutually exclusive - i.e. both can be present in a font but if the 
> MultipleMarkAttachmentTypes are defined, the single one must be
ignored.
> (Old engines will continue using the single MarkAttachmentType.)
> 
> The rationale behind this is that a font may have a generic rule for 
> processing of the single MarkAttachmentType defined, and the more 
> complex set of rules defined by the MultipleMarkAttachmentTypes at the

> same time. They (single rule vs. multiple rules) may not always be 
> complimentary or compatible with each other, and the engine should not

> just automatically assume that they are and filter them all in at the 
> same time. However, if a font developer wants them to be processed 
> together, (s)he can simply duplicate the value of single
MarkAttachmentType in MultipleMarkAttachmentTypes array.
> 
> Thanks again for your comments!
> Vladimir
> 
> 
>> -----Original Message-----
>> From: Behdad Esfahbod [mailto:behdad.esfahbod at gmail.com] On Behalf Of

>> Behdad Esfahbod
>> Sent: Friday, September 05, 2008 8:19 PM
>> To: Michelle Hill
>> Cc: Thomas Phinney; Peter Constable; Mikhail Leonov; Greg Hitchcock; 
>> Sergey Malkin; Daniel Fenwick; John Hudson; 
>> mpsuzuki at hiroshima-u.ac.jp; Levantovsky, Vladimir; Eric Muller; 
>> Terence Dowling; Sairus Patel; Simon Daniels; David Berlow; Adam 
>> Twardoch; Mansour, Kamal; Peter Lofting; Julio Gonzalez
>> Subject: Re: OpenType meeting on September 8th
>> 
>> Michelle Hill wrote:
>>> 
>>> *3-4pm Mark attachment proposal*
>>> 
>>> See attached PDF.
>> 
>> I like to comment on the implementation part of the proposal.
Namely:
>> 
>> """
>> * According to the current specification, if MarkAttachmentType is 
>> non-zero, then its value is interpreted as the single type of 
>> mark-attachment that will be exclusively selected for all operations 
>> in this lookup.
>> If MarkAttachmentType is zero, then the value of Reserved should be 
>> checked.
>> 
>> * If the latter is non-zero, then it indicates the number (from 1-15)

>> of mark- attachment types that should be made simultaneously 
>> accessible (i.e. 'filtered
>> in') throughout this lookup. The actual values of mark-attachment 
>> types will be listed in an auxiliary byte array that follows.
>> """
>> 
>> My main objection is that using all the four reserved bits is 
>> unnecessary.  I propose instead that one of the reserved bits is used

>> for the proposed feature and the other three remain reserved for 
>> future extensions.  Here is my proposal:
>> 
>> """
>> * According to the current specification, if MarkAttachmentType is 
>> non-zero, then its value is interpreted as the single type of 
>> mark-attachment that will be exclusively selected for all operations 
>> in this lookup.
>> 
>> * If the proposed flag MultipleMarkAttachmentTypes=0x10 is set, then 
>> it indicates that a subtable of mark-attachment types that should be 
>> made simultaneously accessible (i.e.
>> 'filtered in') throughout this lookup is present at the end of the 
>> lookup table.  If MarkAttachmentType is non-zero, that type is also 
>> filtered in.
>> """
>> 
>> The subtable then will have a count and additional mark attachment 
>> types.
>> This is superior to the current proposal in two ways:
>> 
>>   * It only uses one or the reserved bits instead of all four to 
>> achieve the same thing,
>> 
>>   * By allowing non-zero MarkAttachmentType coexisting with the 
>> multiple attachment types table, it provides better backward 
>> compatibility as the font can choose one of the desired mark 
>> attachment types to put in the MarkAttachementType field and by doing

>> that make that particular type visible to older implementations too.
>> 
>> 
>> Regards,
>> 
>> behdad
>>