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

List:       kde-bugs-dist
Subject:    [Bug 140546] Koffice don't embed fonts during printing Koffice don't
From:       Kurt Pfeifle <pfeifle () kde ! org>
Date:       2007-01-30 22:52:40
Message-ID: 20070130225240.27070.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=140546         




------- Additional Comments From pfeifle kde org  2007-01-30 23:52 -------

   'Vera sans is not a font name'

Well, call it what you want then; a Chinese veggie dish maybe? Seriously, if \
OOoWriter as well as KWord would display this very same string "Vera Sans" in the \
font dropdown list, then for all it's worth - that *is* a font name, for every user \
you'll ask. (Besides, it was "Bitstream Vera Serif", if you'd finaly be bothered to \
notice...)



   'when I say 'font' here I mean one specific file'

Can you please then design a UI for me into your app, that let's me pick one specific \
file?!? (Now you've indirectly been saying that I, the user, can't be responsible for \
any mess up, because the UI does only display "human readable" and/or "user friendly" \
font names. It tells me "Vera Sans", *not* \
"/usr/X11R6/lib/X11/fonts/truetype/Vera.ttf" or whatever you are suggesting.)

But I'm still not sure you'll agree that here is a problem that users can't solve by \
themselves, and that they need the developers's help with it....



   'Stop using "Sans Serif"...'

You're missing the specific point here again. (I can see the generic point you're \
making, though: "same font" + "all apps" + "same libs"...).

First, I didn't use "Sans Serif", I used "Bitstream Vera Serif" (which is a *real* \
font, and one that most distros ship). Did you even look at the screenshots, man ?!?

Second, this problem is happening on one and the same distro, where two different \
applications (OOoWriter + KWord) can't agree about which font to use in reality, when \
*both* display the *same* font name in the UI drop down menu of the font selector \
(even showing the same "preview" of the font there!). [The comparison with Debian was \
introduced only later, because the problem was not debugg-able for me by staying on \
SUSE only...]

Call it what you want, shift responsibility to the distro or whomever -- it doesn't \
help *now* to solve the problem. But by now I assume you don't know either how to \
solve it...

Let me recapitulate.

 (1) Created an example document with OOoWriter, using only 1 fontsize, 1 
     fontname displayed as "Vera Sans" in the UI.

 (2) Opened the same document in KWord, which displays the same fontsize, same
     fontname "Vera Sans" in the UI.

But obviously, the font found and *used* by KWord as the closest match is Arial. And \
the responsible component is fontconfig, which betrays the user as well as the \
developer of KWord in pointing to Arial when "fc-match 'Vera Sans'" is called. The \
question remains: what makes OOoWriter bypass that crappy fontconfig hint, and what \
makes it pick the correct (=selected in the UI) font?!  
 $> fc-match "Vera Serif" 
 arial.ttf: "Arial" "Regular"

 $> fc-list : file|grep -i vera
 /usr/X11R6/lib/X11/fonts/truetype/VeraSeBd.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraSe.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraBI.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraBd.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/Vera.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraIt.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraMono.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraMoBI.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraMoIt.ttf:
 /usr/X11R6/lib/X11/fonts/truetype/VeraMoBd.ttf:

As you hopefully can see, "fc-list" is able to find a font family named "Vera", and \
finds even the absolute paths to the distinct file names. So there *is* a font named \
"Vera" on this system, and fontconfig knows it. And "kcmshell kcmfontinst" displays \
10 different variations of "user friendly" names  for these very files: 

 1.  Bitstream Vera Sans 
 2.  Bitstream Vera Sans Bold
 3.  Bitstream Vera Sans Bold Oblique
 4.  Bitstream Vera Sans Mono
 5.  Bitstream Vera Sans Mono Oblique
 6.  Bitstream Vera Sans Mono Bold
 7.  Bitstream Vera Sans Mono Bold Oblique
 8.  Bitstream Vera Sans Oblique
 9.  Bitstream Vera Serif 
10.  Bitstream Vera Serif Bold


 $> fc-match "Bitstream Vera Serif"
 VeraSe.ttf: "Bitstream Vera Serif" "Roman"

So fc-match finds the font if given the same full name as KWord does display int he \
dropdown list of the font selector. But KWord still does not *use* it: neither on \
screen/X11, nor on printout/paper, nor on PDF. 

Yeah, a fontconfig bug for sure, and KWord is completely innocent....



   'The first problem is mostly a user and distro problem.'

The user problem is that he is left alone; with the available tools he can't do any \
more debugging, even if he is heavily willing, and if he is way beyond the stage of a \
newbie. KWord doesn't offer any other way than selecting the drop-down list in the UI \
to select a font (and KWord doesn't even offer to do for the KWord user what the \
KWord developer recommends: selecting a font by "one specific file").

My present guess is that this system has a buggy fontconfig version installed, yes, \
yes, yes. 

And your hint to the "fc-match" utility probably was the key to let me come to that \
conclusion. I've now to find an RPM package (or compile from sources) and test again. \


I'll discharge KWord from the accusation causing this specific bug for now, and I \
thank its maintainer for one helpful titbit of a catchword ("fc-match") despite the \
rather careless sloppiness of his remaining comments.   :-)


Thanks also for your rather tight-lipped hint to that "harfbuzz" thingie too. Didn't \
know that (and still don't -- haven't googled it yet).


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