[mpeg-OTspec] Toward a Composite Font format specification

[Levantovsky, Vladimir]

Daan,

 

Thank you for presenting a very elaborate use case, I really appreciate
it. It brings attention to some very specific details but, first and
foremost, I think it will by and large help us better understand the
concepts of mandatory features in a specification language; and, in
particular, it may help us better understand the scope and goals of the
Composite Fonts specification.

 

First of all, I would like to make sure we are all on the same page when
it comes to the meaning of the notion of "mandatory" or "required"
components in a specification - they exist and are useful only for the
purposes of defining the meaning of "compliant implementation" and
establishing certain conformance points. There is no such thing as
'standards police', and "violation" of a specification by not following
its recommendations or requirements (and/or not implementing everything
that is deemed mandatory) does not result in any repercussions for the
implementer. In the worst case, the only "punishment" for not following
the spec mandate may be inability to claim compliance with that
standard, and in some circumstances, being compliant to the spec may
bring certain market advantages (e.g. an opportunity to use a spec logo
to promote a final product). Some standards organizations (e.g. those
that define hardware-acceleration or software development APIs) and
their specifications are very rigid about "enforcing" the conformance
requirements by mandating implementers to run and pass a standardized
test suite as part of self-certification process. Sometimes, they even
require to submit the test results to be validated by a standards
organization, e.g. in exchange for a grant to use its logo on a final
product. However, in many cases implementers are free to make their own
choices whether or not to follow all specification requirements - the
result of creating a non-compliant implementation may be justified by
the market conditions. 

 

For example, if I wanted to build a closed-circuit digital video
surveillance system using MPEG-4 AVC video standard - I may choose not
to implement some video compression/decompression tools that would be
mandatory for a Blu-Ray DVD player. My video surveillance system may
work just fine without them, and I'd have no need or intention to claim
that my video encoding/decoding capabilities are compliant with the
standard that all DVD players must adhere to. To summarize - I'd only
have to implement all mandatory parts of the standard if I

-          need to be compliant to pass a standardized conformance test,
and/or

-          want to advertize my product as compliant with a particular
standard.

 

Now, let's go back to the use case you presented:

 

1)      The team of developers decided to create a "rich internet
application (RIA)" client where its sole purpose is to render
interactive online map. They concluded that "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." Based on
the facts you presented, I think that it would be fair to say that the
RIA client has very limited scope. Therefore, implementing a limited
subset of Composite Fonts specification may satisfy their needs even
though the RIA developers would never be able (and likely would have no
intention) to claim compliance with the standard. And, if they don't
claim a conformance to the spec, there is no harm done and there is no
authority that would be in a position to "punish" them.

 

2)      Let's assume that the RIA team has been successful in delivering
everything they planned for, and their very next step would be to build
on their own success and enhance their application by accommodating
end-user suggestions to introduce a new feature - e.g.  displaying a
paragraph of text with ethnic data when an end-user clicks on the name
of the ethnic group or their territory on the map. The RIA team may
suddenly realize that they do need to support punctuation and lay out
complete sentences, and be able to mix two scripts on the same line
because "the place names [and now the description text should] 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."  All of a sudden, "the grad student tasked with the
typography discovers that the [newly developed] RIA framework's support
for typography is no better than a typical Web browser's", and that the
industry experts who wrote Composite Fonts specification did have a
point when they said that certain features defined by the standard must
be supported by all implementations.

In fact, this is another important role of the standards specifications
- many implementers do not possess the same level of expertise in a
particular field (as spec authors do), and they rely on industry /
international standards to provide clear guidance and specify the set of
requirements that must be satisfied to make their implementations
compliant and useful.

 

3)      This use case brings even more important aspects to consider.
"Marina is a university professor with a grant from her government to
develop a detailed, interactive online ethnographic map of the world ...
Marina concludes they [place (and ethnic group) names] 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". (emphasis is added).

The developers of RIA client wouldn't have been in a position where
they'd have to develop their own text processing engine with such a
limited scope if they had a choice of standard-compliant  text rendering
implementations that are either readily available or simply supported by
a platform of their choice. And, assuming that browser vendors had
followed the standards as well, Marina might have come to a different
conclusion that the existing infrastructure of standards-compliant
solutions would provide her with everything she needs to develop and
deploy valuable new content and service - with minimal efforts, no
market fragmentation introduced by a custom RIA client, and without any
need for custom development (all this while saving government's and
taxpayer's money!).

 

Regards,

Vladimir

 

 

From: Daniel Strebe [mailto:dstrebe at adobe.com] 
Sent: Friday, September 18, 2009 3:15 PM
To: Levantovsky, Vladimir; Ken Lunde; mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Toward a Composite Font format specification

 


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/20090921/5830d1b4/attachment.html>