OpenType meeting on September 8th
Levantovsky, Vladimir
vladimir.levantovsky at monotypeimaging.com
Thu Oct 9 21:29:56 CEST 2008
Dear all,
We will have the AHG conference call on October 29th at 2:00 pm PST
(http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=29&ye
ar=2008&hour=14&min=0&sec=0&p1=234) for one hour to discuss the
alternative Mark Attachment Types proposal from Sergey Malkin, available
at
http://groups.yahoo.com/group/mpeg-OTspec/files/Mark%20attachment%20filt
ering%20using%20mark%20glyph%20sets.docx
It is expected that the conference call will last approximately one
hour. 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: Levantovsky, Vladimir
> Sent: Monday, October 06, 2008 5:51 PM
> To: 'Michelle Hill'; Sergey Malkin; 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
>
> 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
> > > >>
> > >
> >
> >
More information about the mpeg-otspec
mailing list