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

List:       kde-usability
Subject:    Fonts problems
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2004-03-31 0:00:28
Message-ID: 406A0A1C.9020708 () acm ! org
[Download RAW message or body]

I believe that one of the major usability issues in KDE is the font system
(or lack of it).

I realize that much of this is a Qt issue, but if the Trolls don't fix it,
then we should help them.

The most basic problem is that font names need to be correct.  As an
engineer, I do not understand why this doesn't work.  It is basically just
a string parsing problem.  Cant' Lex/YACC/Bison do this?

The first example is the KDE Font Selector dialog.  The basic question here
is what is a Font Name and what is a Font Style.  Compare various faces of
Arial and Helvetica.  Weight should always be a Style but on my system,
"Arial Black" is a Name.  Width should always be a Name, but on my system,
"Helvetica Narrow was (IIRC) a Style till it went missing in the current
version.

I find that this runs deeper than just Qt.  The XLFDs are not correct
either.  For Helvetica Narrow, I get this from X's: "mkfontscale":

-adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1

and from KDE Font installer:

-adobe-Helvetica Narrow-Medium-r-Normal--0-0-0-0-p-0-iso8859-1

These are both wrong according to the standard (and there are errors in the
standard).  I thought that the XLFDs were supposed to be all lower case,
but apparently that doesn't matter.  I think that this is correct:

-adobe-helvetica-medium-r-narrow--0-0-0-0-p-0-iso8859-1

But does this matter -- does Qt use the XLFDs in: "fonts.dir"?

Fixing this by hand does not cure the problem with KDE.  I have Helvetica
Condensed and Helvetica Narrow and KDE doesn't seem to find either of them.

I am also puzzled by the issue of the: WEIGHT_NAME.  Most configuration and
installation programs make substitutions, but the XLFD standard says that
this isn't the case.  Being a purist, and because it was generating errors,
I modified the: "mkfontscale" program from XFree86 to return the actual
weight string from the font.  It appears to me that doing it any other way
leads to needles confusion.

Even if Qt could get the font names straight -- and it can't.  Example: I
have a problem where: BitstreamVeraSans is substituted for: Swiss721.  Very
odd.  Also note regarding Swiss721 that the version distributed with
WordPerfect has a PS font name: Swis721 but I found another version that
uses: Swiss721.  Even more odd.

Any who: The Qt PostScript driver does not use the correct PostScript font
names unless you embed the fonts.  The logic of this is impressive. :-)  If
you embed the fonts, it doesn't really matter what you call them, but if
you don't embed them, you need the exact correct PostScript font name.  I
reported this bug to the Trolls several versions of Qt ago.  I have made a
patch that appears to fix this:

http://home.earthlink.net/~tyrerj/files/qt-x11-free-3.3.1-PSfontname.patch.tar.bz2

Note: this is a hack, but it does work.

Yes, I also sent them a copy of the patch (3.2.somthin')

IMHO, there are also several other things that need to be changed. 
Specifically (two related issues) the PS driver code 
(src/kernel/qpsprinter.cpp) has font names in it.  This should not be 
necessary.  It also adds a list of substitute fonts to the PS file.  IMO, 
it shouldn't do this.  I realize that this stuff may be necessary for 
systems that don't have FontConfig, Xft[2], & FreeType2.  Perhaps they need 
two versions of the PostScript driver code -- add a new one for systems 
that do have those three libraries.

This problem is made even worse by the fact that the Qt PostScript driver
doesn't do a good job of embedding TrueType fonts. :-(  Type 42 font 
conversion has not been implemented yet.

If you don't embed the fonts, you will have other problems.  This issue is 
a system issue with the print filter and print server (if you have a 
network).  I also believe that there ia a bug in Bash, but that is not the 
problem if you use CUPS (it only applies to LPRng).  With CUPS, either the 
print filter or GhostScript needs to be modified to find the fonts.  You 
can build the font paths into GhostScript but that doesn't solve all of the 
problems.  That won't find fonts installed in your $HOME directory and it 
might not work on a network.  The solution is a GhostScript that uses 
FontConfig to find the font directories.

Then there is the font spacing:

Qt does it's own spacing for proportional spaced fonts.  This appears to be 
slightly larger than the spacing listed in the font.  Then the PostScript 
driver pads the font spacing when it prints.  This is not the proper way to 
do WYSIWYG for some applications (word processing & desktop publishing).

This problem probably also goes deep since Qt appears to be using Xft[2] 
and Freetype2 so it is probably the hinting (for the screen display 
resolution) that is causing the problem.

FreeType2 does whole pixel spacing of glyphs.  But when you print, you need
to use the DPI of the printer.  This gets complicated since the glyphs need
to be rendered at the printer's DPI and then displayed on the screen at a
reduced DPI.  This is the way that WordPerfect works and sometimes the
screen display doesn't look that good (but it prints "perfectly"). 
Anti-aliasing should work for fractional pixel spacing and improve things 
considerably.

So, the glyph rendering model needs to have TWO DPIs: the rendering DPI and
the display DPI.  This means that when you change the resolution of the
printer that the glyph spacing will change slightly in a document (if it is
being formated for printing that is).

This assumes that FreeType2 and the PostScript RIP (GhostScript) will both
render the fonts the same at a given DPI (the printer's DPI).  I don't know 
if this is a possible problem but IIUC you can specify the line length in a 
PostScript file so there is a fudge factor (this is what is being used now 
to produce the larger spacing).  The ultimate solution is something like 
Keith Packard is working on, but that will not be Qt.  It would be nice to 
see GhostScript that was based on FreeType2/XFT/FontConfig, but that is 
another issue.

I think that we need to have Trolltec's help to solve these problems.  They 
don't seem to be fixing this so we probably need to help them as well.

Perhaps KDE needs to write it's own PostScript driver.  An advantage of 
this would be that we could use the Sun code in OpenOffice.  Scribus 
already has a PostScript driver.  Perhaps we could use that.

--
JRT
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]