OpenType meeting on September 8th

[Levantovsky, Vladimir]

(Adding MPEG-OTspec reflector to this thread)

Dear all,

Please do not forget to copy your emails to MPEG-OTspec reflector on all
your correspondence. I uploaded the text of the Sergey proposal to AHG
file storage:
http://groups.yahoo.com/group/mpeg-OTspec/files/Mark%20attachment%20filt
ering%20using%20mark%20glyph%20sets.docx

Thank you,
Vladimir


> -----Original Message-----
> From: Behdad Esfahbod [mailto:behdad.esfahbod at gmail.com] On 
> Behalf Of Behdad Esfahbod
> Sent: Wednesday, September 10, 2008 4:32 PM
> To: Sergey Malkin
> Cc: Levantovsky, Vladimir; Michelle Hill; 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; Mansour, Kamal; Peter Lofting; Julio Gonzalez
> Subject: Re: OpenType meeting on September 8th
> 
> Hi Sergey,
> 
> While I generally like your proposal, I think it has its own 
> issues.  Most prominent one being that now instead of 
> classifying a mark with one class, a font designer (OpenType 
> table designer in fact) needs to assign a class to the mark 
> and add it to *multiple* sets.  Where as in Vladimir's 
> original proposal it's easy to set "for this lookup, filter 
> in all Below and BelowLeft marks", with yours that's 
> significantly harder as one needs to go build a set of those 
> two groups, and ensure that in the future any new Below and 
> BelowLeft marks are also added to those sets.
> 
> One way to solve this issue is to have multiple Set formats, 
> one of them taking mark attachment types instead of a coverage.
> 
> behdad
> 
> Sergey Malkin 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
> >>
>