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

List:       koffice
Subject:    [Bug 140546] KOffice does not properly embed TrueType fonts for
From:       Kurt Pfeifle <pfeifle () kde ! org>
Date:       2007-01-31 22:26:03
Message-ID: 20070131222603.11409.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
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.) ____________________________________
koffice mailing list
koffice@kde.org
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice


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