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

Sun Feb 28 17:14:39 CET 2010

Ken,

We are fast, but not fast enough.

If CfP is issued in April this is what can happen

1.      July 2010

a.      Receive proposals

b.      Produce WD

2.      October 2010

a.      Publish CD

3.      January 2011

a.      Receive comments

b.      Publish FCD

4.      April 2011

a.      Publish "study of FCD" (if we feel like that

5.      July 2011

a.      Publish FDIS

This is as fast as the ISO rules allow us to move. Note that even if we
published CD in July 2010 the time line would not change because we do not
have 3 months between July and October

Leonardo 

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On
Behalf Of Ken Lunde
Sent: 28 February 2010 15:37
To: Levantovsky, Vladimir
Cc: mpeg-OTspec at yahoogroups.com; David Lemon
Subject: Re: [mpeg-OTspec] AHG on Font Format Kick-off

Vladimir,

Thank you. I vote for the more aggressive three-month CFP period. I feel
that this is necessary if we want this standard to be done by the end of the
year.

Regards...

-- Ken

On 2010/02/26, at 9:00, Levantovsky, Vladimir wrote:

> Ken,
>
> The AHG should finalize the text of requirements and the draft CFP before
the next meeting. Since the draft requirements and use cases have already
been approved by the WG11, and there are likely to be only minor changes to
the document, I anticipate that both the "Requirements and Use Cases" and
the "Call for Proposals" will be finalized and published at the same time in
the end of the next MPEG meeting in April.
>
> It is also up to the AHG to come up with the recommendations on the
proposal submission deadlines. If we want to move fast, we can recommend the
submission period be shortened to three month, with the deadline set right
before the beginning of the MPEG meeting in July 26-30. Assuming that the
CFP is published on the last day of WG11 meeting on April 23, it would be
possible (although somewhat aggressive) to choose the submission deadline be
July 23rd, 2010. Alternatively, if we want to allow more time for people to
respond to CFP, we can extend the deadline until the MPEG meeting in October
11-15.
>
> Regards,
> Vladimir
>
>
>> -----Original Message-----
>> From: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com>
[mailto:mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.com> ]
>> On Behalf Of Ken Lunde
>> Sent: Thursday, February 25, 2010 10:05 PM
>> To: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.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%40yahoogroups.com>
[mailto:mpeg-
>> OTspec at yahoogroups.com <mailto:OTspec%40yahoogroups.com> ] On Behalf Of
Ken Lunde
>>> Sent: Thursday, February 11, 2010 5:47 PM
>>> To: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.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%40yahoogroups.com>  [mailto:mpeg-
>> OTspec at yahoogroups.com <mailto:OTspec%40yahoogroups.com> ]
>>>>> On Behalf Of Ken Lunde
>>>>> Sent: Monday, February 01, 2010 12:29 PM
>>>>> To: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100228/e5ce3b64/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100228/e5ce3b64/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100228/e5ce3b64/attachment-0001.bin>