[mpeg-OTspec] Toward a Composite Font format specification

[Daniel Strebe]

Vladimir:

Yes, I can conceive of countless cases where only partially fulfilling the creator's intent is still in the consumer's interest.

I realize we should be talking about concrete examples instead of exchanging disembodied statements of philosophy. Here I will present an elaborate example. I made it elaborate in order to highlight a lot of subtleties surrounding the potential uses of composite fonts. If you will please indulge me in a careful study of this scenario, I think you will better understand my advocacy.

Edward at Duotype has crafted a series of rich composite font recipes whose purpose is global text rendering with the best attainable readability at modern computer display resolutions. Each recipe in the Duotype World Series supports every major writing script, carefully matching the component fonts for design compatibility even in mixed-script usage. The recipe includes transformation matrices for subtly adjusting the baselines, widths and heights of the glyphs of some of the component fonts to better match against the others in mixed-script scenarios. The series contains many recipes each for serif and sans-serif designs, and italicized versions of each.

Marina is a university professor with a grant from her government to develop a detailed, interactive online ethnographic map of the world. The typographic elements of the map will be just place (and ethnic group) names, but with a twist: Not only will the place names be presented in the script of the viewer's choice, they will also be presented in the official script or scripts of the jurisdiction of the place name. Because the map must be viewable at a vast range of scales and on different map projections, Marina concludes they must get rendered real-time. Because the server budget is limited, she realizes much of the processing must be client-side. She is unable to meet all her objectives with any technology that delivered content through the browser, so instead she opted for a "rich internet application" (RIA), since this also allowed for offline perusal of the static portions of the website.

The grad student tasked with the typography discovers that the RIA framework's support for typography is no better than a typical Web browser's: It does not kern or even ligate basic forms. These restrictions are deemed unacceptable in the crowded conditions of cartographic typography, particularly given the common usage of all-caps. The project team understands they cannot not rely on the needed fonts being available on the viewer's machine, so they arrange for a license with the Fontkit Corporation to serve the specific fonts they need on demand. Fontkit Corporation uses a variety of techniques to obfuscate the font so that it cannot be casually re-used as a general-purpose font on the viewer's computer. One of those techniques, which also saves bandwidth, is to subset the font.

Because they must render the fonts themselves, they examine several possibilities. They find LiberationType, an open source project that would have been fine, but it was written in a computer language that was not compatible with the RIA's managed environment. They are also concerned about the size of the library, since the client must download it. Reworking the code for the managed environment is deemed too large a task, so they abandon LiberationType. Instead they find a much smaller library that an agency in their own government had written that parses the SFNT structures of TrueType and renders its outlines. It knows nothing about CFF or OpenType's advanced typography tables. The project conscripts a computer science student to extend the code enough to interpret a subset of GPOS and GSUB instructions so that they can render complex scripts correctly. This coincidentally solves their ligature and kerning problems as well.

The team's typography expert begins the onerous task of testing and matching typefaces for all the various writing scripts. In the course of his investigations, he comes across the Duotype World Series, a very welcome discovery indeed. They had already resigned themselves to a single font for each script because it was so hard to pair up fonts. They were not happy with that because they found that users in different parts of the world tended to prefer different fonts. But now it seems they could even let the viewer select fonts themselves, since Fontkit charges mostly for dispensing the font, not for the availability of the font. In other words, whether a single font is used a hundred times, or a hundred fonts are each used only once, the cost is about the same. The only problem is that the project's font system does not know how to handle composite fonts.

The component fonts in Duotype's World Series are all OpenType CFF fonts when purchased for desktop use, but Fontkit Corporation assures the team they can dispense the fonts as TrueType outlines, stripped of unnecessary tables. These practices are permitted in the license Fontkit has with the foundries. The project has no need for VDMX, vhea, vmtx, BASE, JSTF, chunks of GSUB and GPOS, and several other tables and portions thereof. They will never mix two scripts on the same line, so they do not care about relative baselines. They lay out no vertical text. They will never lay out a complete sentence. They do not need punctuation in any general sense. The slightly different aspect ratios of some of the components do not concern them because they do not mix text of the different component fonts on the same line. The unified design of the fonts within a recipe, and the recipe's selection of glyphs per language, are their reasons for wanting to use composite fonts.

The team investigates writing a composite font parser. They find many open source, generic XML readers, so they have no trouble parsing recipes. However, in the end they abandon using composite fonts because they discovered they would be "violating" the specification, and they worry they would get into some sort of trouble or be censured. They do not need OpenType in any general sense, do not need to support baseline shifts, do not care about digital signatures, have no interest in a missing font "fallback" algorithm. Yet we, the authors of the composite font specification "required" them to support those features. Why did we do this?

Regards,
- daan Strebe


On 09/09/18 7:07, "Levantovsky, Vladimir" <Vladimir.Levantovsky at MonotypeImaging.com> wrote:

Daniel,

I am not sure what you're asking, can you please elaborate? Is there an example or use case that you can present, where not fulfilling creator's intent would benefit a consumer?

Thank you,
Vlad


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090918/85573cf4/attachment.html>