From: Joaquin Cuenca Abela (e98cuenc@yahoo.com)
Date: Thu Oct 03 2002 - 04:35:49 EDT
The proposal is very interesting, and some time ago I
was thinking about something similar, but I have some
comments about the aproach that you suggest to solve
this problem.
I will first try to explain where fontconfig/win32 api
fits in all that. Substituting a font for another one
is a complex process if you want to do it right (I
hope that we're not aiming for an afternoon hack).
First, the "big database" approach doesn't works well.
There're simply too much fonts out there. Of course,
a system that solves this problem can have a little
database with some popular/user defined aliases, but
that's more of an "exception" list than a "generic"
list.
Next, the "match" process is relatively hard to get
right. Not only you need the name of the font, its
panose[2] numbers or [hv]stems, but also its unicode
coverage. Think of an arabic user using an Arial
document, if he doesn't have Arial, the system should
not use Verdana as an alias, because Verdana doesn't
have arabic glyphs.
At the end of the day, you finish with an algorithm
that has to known about unicode coverage, panose
numbers and user preferences. For a detailed
description of such an algorithm you can take a look
at the CSS2 specs.
The good news is that fontconfig almost does that for
us in unix (afair except the panose matching[*]), and
win32 does at the very least the panose matching.
What's our job here? Imo, we should supply these
"metafont" data to fontconfig/win32. We know that
just the name of the font is not enough to get a good
alias, so we also store (in each abiword document)
with the name of the font, its panose numbers[**], and
maybe the need unicode codepoints.
The irony is that it should actually even reduce our
file size. So instead of having a:
<s props="font-family:Times New Roman; ...">
We will have a preamble with:
<font id="1" family="Times New Roman" panose="..."
...>
and later:
<s props="font:1; ...">
The unicode coverage that an aliased font should have
can be calculated at runtime, but maybe it's worth
keeping it cached in the font element.
This scheme leaves doors open to embedding the font
itself inside the font element. I'm not arguing about
font embedding here (let's going to keep discussion
centered in the font mapping mechanism).
I have mildly feelings for the exporter specific
aliases. I guess that they will be useful, but also
the gui for letting the users add an exporter specific
alias may be hard to get right.
[*]: Keith is trying to fully implement the CSS2
algorithm in fontconfig. It was not ready for the
recent release, but it will surely be in further
releases.
[**]: Panose is not the only aliasing algorithm. Some
people think that you can get better results just
storing [hv]stems widths. And Panose doesn't work for
MM fonts. Last time I checked, there was a Panose2
proposal to handle variable fonts as MM.
Cheers,
=====
Joaquin Cuenca Abela
e98cuenc@yahoo.com
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
This archive was generated by hypermail 2.1.4 : Thu Oct 03 2002 - 04:41:24 EDT