OpenType meeting on September 8th

[Sergey Malkin]

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
> >>
>