From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon May 21 2007 - 18:48:17 CDT
mpsuzuki@hiroshima-u.ac.jp wrote:
> "Philippe Verdy" <verdy_p@wanadoo.fr> wrote:
> > Is the OTC extension for Opentype able to handle such case, by creating
> > in a single font file multiple fonts packed together, and crosslinked
> > with an explicit fallback from one font to the other in the same pack?
>
> Excuse me, OTC is the OpenType/TrueType Collection
> described in OpenType specification v1.4? If so,
> I remember, it doesn't mention anything about the
> relationship among the faces included in same package
> (if I'm wrong, please correct). In fact, Microsoft
> had ever used TTC to pack independent faces (think
> about Courier & Helvetica) into single file, for
> Japanese and Korean markets. There might be requirement
> to use OTC for 32bit glyph collection, but I don't
> know if there's any movement for standardization.
I spoke about OTC (or TTC) because it is backward compatible and would allow
referring to a single font for drawing the legacy subset, while still having
the possibilitily to refer to the other subet using the alternate font name.
But with an extra (very small) table within each fontpacked into the
collection, there would be the possibility to insert explicit font linking
for ranges not covered in the current font in that collection; This small
table could be inserted in each font part of the OTC/TTC pack.
This way, the OTC/TTC fonts remain compatible, but there's a clean way to
cover very large ranges, by splitting them into smaller sets, each one
having the possibility of storing multiple variations (for example Japanese,
or Korean or Traditional Chinese variants, enabled through the existing
language feature).
Font linking, performed this way within the fonts themselves would be much
better than solutions implemented in code only in the system-specific
renderer.
Also, it allows sharing common designs for alternate styles without
duplicating most of the collection (look for example at symbols: most of
them can't be mapped safely to italic, or sometimes even to bold).
Font linking instructions within font files is certainly something that will
ease their installation and use. If this is not done, may be Opentype should
create a new virtual font format that does not contain any glyph, but just a
set of tables containing such font linking for some ranges (so the
64K-limited fonts will remain to be installed separately).
I am horrified about the way font linking currently works in common
renderers, with hardwired code, and no place for extension for new scripts.
This slows down the development and deployment of new scripts, based only on
the way a few scripts are implemented in each OS version. I am convinced
that all those hardwired rules implemented in renderers can be described in
external tables, and so could be stored in font tables. If this is not
possible, because that requires horrible tweaks in the way the Unicode code
point stream must be prepared, then something is missing in the Unicode
standard, namely: character properties.
No renderer should have a prior knowledge about specific fonts for the
system on which it was initially designed, given that even these systems
will need to evolve and support larger subsets sooner or later, and still
need to find some way to work for several years on other supported versions
of these systems. If this is still true, I think this is bogous by design,
due to lack of modelling and abstraction.
And at least, it is very frustrating for font designers that can't sell
their fonts (or need to create multiple masters, and experiment other
problems like describing which font is appropriate for which user, and
having to manage things like multiple licencing for the same font design in
multiple master formats), and for users that can't buy and use them with the
applications of their choice. In other words, this is a severe
interoperability problem, something that industry standards like Unicode and
OpenType are supposed to clean up.
This archive was generated by hypermail 2.1.5 : Mon May 21 2007 - 18:50:34 CDT