We may reserve about two hours for some talk about fonts and I can accompany
it with some notes. My problem is I don't know how much is common knowledge.
We are all assumed to be printer experts somehow. So maybe everyone knows as
much or even more than I do. But nonetheless I will be prepared for some
items. So we can use this as a kind of an agenda to follow on.
At the beginning of our font discussion I'd like a public and binding
decision that every glyph will always and everywhere be identified as a
Unicode in our spec.
After that we may talk about resident fonts:
1. Common font description files for the host
PFM, AFM, TFM
2. General font attributes
I hope others will jump in here. We will talk about font description
structures for drivers in different operating systems. I propose a
description close to the IFIMETRICS we know from NT. Please send me and
bring with you appropriate stuff for the Mac and Unix/Linux.
3. Character width tables
One long list of pairs of Unicode and width values. I'd like to see values
for bitmap fonts rather based on virtual units (7200 will work in many
cases, but this could be set somewhere more in a global section of our spec)
than on real resolution. I do not want to have two lists for one font in 300
and 600 dpi, not to talk about 1200. This will make the font description a
bit more model independent and reusable. I hope to encourage font vendors by
that to develop a tool for automatic creation of UPDF font description files
for easy implementation into a UPDF file. That is exactly the kind of
arguments companies like Bitstream are looking for.
An interesting item may be to describe the width of some fonts used in
Japan, which are mainly fixed pitch. Few glyphs are half width and few
others, mainly the Latin section, are proportional. The danger is to create
huge data files without really providing much information. Do we want it
simple and large or small and effective, but with more work on the driver
side?
4. Dynamic character selection
Similar problem as above. Do we want fonts to be determined to one special
character set used in the operating system? This may result in quite a large
number of font descriptions just to support a typeface like Arial under
different operating systems and different language versions (International,
East European, Cyrillic, Japanese, etc.).
We have to think about character set definitions and their effective use.
And I want us to specify some common character sets in the DTD. Who can we
use as a reference? The Unicode consortium? IEEE?
A subitem here is when the font should be announced at all. Assuming a font
description including Western and Eastern European characters would we
expect to see the font showing up as Western AND Eastern, when the Eastern
European option is not installed? That might be a nice battle. I have fought
a lot already to make fonts 'dynamic'.
5. Font rotation
Sometimes only some characters can be rotated. See Japanese market.
Sometimes fonts can only rotated in 90 degree steps.
The unit to describe angles in could be 3600.
6. Character composition table
Maybe there is better name for it. But you want to be able to substitute
some characters with accents by combining the basic character and the accent
as another char.
I want us to specify a common composition table in the DTD, which can be
used as a base.
7. Kerning
8. Scaling formulas
I do not want to translate C code into XML to specify the way the width of
characters in a scalable Intellifont or other font format is done.
So we need to decide which font formats and therefore scaling formulas we
support. This can include an anticipation of how the driver is expected to
calculate. I would not mind to show five lines of C code per scaling formula
in the general explanation of the spec.
9. System fonts used to screen resident fonts
To be honest: This is an area, where I get angry quickly. So keep me calm.
Typical questions: How should the font be named? If there are four styles of
a typeface will the font name of these four fonts have a suffix like 'Bold',
'Italic', 'BoldItalic' or so? We don't need to decide that and can leave it
open. But I like to have a policy in cases like this, which then can build
up some culture to avoid problems early.
Do we say anything how characters should be handled, which may not be
supported by standard system fonts? When system fonts will be shipped with
the device can we assume they are installed?
10. Command sequences
Generally I propose to select fonts by attribute and not by location.
To describe the download of system fonts not represented by resident fonts
is somehow different, but we could reuse some sections.
Character sets and rotation are an issue here, too.
Proposal: We concentrate on temporary download, not permanent. Otherwise we
have to handle hard disk, Flash ROM and so on. I do not think we are on
level to handle that already. Temporary will make it difficult enough.
I do not want to describe each download method in detail, but create a
reference list with exact target models, e.g. 'PCL 5 bitmap' references the
PCL bitmap download understood by a HP LaserJet III.
We may need to specify some values like 'maximum number of download fonts',
'download per page / per document', etc.
Even with constraints (you remember I suggested not to use constraints for
UI only) it might be impossible to describe something like 'do not use more
than 30% of RAM for download, if less than 2MB are available'. So memory
handling might be up to the driver.
So the download section might be quite short.
As I said I know this and that. This overview may give you enough reason to
throw tomatoes and eggs.
I know I left font substitution out.
I think we will face huge data accumulation and compression automatically.
Anything else I forgot?
Norbert