[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Kword included in font HOWTO
From:       Donovan Rebbechi <elflord () panix ! com>
Date:       2000-03-12 2:55:15
[Download RAW message or body]

On Sun, 12 Mar 2000, David Faure wrote:

> When you say "KWord tries to guess font names", I guess the problem
> effectively lies in Qt ? 

Yes and no. The problem could be fixed in Kword or in QT or somewhere
else. 

The problem boils down to the fact that Linux has no standard way to map
screen fonts to printer fonts. X11 does not print, and does not provide a
way to print. Moreover, it doesn't provide a way that one *could* retrieve
the information that you need to print. In short, Linux's print and
display system are entirely seperate ( the left hand and right hand don't
know what the other is doing ). Qt tries to offer a unified display/print
method by using the same methods to write to a printer and
display. However, at this stage, there's no way to do this with fonts.

To put it concisely, here's a problem: show me some code that displays a
font, and *reliably* prints the same font. Once you solve this problem,
you can do WYSIWYG. Before then, you can't. 

Star Office and Applixware
solve it via config files that negotiate printing/display systems ( they
basically take care of printing internally ). Qt sort of handles it by
trying to guess the names of the print fonts -- 

*and mistakenly assuming that the print system is configured to print
those fonts*. Both the guess and assumption are bad.

The problem is nontrivial because  X11 doesn't allow the developers cannot
retrieve complete font metric information, or the glyphs. It also doesn't
tell the developer how to print the font, or even if the font in question
is actually printable.

There *really* needs to be a ( as in one ) standard way to do
this. Building it into Qt would only mean that the users would seperately
have to negotiate "Qt/KDE  fonts" and "Gnome/GTK fonts". Here's to
fragmentation (-;

IMO, the right way (tm) is to simply provide some database that stores the
following kind of information about a font:

* 	screen name ( as in the XFLD )
*	outline file name 
*	font metric file if applicable
*	family name
*	weight ( bold, demibold, regular, light )
*	slant ( italic, oblique, regular )

Once you document the format of the database ( actually, xml is one
possibility ), you can write APIs to read it and edit it in any language
you choose.

> I am ignorant about all this, but a bit
> surprised by the complexity - can't people just agree on font names ? :-)

There is more than a simple naming problem going on here. The main problem
is that Qt just assumes that you've configured the fonts in your printing
system, when in fact there's no way of knowing if the fonts are even
printable ( nb: bitmap fonts are not considered "printable", not unless
100dpi is good enough  )

Cheers,
-- 
Donovan

[prev in list] [next in list] [prev in thread] [next in thread]