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

List:       kde-bugs-dist
Subject:    [Bug 140546] KOffice does not properly embed TrueType fonts for
From:       Kurt Pfeifle <pfeifle () kde ! org>
Date:       2007-01-31 22:26:04
Message-ID: 20070131222604.11418.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         
pfeifle kde org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Summary|Koffice don't embed fonts   |KOffice does not properly
                   |during printing    Koffice  |embed TrueType fonts for
                   |don't  embed truetype during|printing or PDF creation \
(PS  |the printing                |fonts Type 1 are OK)



------- Additional Comments From pfeifle kde org  2007-01-31 23:26 -------
    'the bug system is [....] about reporting problems and fixing them.'

Fair enough. 

And it's also about *reading*, and reading *properly* what's reported, and \
not giving comments that do not match the reported problems.


    'I told you so in comment 13'

If you did, I fail to see the solution.... 

What I took from comment 13 was this: "'fc-match' does not find the font, \
so how do you expect KWord can find it?" That hint was fair enough at \
first. However, it did not say how to force fontconfig to find the font in \
question, and no manpage nor READM shipping with fontconfig does so either. \
It was not a solution, it merely led to a more precise description of the \
problem.

And what's more (please do now take note, finally!), the problem now turned \
out to be this (as I have tried clarify by different means in previous \
comments, but seem to have failed):

 (1) KWord displays "Bitstream Vera Serif" in its drop-down list of fonts 
     used for the document (attachment 19401)

 (2) KWord does not use the font it pretends to use; *even* *on* *screen*, \
                in
     the document window there is a very obvious difference. [So forget the
     hated "printing", don't even read my points (3) and (4)... The problem \
is  already HERE, in (2)...]

 (3) 'fc-match "Bitstream Vera Serif"' returns a good match in what it \
                says:
     'VeraSe.ttf: "Bitstream Vera Serif" "Roman"' (We asked the wrong \
                question
     when we used 'fc-match "vera serif"' and got "Arial" as a response...)

 (4) KWord's printfile does not use that font either (but why should it, if \
it  can't even use it for working with the .odt document per se?)


    'the problem has been fixed in trunk'

Well, it is not a real 'fix', is it? PDF creation is a completely new \
technology, and will not replace at once what we do now via PostScript. It \
means the problem will persist with PostScript.

I'd love to get my hands on some example documents created with KWord 2.0 \
trunk, or rather, the PDFs created from them with KWord's "native" \
mechanism for that.

Is it possible to open documents created with my KWord 1.6.1 in KWord \
trunk, using the same fonts, and then generate the respective PDFs?

Would you be willing to do that and send the PDFs back to me, if I supply \
you with a few sample KWord documents focussing on font processing?

It'd be great for testing.  I'm not assuming there are any bugs in KWord \
2.0 regarding this, so fear not.   :)

I'm thinking more about the processing of such hi-quality PDFs \
"downstream", with other tools, and testing the outcome of this even now... \
(impositioning, creating color separations, merging PDF files, extracting \
pages,... Can current CUPS filters even process those high-versioned PDFs? \
Do these PDFs print if they are sent "raw" to PDF-capable printers? What do \
MS Windows-based preflight checkers say about them?, etc. pp.)


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