[mpeg-OTspec] AHG on Font Format Kick-off

[Levantovsky, Vladimir]

Ken, all,

I appreciate your efforts but I am afraid you misunderstood what I said in my earlier post. I do not see how any part of it could have been interpreted as a suggestion to include a modified version of Apple's Spliced Font Format in the CFP. To the contrary, what I said was that CFP can *not* require a specific implementation be the only suitable result - this would contradict the purpose of making public call for proposals to find the best technology for a technical solution we are trying to develop.
In addition, there may be other issues we need to consider. As I mentioned in my previous message, I assume that specification for Apple's Spliced Font Format is copyrighted by Apple, and we have not yet heard from any of Apple representatives on this list whether they in fact would be willing to contribute their technology to ISO. I understand the benefits of developing a standardized solution that would be compatible with already existing implementations supported by at least one major vendor; but for "Call for Proposals" to be successful we need to concentrate on defining requirements and evaluation criteria in a way that would set the bar high enough to make sure that the best technical proposals would be selected, and not just the one particular solution we currently see as a strong candidate.

Regards,
Vladimir

> -----Original Message-----
> From: Ken Lunde [mailto:lunde at adobe.com]
> Sent: Monday, March 01, 2010 1:15 PM
> To: Levantovsky, Vladimir
> Cc: mpeg-OTspec at yahoogroups.com; David Lemon; David Singer
> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off
>
> Vladimir and others,
>
> It seems that my mailing list posts were not blocked, but were being
> severely delayed.
>
> Anyway, I like your suggestion about including a modified version of
> Apple's Spliced Font Format as part of the CFP. To this end, I spent
> some time this morning thinking about where in the Spliced Font Format
> the missing elements could be inserted. As I did late last year, below
> is a more human-readable form of the elements and their relative
> hierarchy in Apple's current Spliced Font Format:
>
>   PosingFont (Name*, FontMetrics?, Components+)
>   -->Name
>   -->FontMetrics
>   -->Components (ComponentDef | LanguagePreferedList)+
>   ----->ComponentDef (Matrix?, UnicodeCharSet*, cmapOverride?)
>   -------->Matrix
>   -------->UnicodeCharSet
>   -------->cmapOverride (map+)
>   ----------->map
>   ----->LanguagePreferedList (LanguagePreferedComponentDef+)
>   -------->LanguagePreferedComponentDef (ComponentDef, language+)
>   ----------->ComponentDef (Matrix?, UnicodeCharSet*, cmapOverride?)
>   -------------->Matrix
>   -------------->UnicodeCharSet
>   -------------->cmapOverride (map+)
>   ----------------->map
>   ----------->language
>
> I identified the following elements as ones that should be added, based
> on our discussions:
>
>   <cfs:ComponentFont> LocationHint
>   <cfs:ComponentFont> Tracking
>   <cfs:Encoding> Original
>
> Below is the same human-readable form of the format, with these
> elements added:
>
>   PosingFont (Name*, FontMetrics?, Components+)
>   -->Name
>   -->FontMetrics
>   -->Components (ComponentDef | LanguagePreferedList)+
>   ----->ComponentDef (LocationHint*, Matrix?, Tracking?,
> UnicodeCharSet*, cmapOverride?)
>   -------->LocationHint
>   -------->Matrix
>   -------->Tracking
>   -------->UnicodeCharSet (ToUnicode*)
>   ----------->ToUnicode
>   -------->cmapOverride (map+)
>   ----------->map
>   ----->LanguagePreferedList (LanguagePreferedComponentDef+)
>   -------->LanguagePreferedComponentDef (ComponentDef, language+)
>   ----------->ComponentDef (LocationHint*, Matrix?, Tracking?,
> UnicodeCharSet*, cmapOverride?)
>   -------------->LocationHint
>   -------------->Matrix
>   -------------->Tracking
>   -------------->UnicodeCharSet (ToUnicode*)
>   ----------------->ToUnicode
>   -------------->cmapOverride (map+)
>   ----------------->map
>   ----------->language
>
> Note that "<cfs:Encoding> Original" is an optional element of the
> UnicodeCharSet element, called "ToUnicode," whose purpose is remap at
> the encoding level, which could be from Unicode to Unicode, or from
> non-Unicode to Unicode. Also note that "cfs:ComponentFont>
> LocationHint" and cfs:ComponentFont> Tracking" are set as optional
> elements of the "ComponentDef" element.
>
> If anyone thinks that are better places for these three elements,
> please let me know. I feel that this is the first step in modifying the
> Spliced Font Format DTD.
>
> Regards...
>
> -- Ken
>
> On 2010/02/26, at 7:45, Levantovsky, Vladimir wrote:
>
> > Ken,
> >
> > As far as email blocking is concerned, you may need to take this
> issue up with your IT department - there is nothing I can do (as far as
> AHG email list configuration is concerned) to change this. In the
> meantime - you do have another option - as an alternative solution you
> can post and reply-to messages online
> (http://tech.groups.yahoo.com/group/mpeg-OTspec/messages) using the
> "Reply" function in the upper left corner of the message frame.
> >
> > On the subject of CFS - I do not disagree with you that Apple's
> Spliced Font Format may in fact become the good foundation for future
> CFS solution. You advocated for this more than once; however, we have
> not heard yet from Apple's representatives on this list whether they in
> fact would be willing to disclaim copyrights and contribute their
> specification to ISO. As far as CFP is concerned, I don't think we can
> draft it to require a specific implementation, but we can definitely
> strengthen the requirements and evaluation criteria for future solution
> in such a way that would assure that only qualified proposals would
> pass through the submission selection process.
> >
> > Thank you,
> > Vladimir
> >
> >> -----Original Message-----
> >> From: Ken Lunde [mailto:lunde at adobe.com]
> >> Sent: Friday, February 26, 2010 10:02 AM
> >> To: Levantovsky, Vladimir
> >> Cc: mpeg-OTspec at yahoogroups.com; David Lemon
> >> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off
> >>
> >> Vladimir,
> >>
> >> On an administrative note, my messages to the AHG mailing list are
> no
> >> longer being posted, and I suspect that "adobe.com" emails are now
> >> being blocked. If you check the messages on the website, the one you
> >> replied to isn't there (I originally sent it yesterday afternoon,
> and
> >> resent it this morning, explicitly adding your email address), and I
> >> suspect that this one won't be there.
> >>
> >> Back to the topic, I strongly suggest that we work to develop a
> >> modified version of Apple's Spliced Font Format, modified by having
> the
> >> three identified elements added, and use it with the Requirements
> >> document and CFP.
> >>
> >> Regards...
> >>
> >> -- Ken
> >>
> >> On 2010/02/26, at 6:34, Levantovsky, Vladimir wrote:
> >>
> >>> Ken, all,
> >>>
> >>> I expect that the requirements and the CFP documents would be
> >> published at the same time (tentatively in April). It is up to us as
> a
> >> group to agree on the deadline for submissions, but typically CFPs
> have
> >> deadlines from three to six months from the publication date. That
> >> being said, it doesn't mean that we should stop any development work
> -
> >> we can produce a working draft and update it as we go along with the
> >> evaluation of CFP submissions.
> >>> It might even be desirable (and, again, this is the decision that
> AHG
> >> would have to make) that the first working draft be prepared and
> >> published at the same time when CFP is published, so that together
> with
> >> the requirements and CFP itself it would give to potential
> contributors
> >> an idea of the scope of work been done by the AHG (assuming that the
> >> submitter of a proposal may not yet be an AHG member, which is
> unlikely
> >> but may be the case).
> >>>
> >>> Regards,
> >>> Vladimir
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Ken Lunde [mailto:lunde at adobe.com]
> >>>> Sent: Friday, February 26, 2010 9:19 AM
> >>>> To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
> >>>> Cc: David Lemon
> >>>> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off
> >>>>
> >>>> Vladimir,
> >>>>
> >>>> After the the requirements and use-case document is accepted at
> the
> >>>> next MPEG meeting, by what date do you expect to have the CFP
> >> document
> >>>> ready? And, to follow up on that, once the CFP document is
> >> published,
> >>>> by what date must any proposals be submitted?
> >>>>
> >>>> Thanks...
> >>>>
> >>>> -- Ken
> >>>>
> >>>> On 2010/02/23, at 11:34, Levantovsky, Vladimir wrote:
> >>>>
> >>>>> Ken, all,
> >>>>>
> >>>>> Thank you for your active participation and support of Composite
> >> Font
> >>>> Standard activity. I uploaded the draft requirements document that
> >> we
> >>>> discussed and approved during the last ISO MPEG meeting in
> January.
> >> The
> >>>> document can be downloaded using the following
> >>>> link:http://groups.yahoo.com/group/mpeg-OTspec/files/w11212-
> >>>> DraftRequirements_CFS.zip
> >>>>>
> >>>>> The next MPEG meeting will be held in April 19-23, and part of
> our
> >>>> mandate is to finalize the requirements and use case document, and
> >> to
> >>>> prepare a draft text for Call for Proposals where we should
> clearly
> >>>> outline the features of the CFS (including expectations for future
> >>>> implementations based on the requirements document) and evaluation
> >>>> criteria for submitted proposals, as well as the estimated
> schedule
> >> of
> >>>> the development of the CFS specification.
> >>>>>
> >>>>> I will make a first stub at drafting the text of CFP; meanwhile I
> >>>> would like to ask all AHG members to review the draft requirements
> >>>> document and submit your comments and proposed
> >> changes/clarifications
> >>>> (if any). I would expect to have final drafts of both document
> >>>> (requirements / use cases, and draft CFP) finalized no later than
> >> April
> >>>> 12, 2010.
> >>>>>
> >>>>> I also would like to remind the AHG that the text of the draft
> >>>> corrigendum for ISO/IEC 14496-22 OFF is now under open ballot, and
> >> that
> >>>> we had some comments submitted by Microsoft. We need to discuss
> and
> >>>> finalize the text of the corrigendum and prepare ballot comments
> to
> >>>> have the proposed changes incorporated in the current text.
> >>>>>
> >>>>> Thank you,
> >>>>> Vladimir
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-
> >>>> OTspec at yahoogroups.com] On Behalf Of Ken Lunde
> >>>>> Sent: Thursday, February 11, 2010 5:47 PM
> >>>>> To: mpeg-OTspec at yahoogroups.com
> >>>>> Cc: David Lemon
> >>>>> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off
> >>>>>
> >>>>>
> >>>>> Vladimir,
> >>>>>
> >>>>> Are you planning to drive the schedule for the required bits,
> such
> >> as
> >>>> turning the list of requirements for the CFS into something that
> is
> >> no
> >>>> longer draft, and issuing the CFP? Unless we have feasible dates
> >>>> attached to these milestones, things will continue to delay. As
> >> usual,
> >>>> if there is anything I can do to push things along, you can count
> on
> >> my
> >>>> help and support.
> >>>>>
> >>>>> Thanks...
> >>>>>
> >>>>> -- Ken
> >>>>>
> >>>>> On 2010/02/01, at 14:40, Levantovsky, Vladimir wrote:
> >>>>>
> >>>>>> Dear Ken, all,
> >>>>>>
> >>>>>> Thank you very much for your efforts and support for CFS
> >>>> development activity. I agree with you that any existing
> technology
> >>>> that is potentially a good fit for what we are trying to
> accomplish
> >>>> with CFS should be considered and discussed in details. I am happy
> >> to
> >>>> hear that Apple is open to contributing their Spliced Font Format
> as
> >> a
> >>>> basis for CFS effort, and that they are open to adding support for
> >>>> additional elements or attributes.
> >>>>>> However, from the AHG perspective - in order to successfully
> >>>> evaluate any and all candidate technologies, and determine and
> >> finalize
> >>>> the set of tags, elements and arguments needed to fulfill the
> stated
> >>>> goals it would be both useful and necessary to create a list of
> >>>> requirements we need to address. The requirements, and the open
> Call
> >>>> for Proposals that will follow, would allow us to make sure that
> we:
> >>>>>> - have a strong foundation for evaluating candidate technologies
> >>>> (such as Apple's Spliced Font Format, and maybe other solutions,
> >>>> including what AHG came up with during the exploration stage), and
> >>>>>> - develop a final solution that would fully satisfy the stated
> >>>> requirements, possibly by combining the best of all proposals we
> >> will
> >>>> have submitted in response to CFP. (It could be that we end up
> >> taking
> >>>> one particular solution as a basis and adding features from other
> >>>> solutions we discussed earlier - at this point I am reluctant to
> try
> >>>> and predict the outcome of this effort.)
> >>>>>>
> >>>>>> I also agree with Ken that CFS should be able to serve both as a
> >>>> composite font and as a fallback font mechanism. Nesting and
> >> recursion
> >>>> can be allowed if necessary, but, again - this is something we as
> >> the
> >>>> AHG will determine in the process of finalizing CFS requirements.
> >>>>>>
> >>>>>> Thank you and best regards,
> >>>>>> Vladimir
> >>>>>>
> >>>>>> P.S. I know some of you may wonder why Call for Proposals would
> >>>> even be necessary after all the efforts we, as the AHG, put in
> place
> >> to
> >>>> engage industry experts and invite them to join the group. Yes, we
> >> made
> >>>> a concerted effort to make public aware of this activity by
> >>>> distributing the information in all relevant public forums;
> however,
> >>>> the ISO process requires that public Call for Proposal should be
> >> issued
> >>>> to insure that all interested parties are notified about this
> >> activity
> >>>> through the official channels. In the end, it will only help us
> >> ensure
> >>>> that we have the best pool of contributors to this activity, even
> if
> >>>> the CFP itself doesn't bring 'new' proposals for consideration.
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-
> >>>> OTspec at yahoogroups.com]
> >>>>>>> On Behalf Of Ken Lunde
> >>>>>>> Sent: Monday, February 01, 2010 12:29 PM
> >>>>>>> To: mpeg-OTspec at yahoogroups.com
> >>>>>>> Cc: David Lemon
> >>>>>>> Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off
> >>>>>>>
> >>>>>>> Vladimir,
> >>>>>>>
> >>>>>>> I am very glad to see that WG11 is pushing us toward a
> standard.
> >>>>>>>
> >>>>>>> With that said, the highest priority for the AHG, in my
> opinion,
> >>>> is to
> >>>>>>> determine whether Apple's "Spliced Font Format" is suitable as
> >> the
> >>>>>>> basis for CFS. Apple confirmed that they are open to this, and
> >>>> they are
> >>>>>>> also open to adding support for any additional elements or
> >>>> attributes,
> >>>>>>> as long as they are considered optional. (The vast majority of
> >>>> elements
> >>>>>>> and attributes are optional, so I don't anticipate any issues.)
> >>>>>>>
> >>>>>>> To help with this effort, please reference/re-read my
> 01/15/2010
> >>>> email
> >>>>>>> to the AHG that summarized Apple's Spliced Font Format.
> >>>>>>>
> >>>>>>> Secondly, I once brought up the issue of nesting in the context
> >> of
> >>>> CFS,
> >>>>>>> and stated that it should not be allowed due to recursion and
> >>>>>>> complexity issues. However, I now believe that this should be
> >>>> allowed
> >>>>>>> in a specific context, because I believe that we can now
> >>>> distinguish
> >>>>>>> CFS objects that serve as composite fonts versus as fallback
> >>>> fonts. Let
> >>>>>>> me explain.
> >>>>>>>
> >>>>>>> CFS objects can serve two main purposes or functions,
> >> specifically
> >>>> as
> >>>>>>> composite fonts or as fallback fonts. I started going into this
> >>>>>>> distinction in my 01/08/2010 post to the mailing list.
> >>>> Specifically, a
> >>>>>>> CFS object functioning as a composite font requires a unique
> >> name,
> >>>>>>> meaning a name that is unique from any installed font, and
> unique
> >>>> from
> >>>>>>> any other CFS object that is functioning as a composite font.
> >>>> However,
> >>>>>>> a CFS object that functions as a fallback font takes on the
> name
> >>>> of an
> >>>>>>> existing font, which may be a standard font or potentially a
> CFS
> >>>> object
> >>>>>>> that functions as a composite font. This means that CFS-savvy
> >> OSes
> >>>> and
> >>>>>>> applications need to be prepared to deal with a CFS object and
> an
> >>>>>>> installed font with the same name, and to prioritize the CFS
> >>>> object for
> >>>>>>> obvious reasons.
> >>>>>>>
> >>>>>>> If you consider how fallback fonts work today, they take on the
> >>>> name of
> >>>>>>> an existing font resource, and describe composite font-like
> >>>> behavior,
> >>>>>>> such as referencing other font resources to provide glyphs for
> >>>>>>> characters that are not supported by the parent font resource.
> >>>>>>>
> >>>>>>> Getting back to the nesting of CFS objects, I now believe that
> >>>> this can
> >>>>>>> be allowed in CFS objects as long as what is being nested is a
> >> CFS
> >>>>>>> object that is functioning as a composite font. Furthermore, I
> >>>> propose
> >>>>>>> that the nesting depth should be one, meaning a top-level CFS
> >>>> object
> >>>>>>> that functions as a fallback font can reference one or more CFS
> >>>> objects
> >>>>>>> that function as composite fonts, but that those "nested" CFS
> >>>> objects
> >>>>>>> that function as composite fonts cannot reference any CFS
> objects
> >>>>>>> themselves.
> >>>>>>>
> >>>>>>> Regards...
> >>>>>>>
> >>>>>>> -- Ken
> >>>>>>>
> >>>>>>> On 2010/01/28, at 12:39, Levantovsky, Vladimir wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Dear AHG,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> First of all, I'd like to welcome many new members who have
> >>>> recently
> >>>>>>> joined the group - just for the past couple of weeks our group
> >>>> grew
> >>>>>>> stronger by 20+ members.
> >>>>>>>>
> >>>>>>>> At this time, the mandate for the AHG has been extended with
> new
> >>>> work
> >>>>>>> items - to produce the report summarizing the results of the
> >>>>>>> exploration activities and to propose and develop a timeline
> for
> >>>> WG11
> >>>>>>> to achieve stated goals of CFS standardization.
> >>>>>>>>
> >>>>>>>> The timeline should include the following steps that are part
> of
> >>>> the
> >>>>>>> ISO standards development process:
> >>>>>>>>
> >>>>>>>> - Finalization of complete list of requirements for Composite
> >>>>>>> Font Standard - these should include any and all features that
> we
> >>>>>>> believe should be part of the CFS (expected to be finished by
> the
> >>>> next
> >>>>>>> WG11 meeting in April 2010);
> >>>>>>>>
> >>>>>>>> - Creation and publication of the Call for Proposals for
> >>>>>>> either existing or developing technical solutions that would
> >>>> address
> >>>>>>> indentified list of requirements.
> >>>>>>>>
> >>>>>>>> - Review and analysis of responses to the Call for Proposal,
> >>>>>>> and publication of a working draft specification;
> >>>>>>>>
> >>>>>>>> - Creation of the Committee Draft (Proposed Draft Amendment if
> >>>>>>> applicable);
> >>>>>>>>
> >>>>>>>> - Final Committee Draft ;
> >>>>>>>>
> >>>>>>>> - Final Draft International Standard.
> >>>>>>>>
> >>>>>>>> As part of the requirements work, I suggest that we should
> >>>> identify
> >>>>>>> and document both features that are already supported by known
> /
> >>>>>>> existing technical solutions (such as features proposed by
> >> Adobe),
> >>>> as
> >>>>>>> well as features / capabilities implemented in Apple's Spliced
> >>>> Font
> >>>>>>> format and other technologies.
> >>>>>>>>
> >>>>>>>> We should also review and discuss the text of the draft
> >>>> corrigendum
> >>>>>>> for ISO OFF standard that was prepared at the WG11 meeting last
> >>>> week.
> >>>>>>> If there are any changes or corrections that need to be made -
> we
> >>>>>>> should review them and bring to the attention of the respective
> >>>>>>> National Bodies to be included as part of the ballot comments.
> I
> >>>> have
> >>>>>>> uploaded the draft to the AHG files.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thank you,
> >>>>>>>>
> >>>>>>>> Vladimir
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------
> >>>>>>>
> >>>>>>> Yahoo! Groups Links
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> 
> >>>
> >