OpenType meeting on September 8th

[Levantovsky, Vladimir]

Dear all,

According to AHG mandate, we need to allow at least two weeks from the
moment the AHG conference call is announced. I will be traveling Oct.
11-17 (Korea) and Oct. 19-25 (Europe), and it would be my preference to
schedule this AHG conference call the week of Oct. 27. We can use the
same conference call bridge that was used for our meeting on September
8th, the dial-in information is as follows:

Access numbers:

USA: 866-617-3597 or 210-795-0625
UK:   0800-279-9632 or +44-20-7108-6391
France: 080-510-0984 or +33-1-7070-8456
Germany: 0800-101-7056 or +49-69-2222-3468
Italy:0800-906-465 or +39-02-3604-7040
Japan: 0034-800-400652 or +81-3-5539-5161

Participant passcode: 3148166#

(if any participant would like to join this call from the country not
listed above - please email me and I will provide you with additional
country-specific dial-in information).
 

Best regards,
Vladimir


> -----Original Message-----
> From: Michelle Hill [mailto:mihill at microsoft.com] 
> Sent: Monday, October 06, 2008 5:10 PM
> To: Sergey Malkin; Levantovsky, Vladimir; Behdad Esfahbod; 
> mpeg-OTspec at yahoogroups.com
> 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; 
> Mansour, Kamal; Peter Lofting; Julio Gonzalez
> Subject: RE: OpenType meeting on September 8th
> 
> I'd like to set up a phone meeting to discuss the mark 
> attachment proposal and the issues brought up in this thread. 
> Please let me know if you are interested in attending and 
> what a good day/time would be for you.
> 
> Michelle
> 
> -----Original Message-----
> From: Sergey Malkin
> Sent: Wednesday, September 10, 2008 10:55 PM
> To: Levantovsky, Vladimir; Behdad Esfahbod; 
> mpeg-OTspec at yahoogroups.com
> Cc: 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
> 
> For me it is opposite, having independent sets is what I like 
> in my proposal :).
> 
> > Where as in ... original proposal it's easy to set "for 
> this lookup, 
> > filter in all Below and BelowLeft marks"
> 
> Let's say we are looking at simple case (I am using some 
> pseudo-VOLT syntax):
> 
> There are two mark classes: <Below> and <BelowLeft>
>     Lookup1, filter by <Below>
>     Lookup2, filter by <BelowLeft>
>     Lookup3, filter by { <Below>, <BelowLeft> }
> 
> This would looks exactly the same in both formats. But then, 
> you want to add another lookup. I would simply say:
>     Lookup4, filter by <SomeBelowMarks>
> Or even
>     Lookup5, filter by {SomeVerySpecialBelowMarkGlyph}
> 
> No changes to other lookups or groups is needed from me. What 
> you have to do is to break <Below> into <SomeBelowMakrs> and 
> unintuitive <BelowMarksOtherThanSome>. After that, create 
> special class for SomeVerySpecialBelowMark glyph. Every time 
> doing this, you have to correct existing lookups to reflect 
> this change. Number of your classes may grow fast and get out 
> of control.
> 
> Of course, this work may be simplified for font developer by 
> using nice syntactic sugar, maybe set of smallest unique mark 
> classes will be defined automatically. But this will mean 
> exactly the same syntax I propose to be native format! If you 
> prefer to work with small groups, like classes, you can 
> easily do that and merging them into real sets. People 
> frequently do that in other places, like lookup inputs or 
> contexts. This is just matter of your preferences in font 
> project organization.
> 
> > 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.
> 
> I do not see any difference between proposals. You have to 
> keep either mark classes or mark sets up to date, they both 
> are just groups and it is not more (or less) difficult than 
> maintaining any other groups in your projects. There will be 
> much more normal groups than mark classes or sets, anyway. If 
> you do not properly organize groups in your project, you will 
> have lots of problems anywhere you use glyphs and not only 
> with mark filtering.
> 
> > One way to solve this issue is to have multiple Set formats, one of 
> > them taking mark attachment types instead of a coverage.
> 
> Introducing mark glyph sets based on smaller classes does not 
> help anything. Even more, it complicates simple data 
> structure with artificial division of simple sets into small 
> classes. And this was one of the things that I do not like in 
> original proposal.
> 
> Additional point of not involving artificially defined mark 
> classes is that they potentially can be used for providing 
> backward compatible filters for older engines, which may 
> cover most of the cases for common scenarios. Mark classes 
> and sets will be just parallel independent filtering systems.
> 
> Thanks,
> Sergey
> 
> 
> > -----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
> > >>
> >
> 
>