Subject: Re: Rant (Was Re: printing in gnome port)
From: Paul Rohr (paul@abisource.com)
Date: Sun Feb 18 2001 - 21:12:08 CST
At 03:34 PM 2/18/01 -0500, Dom Lachowicz wrote:
>This is changing with the next release of gnome-print AFAIK. We don't
>support TTF printing (Tomas' new addition) because (I'll say this once more)
>we stupidly ship our own fonts. This whole discussion about adding a
>gui/dialog to add TTFs and new fonts would be mute if someone fixed this.
>Someone write a better PS driver so we can:
>
>1) Use whatever fonts are available to us
>2) Not ship our own fonts (and thus increates our robustness and decrese our
>size)
>
>If only I could convince everyone that they were trying to fix the problem
>from the wrong end and that our handling of fonts just plain sucks!
Dom,
Please, please convince us. :-) In your opinion what's the Right Way to
make fonts Just Work? What work needs to be done where?
IIRC, to get WYSIWYG printing, we need to have printer metrics for the fonts
we use, so we can get the on-screen layout calculations right. To
reiterate, we need:
- a font,
- printer metrics for that font,
- some way of persisting the mapping between the two.
On other OSes, you get all that for free, but when the current solution was
coded, raw X didn't do that job for us. Does it now? Does GTK? (To save
Aaron a post, I'll posit that a GNOME-only solution doesn't help.) Who
*should* do that job?
Yes, our initial solution was to ship a bundle with fonts, printer metrics,
and a fonts.dir index which maintained the mappings. (If there's any
additional value add in fonts.dir, I don't remember what it is, so someone
should point it out.) The main virtue of such a lowest-common-denominator
solution is its simplicity. That's also its greatest limitation.
I now get the impression that Tomas is generating the code needed to
dynamically create and use the font metrics we'll need. Thus, so as long as
we have a way to:
- locate fonts, and
- cache the printer metrics for those fonts,
then we should be able to evolve into an increasingly flexible solution.
For example, perhaps we should morph fonts.dir into a cache index for
printer metrics files generated at runtime. The first time a user chooses
any new font for use in AbiWord, we'd autogenerate the relevant metrics and
store them in our cache. That way, all subsequent documents which use that
font would already have the necessary printer metrics available (from the
cache).
Since you don't seem to like the idea of this kind of work being
Abi-specific, please describe where the code *should* go, and how we can
ensure that Unix users on all our supported platforms can use it.
Paul
PS: I'll claim that the following issues are peripheral to the current
discussion:
- whether to ship fonts at all
- which ones to ship
- where and how to install them
There are a lot of valid reasons for word processors to ship fonts -- no
matter what you think of the current reason(s). :-)
This archive was generated by hypermail 2b25 : Sun Feb 18 2001 - 21:04:35 CST