From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Thu Oct 03 2002 - 02:18:42 EDT
--- Dom Lachowicz <doml@appligent.com> wrote:
> Hi,
>
> So my latest build doc brought up some confusion on
> IRC about what the "Luxi Sans" font was, and is an
> example of a much larger problem - we have no good
> font name mapping solution in place, so necessarily
> some font information gets lost when a document
moves
> from one machine to another (and especially across
> platforms), and is parallel to the font embedding
> problem that Joaquin and I were discussing last
> month.
>
> What I am proposing here comes in several parts:
>
> 1) We create a user-editable XML based file
> containing font name information, aliases, platform
> names, alternates, et. al.
>
> 2) Create a singleton "mapper" class whose job is:
> a) to return the proper GR_Font (or font name) for a
> given input font name and graphics class
> b) to return a font name and alternates list based
> on and input name and possibly some auxiliary data,
> such as output format (RTF and HTML come to mind)
>
> 3) Use information gathered in 2.b when saving to
> virtually every format, where appropriate
>
> The DTD would look something like
> <!ELEMENT font>
> <!ATTLIST font
> id %String; #REQUIRED
> aliases %StringList; #IMPLIED
> alternates %StringList; #IMPLIED
> >
>
> A use of said DTD might look like:
>
> <font id="Times New Roman" aliases="Nimbus Roman 9L,
> Nimbus Roman" alternates="Times, Georgia"/>
>
> and would correspond in the ABW and HTML formats to
> something like:
> style="font-family:Times New Roman,Times,Georgia"
>
> where alternates is a list of IDREFS to other <font>
> entries and the font-family entry looks like:
> id,alternates. Aliases need not be IDREFS, since
> they would essentially be alternate (platform
> specific) names for the id attribute.
>
> If needed, we could expand this list to also have
> additional information. Poor nonsensical example
> follows:
>
> <font id="Times New Roman" aliases="Nimbus Roman 9L,
> Nimbus Roman" alternates="Times, Georgia"
> file-format="rtf:Comic Sans MS; latex:Rubbish"/>
>
> which means "when saving to RTF, use 'Comic Sans MS'
> as the font's name and 'Rubbish' when saving to
> LaTeX". These would also necessarily be IDREFS to
> other listed fonts, thus making re-loading the RTF
> transparent to our users and to our formatting
> engine.
>
> If a font installed on a user's system isn't present
> in our list, we will still display the document
> using that font on the user's computer, and save
> that name in the ABW file. However, when loading on
> a 3rd party machine, we would use a default like
> Times Roman for viewing purposes instead. In this
> case, the result is no worse than our present
> behavior, and arguably could not get much better.
>
> Again, this is just an idea, and probably a poor one
> at that. I'm admittedly out of my league here. I'm
> looking for constructive feedback suggestions from
> other people on the list, not criticism and
> flameage. Other information, links, feedback
> appreciated.
>
> Thanks,
> Dom
> /me already forsees Andrew wanting to add locale
> information to the above DTD
Of course! (: Only problem is I don't know what.
Just using our existing locale tags isn't going to
be flexible enough for .abw for long.
We definitely need something like this though -
aspects
of it have been discussed before. We probably need to
introduce the concept of a "FontSet" which is what the
aliases and alternatives are. Though in the i18n
sense it's a little different. With one language it
means "use this font but if it doesn't exist, use this
other font". With 2 languages with different scripts
it means "use this font for latin script languages,
and
use this other font for cyrillic script languages".
But of course they're going to interact and it's going
to get very hairy.
In the Unix worls we will have to be careful. Xft has
already the concept of font sets so I'm sure we want
to be able to hook into that. Otherwise we could have
the document aliases and alternatives being different
to the rendering system aliases and alternatives.
But of course Xft is Unix-specific. Windows doesn't
seem to have such a concept though with i18n fonts,
Uniscribe does actually do some similar tricks. I
have no idea what OS X does. Panose information in
fonts may also play a part?
We have to be careful of overspecifying and making too
confusing a system. Or one that users think they're
going to have to tweak to solve some other problem
and we could end up having to service all kinds of
weird bug reports that wouldn't have existed
otherwise.
Or maybe not - I really don't know (:
What we definitely have to do is start maintaining a
list of all the related problems that this stuff is
going to solve. We need something that's going to be
workable at solving the target problems, coexist with
the other systems which provide related functions
(Xft), and work across all platforms.
But as discussed earlier, MS Word's Tools/Options/
Compatibility/Font Substitution does the XP font
mapping problem pretty well. At least in the
direction
of "whatever platform" -> Windows. I don't think it
solves all the problems but it mostly "just works" to
the degree that few users probably even know it's
there.
Andrew.
=====
http://linguaphile.sourceforge.net/cgi-bin/translator.pl http://www.abisource.com
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
This archive was generated by hypermail 2.1.4 : Thu Oct 03 2002 - 02:24:19 EDT