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