[mpeg-OTspec] AHG on Open Font Format kick off

[Mikhail Leonov]

Dear all,
It is exciting to resume this conversation.

I'd like to recap some of the previous talking points on this issue.

The general goal is to create an industry wide specification for a composite font format that specifies rules that map Unicode ranges accompanied by language information to fonts.

To be successful and useful, such format should be reasonably easy to implement, and it should address key motivating scenarios such as multi-lingual font fallback and cases that are currently served by technologies such as WPF composite fonts and Adobe composite fonts used in Illustrator and InDesign.

Some issues to discuss:

1.      Physical font format. I believe at this point most people lean towards using standard XML, as it has advantages of being human readable and supported by numerous platforms, tools and libraries. Other ideas were to extend the existing OpenType file specification by introducing a new table or an additional 'cmap' subtable, or to use XAML format introduced by WPF. I advocated the latter approach because of the additional versioning features provided by XAML. However, I recognize that implementing support for XAML is costlier in practice than implementing support for standard XML, and this may hamper the adoption of the composite font format. At this point I would like to retract the proposal to specifically use XAML, and instead I suggest using regular XML for the composite font format.

2.      Versioning. I believe the composite font format should contain explicit provisions and recommendations regarding how future enhancements and additions to it will interact with software that interprets the first revision of the format.

3.      Naming of the composite font itself. Many scenarios require composite fonts themselves to have human readable names, so that they can be selected and manipulated by the end user. There are different opinions on whether composite font name is a mandatory or an optional feature. My preference is for the composite font to always be named. In addition, I suggest ability to include multiple localized names for a composite font. This is somewhat similar to OpenType 'name' table behavior.

4.      Target font scaling. There should be a provision to normalize the size of various target fonts so that they look reasonably well when used together to render a page of international text.

5.      Language information for Unicode ranges. To successfully disambiguate between overlapping CJK ranges, the format needs to include language information as well. Existing xml:lang syntax seems to be sufficient for this purpose. Here is an example from WPF composite font (exact syntax and naming in the new composite font format may be different, but the conceptual idea is the same):
        <!-- CHS -->
        <FontFamilyMap
            Unicode          = "2000-202E, 2030-20CF, 2100-23FF, 2460-27BF, 2980-29FF"
            Language         = "zh-Hans"
            Target           = "Microsoft YaHei, Meiryo, Segoe UI, SimSun, MS Gothic, Tahoma"
            Scale            = "1.0"/>
        <!-- CHT -->
        <FontFamilyMap
            Unicode          = "2000-202E, 2030-20CF, 2100-23FF, 2460-27BF, 2980-29FF"
            Language         = "zh-Hant"
            Target           = "Microsoft JhengHei, Meiryo, Segoe UI, MingLiU, MS Gothic, Tahoma"
            Scale            = "1.0"/>
        <!-- JA -->
        <FontFamilyMap
            Unicode          = "2000-202E, 2030-20CF, 2100-23FF, 2460-27BF, 2980-29FF"
            Language         = "ja"
            Target           = "Meiryo, Segoe UI, MS Gothic, Tahoma"
            Scale            = "1.0"/>
        <!-- KO -->
        <FontFamilyMap
            Unicode          = "2000-202E, 2030-20CF, 2100-23FF, 2460-27BF, 2980-29FF"
            Language         = "ko"
            Target           = "Malgun Gothic, Segoe UI, Gulim, MS Gothic, Tahoma"
            Scale            = "1.0"/>

6.      Target font formats. A hard requirement is that the target font format needs to support Unicode. However, this requirement can be interpreted in different ways. Some may require Unicode to be an integral part of the target font format specification - OpenType format satisfies this requirement, and so does composite font format itself if we are to allow recursion (more on that later.) Others may simply require a way to infer Unicode support from the target font format, which may enable composite fonts to support older formats such as Type 1 and .FON. This is an open area with lots of details to settle even if we were to only allow OpenType target fonts.

7.      Recursion. The issue is whether a composite font can refer to other composite fonts in the target font section. Ken Lunde prefers a flat non-recursive format for simplicity reasons.
I prefer the approach that allow recursion because it allows for more flexibility on the application and platform side. To quote my previous email on the subject:

"While I understand that some platforms don't require recursive fallback and are not built to support it, in the long run  I feel that not supporting recursion in this format would be a serious limitation. For example, imagine a font vendor or a high end design application installing a pre-set composite font A that provides great uniform appearance of multi-lingual text in general, but doesn't include Indic scripts. I chose Indic here because the support for it varies widely today across multiple platforms and applications. Next, imagine an email application or a word processor that defines a stylistically consistent set of multi-lingual text that has wider coverage than composite font A and supports Indic scripts (the said application may have installed additional Indic fonts for this purpose.)

If a user pastes or imports a rich text paragraph that primarily uses composite font A into the email application/word processor, it may create on the fly composite font B that prefers using A for the supported scripts, and its own set of fonts for other scripts such as Indic. Note that this is all done before the system default fallback takes place. I believe there has to be at least one level of recursion possible in order to make this scenario work. Obviously, with more nesting and document interop/import there will be more levels of recursion required."

8.      Font family or font face. Does a composite font specify a font family or a font face? I believe so far the assumption has been that it defines a font family. One benefit of this approach is ability to define one set of rules that covers a large number of font weight/width/slope combinations. However, we have not specified what face grouping approach will be used. OpenType, for example, defines several sets of family and face names for various platforms. Microsoft's long term preference is to group faces into families using weight/width/slope rules introduced by WPF. However, other platforms use different font family grouping rules. This is something we need to rationalize, especially if composite fonts end up supporting multiple target font formats.

9.      Cross font properties. This is related to issue 4. It may be desirable to have some shared properties that override target font properties, for example one may want to have a single underline position and thickness for a line of text render using several target fonts. Another important property is line spacing - it is usually desired to have uniform line spacing in a paragraph of text even if multiple fonts are used inside it.

I would like to make a suggestion on subsequent discussions. Let's create new topics for each open issue, with its brief description in the subject line. For example, we can create "Target font formats" or "Composite font recursion" topics to limit the scope to these particular issues. How does this sound?

Best regards,
Mikhail Leonov
Microsoft


From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Levantovsky, Vladimir
Sent: Thursday, February 19, 2009 2:45 PM
To: Ken Lunde
Cc: mpeg-OTspec at yahoogroups.com; Karsten Luecke
Subject: RE: [mpeg-OTspec] AHG on Open Font Format kick off


Dear Ken,

First of all, addressing the last point in your email - I've sent an
invitation to Karsten to join this group. I also would like to remind
people once again that the participation in this group is open to any
individual, regardless of their affiliation. A participant does not need
to receive an invitation in order to join the group - it can be done
either through the web (http://tech.groups.yahoo.com/group/mpeg-OTspec/)
or by sending email to
mpeg-OTspec-subscribe at yahoogroups.com<mailto:mpeg-OTspec-subscribe%40yahoogroups.com>

Thank you for providing the summary of Adobe composite fonts solution.
Since prior discussions happened outside the scope of this AHG, I think
that in order to have a productive discussion we should make an effort
to bring everyone up to date regarding different ideas and proposals
discussed earlier. Your email is a very good step in this direction and
I would like to ask other participants to present their views and ideas
on this subject on this email list. Alternatively, any participant may
prepare a document outlining your views and ideas, and upload it to AHG
file storage for further review and discussion on this email list.

Thank you,
Vladimir

> -----Original Message-----
> From: Ken Lunde [mailto:lunde at adobe.com<mailto:lunde%40adobe.com>]
> Sent: Thursday, February 19, 2009 5:06 PM
> To: Levantovsky, Vladimir
> Cc: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec%40yahoogroups.com>; Karsten Luecke
> Subject: Re: [mpeg-OTspec] AHG on Open Font Format kick off
>
> Vladmir,
>
> Many thanks for setting up this AHG. I have a lot of irons in
> the fire at the moment, and I am guessing that others can say
> the same.
>
> Still, it is important for this project to move forward.
>
> One of the sticking points in previous discussions, which may
> have caused them to stall, was our insistence that the
> resulting fonts be cross-platform, which meant limiting the
> font format of the component fonts, and requiring built-in
> Unicode support. After discussing this point with key people
> from Apple, we now agree to lift this restriction. Instead, I
> would strongly recommend that the format supports a flag that
> indicates that the Composite Font format is intended to be
> cross-platform, and if it is enabled, some aspects become
> more strict, such as limiting the font format to those that
> can be cross-platform (this would exclude OCF, sfnt-CID, and
> any resource- fork font) and requiring built-in Unicode
> support. With this flag turned off, correctly handling the
> component fonts then becomes the responsibility of the
> client, which may be an OS.
>
> As stated in previous discussions, Adobe Systems has
> implemented Composite Font support in several ways. Our ATC
> (Adobe Type Composer) application was a rather simple
> front-end to our AdobeTypeComposer ProcSet that allowed
> various components to be used together, and was limited to
> Shift-JIS encoding with its user-defined region. Some of our
> flagship applications, such as InDesign and Illustrator,
> include built-in Composite Font support that allows customers
> to select a Base Font, then select other fonts to serve as
> replacements for various character classes, such as Latin,
> symbols, punctuation, and kana. At a high level, perhaps for
> Composite Fonts that are not declared to be cross-platform,
> script-based labels can suffice. But, for those that have
> been declared for cross-platform use, the script-based labels
> should function to specify specific Unicode ranges. The
> format itself should also allow the granularity to be at the
> code point level, meaning that specific code points, not code
> point ranges, should be permitted. Specifying language also
> has value, in that it allows this format to accommodate the
> building of Pan-CJK fonts.
>
> One of my preferences, as conveyed in previous discussions,
> is that Composite Font definitions be flat, meaning that a
> Composite Font cannot use another Composite Font as a
> component. A front-end for creating Composite Font
> definitions could allow a user to specify a Composite Font as
> a component, but that it would need to be flattened.
> Considering how complex fonts can become, limiting (or
> preventing, in this case) recursion is probably a good thing.
>
> In terms of the file format itself, for obvious reasons it
> should be XML, which means that it can be human- and machine-readable.
>
> Lastly, I would like to request that Karsten Luecke
> (karsten.luecke at kltf.de<mailto:karsten.luecke%40kltf.de>
> ) be added to this discussion. His insights and opinions will
> be valuable.
>
> Regards...
>
> -- Ken
>
> On 2009/02/17, at 10:58, Levantovsky, Vladimir wrote:
>
> >
> > Dear AHG OFF members,
> >
> > First of all, I would like to welcome our new members of
> the group and
> > thank all group members for their contributions and continued
> > participation.
> >
> > This message is an official kick off of the new AHG exploration
> > activities.
> > The AHG mandates, as established at the 87th WG11 meeting are:
> > 1. To explore possible ways to overcome the 64K limit of
> the number of
> > glyphs in the existing font format specification. The preferred way
> > should not adversely affect any existing implementations
> and should be
> > backward compatible with the existing OFF specification.
> >
> > 2. To produce a report outlining the results of the exploration
> > activities and propose a way forward for WG11 to achieve
> stated goals.
> >
> > All activities of the AHG will be conducted on this reflector; a
> > telephone conference call can be arranged and, if
> necessary, should be
> > scheduled with advanced two-week notice. The group members
> also have
> > unrestricted access to Web-based message archive
> > (http://tech.groups.yahoo.com/group/mpeg-OTspec/messages
> > ) and file storage
> > (http://tech.groups.yahoo.com/group/mpeg-OTspec/files/
> > ).
> >
> > The subject of 64K limit in OFF/OpenType/TrueType fonts have been
> > raised a number of times in the past. Many of AHG participants have
> > voiced their opinions on the issue and I would like to
> invite all of
> > you to contribute your ideas and suggestions to this group for
> > continued discussion. Our goal is to come up with the
> recommendations
> > and working draft of the future specification that will help to
> > eliminate or overcome the restriction of 64K glyphs in a font.
> >
> > Thank you very much for your efforts.
> > With kind regards,
> > Vladimir
> >
> >
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090224/7fb71a9b/attachment.html>