[mpeg-OTspec] Optically-tuned font size in composite fonts

Mikhail Leonov Mikhail.Leonov at microsoft.com
Fri Jul 10 00:03:33 CEST 2009


Hi John,
We at Microsoft are also interested in potentially using composite fonts to make font selection decisions based on the font size range.

I believe this can be achieved by introducing a new optional attribute that describes the desired font size range for a ComponentFont element.

Another suggestion I have is to provide optional attributes for adjusting font selection parameters for a ComponentFont element. For example, some script and font combinations don't support emboldening and italicization, so ComponentFont entries for such combinations could explicitly suppress these. This way, an application does not have to special case scripts and fonts for such adjustments.

Best regards,
Mikhail Leonov
Microsoft

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of John Hudson
Sent: Saturday, June 27, 2009 10:58 AM
To: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] Optically-tuned font size in composite fonts





Dear All,

So far, we've been looking at composite fonts primarily in terms of
overcoming the 64K glyph set limit and providing multi-script support
from different source fonts within a single composite font. I'd like to
consider the possibility of using composite fonts to support multiple
optically-tuned fonts for different sizes of text. I presume the
participants of this group are familiar with the desirability of
optically-tuned fonts (also referred to as 'optical scaled' fonts or
'optical size' fonts), i.e. designs that are intended to be used at
specific sizes or ranges of sizes, often within a coordinated family of
optically-tuned fonts for e.g. display, subhead, text, captions/notes or
more precisely tuned fonts for individual sizes. [Anyone seeking a
better understanding of these things should order a copy of Tim Ahren's
very good book _Size-specific adjustments to type designs_.]

In metal type, type was by its nature size-specific and usually
optically-tuned, either in the letter design stage or during
punchcutting. In digital type, the most common mechanism to date has
been the production of independent fonts for different size ranges.
Conceivably, the optically tuned glyphs for different sizes could be
contained within a single font, addressed through a substitution
mechanism, or a single set out outlines could be parametrically or
individually manipulated for different sizes (or a combination of these
approaches could be used, e.g. applying substitution for basic sizing
and then hinting for device dependent adjustments).

Attendant on any implementation of optically-tuned fonts is the problem
of letting txt layout engines and applications know which font (or which
set of glyphs within a font) to use for which size(s). Leaving aside,
for now, models in which all the optically-tuned glyphs reside in the
same source font (since this implies possible impact of the 64K TT/OT
glyph set limit, and hence cannot be considered a scaleable solution (no
pun intended)), there are a number of possible ways in which fonts might
contain information usable by engines and applications to select an
appropriately tuned design for a particular size. [I'm also leaving
aside, for now, the tricky issue of nominal (pt) sizes in a variety of
low resolutions, implying cruder scaling factors that accounted for in
outline designs for higher resolution output.]

1. There exists in the current registered OpenType Layout feature set a
nominal GPOS feature <size> that can be used to store information
indicating at what sizes the font is intended to be used. I consider
this a hack. It isn't really a GPOS feature; rather, the GPOS lookup
structure is hijacked to store some basic size information. Since
selecting an optically-tuned font is a pre-layout requirement, one is
left with a mechanism in which this one GPOS feature needs to be
consulted by an engine or app before any other features are applied,
contrary to all other GPOS features, which are normally processed
down-stream of GSUB features. There are also tool issues surrounding
this feature, which means that only Adobe, to my knowledge, have
consistently included support for this feature in their optically tuned
fonts.

2. The idea has been put forward (on the OpenType developer list,
Typophile forums, and during development of the OT 1.6 spec) of a
dedicated 'size' table, which would contain information about both the
size(s) at which the individual font should be used and also its
relationship to other fonts in the same family. [In theory, this
information could also be put into an extension of an existing table,
e.g. OS/2.] Specification of such a table seems stalled by disagreement
over what it should contain.

I would like to consider the possibility of building optically-tuned
font selection information into the headers of the composite font,
alongside the script selection information that it, in many ways,
parallels (with the obvious implication that there may be quite complex
interaction between these sets of information, e.g. a composite font may
contain source fonts for different scripts with different sets of
optically-tuned designs, or might provide optically-tuned designs for
some scripts but not for others.

There are two ways in which this might be considered:

a) as a higher-level mechanism for optically-tuned font selection,
overriding whatever mechanism might be defined within the source fonts
('size' table or <size> feature); this offers users creating composite
fonts the possibility to assert their own preferences against the
decisions of the font developers;

b) as *the* mechanism for optically-tuned font selection, i.e. we give
up on the idea of including size selection information in the source
fonts and say that the way to define use of optically-tuned fonts is
through their inclusion in a composite font.

Regards, John

--

Tiro Typeworks www.tiro.com
Gulf Islands, BC tiro at tiro.com<mailto:tiro%40tiro.com>

Car le chant bien plus que l'association d'un texte
et d'une mélodie, est d'abord un acte dans lequel
le son devient l'expression d'une mémoire, mémoire
d'un corps immergé dans le mouvement d'un geste
ancestral. - Marcel Pérès

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090709/5270d3ca/attachment.html>


More information about the mpeg-otspec mailing list