<HTML>
<HEAD>
<TITLE>Re: [mpeg-OTspec] AHG conference call - Composite Fonts Requirements</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Ken,<BR>
<BR>
Thanks for the detailed notes. Lots of good thinking.<BR>
<BR>
I have an alternate perspective on your final comments:<BR>
<BR>
Related to this, I still like the idea of a flag or setting that <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>effectively increases the strictness. This setting should be off by <BR>
default, but when it is turned on, several requirements kick in, such <BR>
as format and encoding restrictions, and specifying version numbers of <BR>
Component Fonts. I think that this is within the spirit of the third <BR>
policy choice as indicated above. It provides to the Composite Font <BR>
author flexibility in the degree to which aspects of the format are <BR>
mandated. That is also the spirit of XML, which is the format that we <BR>
have chosen.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
My thoughts are that the creator’s intent is already demonstrated by the presence of the information in the composite font recipe, insofar as we do not capriciously mandate that recipes carry information the creator does not care about. How far to enforce that intent is a decision that properly belongs to the consumer. Therefore I would view a “strictness” setting as redundant. If the creator did not intend something, then it should not be in the recipe. Even if the creator did intend something, it has no way (or reason) to enforce it in an inclement environment. A consumer should do its best to preserve the intent as implied by the recipe in all cases. That is the best anyone can hope for. Hopefully any consuming environment that cares about fidelity will always notify the human of problems in reconstructing the intent expressed by the recipe.<BR>
<BR>
Regards,<BR>
— daan Strebe<BR>
<BR>
<BR>
On 09/05/11 11:55, "Ken Lunde" <<a href="lunde@adobe.com">lunde@adobe.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Vladimir,<BR>
<BR>
Thank you for distributing the meeting notes.<BR>
<BR>
We are one week from the next meeting, and it seems that some of the <BR>
discussions that need to take place before then have not yet started.<BR>
<BR>
In an effort to kick this off, I decided to comment on the meeting <BR>
notes. I extracted the text, and reformatted it as plain text.<BR>
<BR>
> Composite Fonts<BR>
> AHG conference call minutes<BR>
> May 4th 2009, 3:00 pm PDT<BR>
> List of Participants<BR>
> Jeff Carey (Monotype Imaging)<BR>
> Peter Constable (Microsoft)<BR>
> Greg Hitchcock (Microsoft)<BR>
> John Hudson (Tiro Typeworks)<BR>
> Mikhail Leonov (Microsoft)<BR>
> Vladimir Levantovsky (Monotype Imaging)<BR>
> Ken Lunde (Adobe)<BR>
> Sergey Malkin (Microsoft)<BR>
> Michelle Perham (HILL) (Microsoft)<BR>
> Daniel Strebe (Adobe)<BR>
> Suzuki Toshiya (Hiroshima University)<BR>
<BR>
I am glad that we seem to have the right mix of people and companies <BR>
for this, but there is one rather large hole, specifically the lack of <BR>
someone from Apple. I realize that they are busy, but I am sure that <BR>
the rest of us can state the same thing. Is anyone from Apple on this <BR>
mailing list? In other words, did they choose not to attend last <BR>
week's meeting, or were they simply not aware of it. I simply want to <BR>
know that they are on board, either in person or in spirit. In other <BR>
words, if we settle on a format, but if it doesn't serve Apple's <BR>
needs, that's a huge strike against it from Day One.<BR>
<BR>
> Advanced Layout Features<BR>
><BR>
> o Should cross-Component Font layout (e.g. GSUB / GPOS, kerning <BR>
> between glyphs from different Component Fonts) be considered?<BR>
> - Microsoft is against allowing interaction on GPOS/GSUB level <BR>
> between different component fonts (this is glyph specific for each <BR>
> component font, interactions between components are very complex)<BR>
> - Each component font should have code ranges and language tags <BR>
> identified, and will be used based on this information.<BR>
> - Adobe's position is similar to Microsoft<BR>
> - There may be a need to identify / implement additional language <BR>
> or script tags<BR>
> - "Master font" may serve as a default fallback in a Composite <BR>
> Font solution<BR>
> - A separate email thread will be setup to continue this <BR>
> discussion and define the appropriate solution<BR>
<BR>
Advanced layout feature operate at the glyph (GID) level, so this <BR>
limitation is reasonable. Furthermore, GIDs cannot serve as the glue <BR>
to hold together a Composite Font. That is where encoding comes in.<BR>
<BR>
> Character Encoding<BR>
><BR>
> o Should Component Fonts be required to support the same CMAP table <BR>
> format(s)<BR>
> - No, Composite Fonts will need to support component fonts with <BR>
> different CMAP subtable formats<BR>
<BR>
The example I provided during the meeting was that BMP-only fonts may <BR>
use Format 4, but that fonts with mappings beyond the BMP may use <BR>
Format 12. Of course, this is considering only Unicode. Speaking of <BR>
Unicode...<BR>
<BR>
> o Should at least one Unicode based CMAP be mandated<BR>
> - No, Unicode mapping should not be a requirement but a font <BR>
> engine should be able to map Unicode code points to internal font <BR>
> character mapping table<BR>
<BR>
While I agree that this should not be mandated, Unicode should be very <BR>
strongly encouraged. While it is true that non-Unicode encodings can <BR>
interoperate with Unicode for the most part, it does mean that <BR>
heuristics will be involved, and clients will need to ether provide <BR>
their own mapping tables, or rely on those provided in a library or <BR>
through an OS-level API. The danger, of course, is that the way in <BR>
which the glyphs are mapped to Unicode may slightly differ from one <BR>
client to another. There may also be a change over time. When this <BR>
information is included in the font, it is used as-is.<BR>
<BR>
Looking at the current Composite Font solutions, such as Adobe Type <BR>
Composer and the Composite Font feature of some Adobe applications, <BR>
encoding is the glue that holds the fonts together. There are, of <BR>
course, some limitations, but customers define Composite Fonts because <BR>
their advantages outweigh their disadvantages. Adobe Type Composer <BR>
used Shift-JIS encoding as its glue, and newer solutions are using <BR>
Unicode.<BR>
<BR>
Clearly, when a Composite Font based on this new format is defined, <BR>
Unicode ranges will play an absolutely huge role in defining how the <BR>
component fonts are to be used.<BR>
<BR>
> Composite Fonts Metrics<BR>
><BR>
> o No-clipping zones (should max ascender and descender values from <BR>
> different Component Fonts be used to calculate no-clipping zones?)<BR>
> - not discussed at this time<BR>
><BR>
> o Line spacing<BR>
> - using ascender and descender to define line metrics may be <BR>
> deficient – certain scripts may be affected by much wider spacing <BR>
> defined for other languages / scripts.<BR>
> - Using BASE table is recommended but its presence in a component <BR>
> font is not required<BR>
> - Will have a separate discussion on the email list<BR>
<BR>
This is complex. While Adobe Systems is including the 'BASE' table in <BR>
every OpenType font it builds, we realize that it cannot be required. <BR>
In lieu of the 'BASE' table, Apple includes the 'bsln' table in its <BR>
AAT fonts.<BR>
<BR>
The issue is how these are defined. Ideally, they would be calculated. <BR>
And, this calculation is not so simple. It is likely that only a <BR>
fraction of the glyphs in a Component Font are referenced in a <BR>
Composite Font, meaning that it would be unwise (and inaccurate) to <BR>
use the advertised ascender and descender values as-is.<BR>
<BR>
Clearly, this area needs further and deeper exploration.<BR>
<BR>
> o Whether a single Component Font should be considered as a "default <BR>
> font" for the purpose of defining Composite Font metrics<BR>
> - No. The preferred (agreed) way is to have default line metrics <BR>
> specified in the Composite Font header.<BR>
<BR>
The Composite Font formats that we (Adobe Systems) have defined in the <BR>
past have used the notion of "default font," and leveraged it to <BR>
define the Composite Font line metrics. But, I agree that for this <BR>
format, due to its wider application, that this should not be done.<BR>
<BR>
> Items for Consideration<BR>
><BR>
> o Use of recursion in Composite Fonts<BR>
> - Recursion is not allowed, a Composite Font can not include <BR>
> another Composite Font as a component<BR>
<BR>
I'd like to stress the importance of this. Given the current state of <BR>
the discussions, the more unknowns that we remove, the better. <BR>
Recursion adds complexity with little benefit. While a client that <BR>
builds a Composite Font file might allow this, when the Composite Font <BR>
file is written, any Component Fonts that are Composite Fonts must be <BR>
flattened. This is an implementation issue.<BR>
<BR>
> o Component Font formats<BR>
> - Composite Font solution will not impose any requirements on the <BR>
> underlying component font formats<BR>
> - Format ID field is not required<BR>
> - Mapping of the component font to a specific font resource is TBD<BR>
<BR>
There are three issues here. One is how to identify fonts. Another is <BR>
where they are located. A third is how to handle font families.<BR>
<BR>
While I cannot speak about TrueType, when an OpenType font is handled, <BR>
there are two choices for identifying the font by name:<BR>
<BR>
name.ID=6<BR>
name.IDs 16 and 17 (1,3,0x409; if defined), otherwise name.IDs 1 <BR>
and 2 (1,3,0x409)<BR>
<BR>
Of course, the advantage of using name.IDs 16 and 17 (or 1 and 2, if <BR>
16 and 17 are not defined), is that the handling of the font family <BR>
becomes possible. I also specified the 1,3,0x409 (Microsoft, Unicode, <BR>
English) strings, because they represent the lowest common denominator.<BR>
<BR>
For legacy PostScript-based font formats, such as OCF and sfnt-CID, <BR>
only the PostScript name can be reliably used.<BR>
<BR>
There was also discussion about more positively identifying the font, <BR>
which would be done by specifying a version number. This could be <BR>
exact, or as a minimal value.<BR>
<BR>
Locating the fonts should not be part of the format, because it is <BR>
implication-specific. Because the Composite Font is merely a recipe, <BR>
if an environment is missing any Component Fonts, the likelihood of <BR>
missing fonts is rather high. It depends on the nature of the <BR>
Composite Font and its use. If it is built and supplied by the OS, the <BR>
likelihood will be low. If it is built by an end user, the likelihood <BR>
will be high. This is the nature of Composite Fonts.<BR>
<BR>
Handling font families needs to be defined in the format. Why? The <BR>
mapping between font families is not one-to-one. CJK fonts, for <BR>
example, do not include italic versions of their ideographs. But, if <BR>
the Composite Font is expected to handle italic text for the Latin <BR>
glyphs, this behavior, and mapping of family members, must be <BR>
specified. Also, the full range of font family members cannot expected <BR>
to be handled via this format. I envision such limitations.<BR>
<BR>
> Composite Font policy decision<BR>
><BR>
> o In order to facilitate the design of the Composite Font solution <BR>
> we need to agree on the general policy:<BR>
> - Make it as simple as possible, or<BR>
> - Mandate all sorts of things to make sure everything works, or<BR>
> - Mandate as little as possible but provide as much information as <BR>
> possible to insure that everything can work as intended<BR>
<BR>
I am gravitating toward the third one. It seems to have the right <BR>
balance. Whether the Composite Font works as intended depends on how <BR>
it was defined.<BR>
<BR>
Related to this, I still like the idea of a flag or setting that <BR>
effectively increases the strictness. This setting should be off by <BR>
default, but when it is turned on, several requirements kick in, such <BR>
as format and encoding restrictions, and specifying version numbers of <BR>
Component Fonts. I think that this is within the spirit of the third <BR>
policy choice as indicated above. It provides to the Composite Font <BR>
author flexibility in the degree to which aspects of the format are <BR>
mandated. That is also the spirit of XML, which is the format that we <BR>
have chosen.<BR>
<BR>
> o A separate follow-up discussion on the AHG email list is needed<BR>
<BR>
Let's try to continue these discussions this week so that we can make <BR>
progress during next Monday's meeting. :-)<BR>
<BR>
Regards...<BR>
<BR>
-- Ken<BR>
<BR>
<BR>
<BR>
------------------------------------<BR>
<BR>
Yahoo! Groups Links<BR>
<BR>
<*> To visit your group on the web, go to:<BR>
<a href="http://groups.yahoo.com/group/mpeg-OTspec/">http://groups.yahoo.com/group/mpeg-OTspec/</a><BR>
<BR>
<*> Your email settings:<BR>
Individual Email | Traditional<BR>
<BR>
<*> To change settings online go to:<BR>
<a href="http://groups.yahoo.com/group/mpeg-OTspec/join">http://groups.yahoo.com/group/mpeg-OTspec/join</a><BR>
(Yahoo! ID required)<BR>
<BR>
<*> To change settings via email:<BR>
<a href="mailto:mpeg-OTspec-digest@yahoogroups.com">mailto:mpeg-OTspec-digest@yahoogroups.com</a><BR>
<a href="mailto:mpeg-OTspec-fullfeatured@yahoogroups.com">mailto:mpeg-OTspec-fullfeatured@yahoogroups.com</a><BR>
<BR>
<*> To unsubscribe from this group, send an email to:<BR>
<a href="mpeg-OTspec-unsubscribe@yahoogroups.com">mpeg-OTspec-unsubscribe@yahoogroups.com</a><BR>
<BR>
<*> Your use of Yahoo! Groups is subject to:<BR>
<a href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>