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

List:       kde-usability
Subject:    Re: Fonts problems
From:       Craig Drummond <Craig.Drummond () gmx ! net>
Date:       2004-03-31 8:55:25
Message-ID: 200403310955.25423.Craig.Drummond () gmx ! net
[Download RAW message or body]

On Wednesday 31 March 2004 01:00, James Richard Tyrer wrote:
> I believe that one of the major usability issues in KDE is the font system
> (or lack of it).

Well its not really KDE specific...

> 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.

"Arial Black" will be the "family name" - just as "Times New Roman" is a 
family name, and not "Times New". So nothings going wrong here.

> 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

Yeah this is because I try to create a "family" name from the font's fullname. 
i.e. the fonts full name would be something like "Helvetica Narrow 
Italic" (for instance) - and "family" name of "Helvetica". Its weight in the 
font is listed as "normal" - so in order to distinguish this from 
"Helvetica", I modify the full name. The reason for this was someone sent a 
bug report for a font called something like "English Bold Old Style" - and 
the only way to get the "Old Style" part was from the "full name" - as the 
family name as just "English"

>
> 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 if the font says its width is "normal" then the xlfd's are correct - it's 
the font thats wrong. Please send me (off list) the font and I'll look into 
this in more detail.

>
> 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 think this is due to Qt only using Xft to find the fonts - previously it 
would use both regular X (which uses the fonts.dir files), and Xft.

> 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

Because if you don't embed the fonts, then Qt doesn't read them => it can't 
know the PS name. This is also faster, as it doesn't have to read the font 
each time you print. The font installer should help with this by creating 
Fontmap files to get around this problem.

> 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.

This still wouldn't work. When printing GS is run as a different user, 
therefore it wouldn't know which $HOME to look into.  You've already created 
a bug report about this - http://bugs.kde.org/show_bug.cgi?id=59367 - to 
which I've previously added a patch for the foomatic-rip which solves this 
problem for locally attached CUPS printers. And as stated in the bug report, 
this could probably also be modified for other print systems.

(foomatic-rip is used by most linuxprinting.org generated PPDs use to talk to 
GS).

Craig.
_______________________________________________
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]