OpenType meeting on September 8th
Levantovsky, Vladimir
vladimir.levantovsky at monotypeimaging.com
Wed Oct 29 21:57:30 CET 2008
Reminder - the conference call will start in 5 minutes.
The phone line is now open.
Thank you,
Vladimir
> -----Original Message-----
> From: Levantovsky, Vladimir
> Sent: Thursday, October 09, 2008 3:30 PM
> To: Levantovsky, Vladimir; 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,
>
> 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&year=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%20attachm
ent%20filtering%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