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 [EMAIL PROTECTED] __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
