Version: (using KDE KDE 3.5.5) Installed from: Mandriva RPMs OS: Linux Mandriva bug: http://qa.mandriva.com/show_bug.cgi?id=8313 Koffice don't embed truetype fonts during the printing. Ex. open Kword, type some text with the "Vera Serif" font. Print your text in a pdf file. In a console type this command (you will need xpdf): pdffonts your_pdf_file.pdf and you will obtain something like that: name type emb sub uni object ID ------------------------------------ ------------ --- --- --- --------- [none] Type 3 no no no 9 0 Koffice transform the truetype font in a Type 3 font. Application like Acrobat Reader and Kpdf doesn't like Type 3 fonts.
That means the font you selected is a bitmapped font. Which is embedded just fine, it just prints really bad. (like you noted).
Sorry, Thomas, a bit less in-accurateness looking at bugzilla reports would do a bit more good in the area of user:developer relations.... :-) Here's why: * Vera Serif is *not* "a bitmapped font"! * And it neither is "embedded just fine"! Qt (and hence, all Qt-based apps that rely on Qt for printing) sucks donkeyballs when it comes to font processing. (That's why Scribus does its own stuff when it comes to PostScript and PDF creation, and therefore they don't suck, despite relying on Qt too....). KOffice, of course, delegates all responsibility for this field over to Qt (and its sucking "PostScript Level 1 only" feature), and hence suffers from the same weaknesses when it comes to PDF generation or to printing. (I know KOffice developers do hope this gets solved one day in the future, but I dare to be a bit pessimistic about this, given for instance ) So, Vera Serif indeed is a TrueType font. In this case, it isn't embedded *at all* (see user's report). Why not, I don't know (but see below, how it *may* be fixed by an assortment of different user settings). In other cases, a Type3 fonts *may* get embedded by Qt/KDE-apps (this problem concerns f.e. Konqueror too, not just KOffice), when they create a printjob, but the embedding may be very "un-fine" (if you allow me to invent a new word). It will take place without a proper name assigned to it (or, internally, the naming may be done in a way that isn't accessible for outside applications that want to use it). You will read "[none]" in the resulting "KPDF --> properties" dialog, or get the same result reported by the "pdffonts" command {see the "[none]" here too}. But such a situation that will mean f.e. that the PDF is... ...not searchable, ...text extraction will not work, ...screen reading with KTTS will fail, etc. pp. Oh, and a PDF file may print even *excellently*, despite containing made-bitmapped fonts! So, Thomas, you are wrong on so many items here, in that single, little 1-liner you wrote above! And my hope for getting magic fixes for our printing deficiencies from Trolltech by ways of new Qt versions has diminished over time. See f.e. this comment in bugzilla (I came across it recently by reading a Dot comment): http://bugs.kde.org/show_bug.cgi?id=54410#c2 It is nearly 4 years old, and a KDE developer says about another one of our major real life printing problems (we can't handle custom size media): "This is a Qt or in the end a KDE issue. Qt and therefore KDEPrint doesn't use the user defined settings yet. Trolls say, this is intended to be implemented in QT 3.2, so we need to wait until it is also implemented in KDE 3.2." Now go to the Trolltech bug tracking system, here: http://www.trolltech.com/developer/task-tracker/index_html?method=entry&id=99441 So it looks it was carried along their old bug tracker version throughout the 3.x Qt series. It has now entered their new bug tracker too. There, they had at first as the Qt version to fix this set to "4.1.0". Then it became "4.2.0". Currently it is "4.3.0". Fixing Qt's major printing weaknesses is just no priority for them. Do you have any indications or smoke signals that that will change with Qt 4.4.0? -------------- Thatall being said,... ...now to you and your problem, Nicolas: You *may* be lucky, and get a better results in a few lucky cases if you follow these steps to configure your system (it will work less likely if you have an older version of Ghostscript, instead of a recent one): * Run "qtconfig": ----------------- --> on the Printer tab: + check if you've enabled font embedding --> on the Fonts tab: + check which font substitutions there are enabled [*] * Run "kaddprinterwizard --kdeconfig": -------------------------------------- --> on the Fonts screen: + check if you've enabled font embedding + insert all directories where on your system fonts are found (no need to include X server font paths -- these are searched by default) * Print to PDF file again, but this time pay attention to the settings: ----------------------------------------------------------------------- --> click "Properties", go to the "Driver Settings" tab --> Use for "Target Device" the "Printer" (not "Default" or "Screen") --> Use for "Compatibility Level" the "1.4" --> For "Embed all fonts", select "Enabled" --> For "Embed font subsets", choose "Embed complete font" --> For "Maxium subset percentage" use "1" (not "0", not "100") --> For "Bitmap font resolution" set it to the same as your printer is capable of. --> Save Your Settings! Save Your Settings! Save Your Settings! I hope this helps. Let me know. Cheers, Kurt ---------------- [*] Oh, and BTW: don't you *dare* to think there are no font substitutions enabled if you just look at the tab and only see a big white field there. Not so! It's not as intuitive as you may think: You have to go through all the font entries available on the upper drop down "Select or Enter a Family" (hint: use the mouse wheel for quick scrolling through the list!). You'll notice that "Arial" is substituted by "helvetica"; that's OK (and default on most Linux systems). But you shouldn't have many more (unless you are a font expert).
Created attachment 19401 [details] my-comment.odt The .odt file created with OOoWriter from above comment.
Created attachment 19402 [details] my-comment.oowriter-pdfexport.pdf PDF exported directly from OOoWriter
Created attachment 19403 [details] my-comment.KDEPrint-to-file.pdf PDF created with KDEPrint's "Print to File" utility, after opening the same .odt document
Created attachment 19404 [details] OOo-showing-font-settings-as-VeraSerif11pt.png Font supposedly used the same by both applications (OOoWriter and KWord)
Created attachment 19405 [details] KWord-showing-font-settings-as-VeraSerif11pt.png Font supposedly used the same by both applications (OOoWriter and KWord)
Created attachment 19406 [details] OOo-2nd-page-bottom-(So-much-for-WYSIWIG-Fidelity).png -> Font display *on screen* (even inside the 2 applications!!!) is different; There are different line and page breaks in both ODT apps for same-font/same-document (!!!); OOoWriter renders the document much prettier on screen than KWord:
Created attachment 19407 [details] KWord-2nd-page-bottom-3rd-page-top-(So-much-for-WYSIWIG-Fidelity).png -> Font display *on screen* (even inside the 2 applications!!!) is different; There are different line and page breaks in both ODT apps for same-font/same-document (!!!); OOoWriter renders the document much prettier on screen than KWord:
Created attachment 19408 [details] KPDF-searching-text-in-OOo-generated-PDF-with-embedded-font.png Fonts embedded for printing are different; OOo's PDF is searchable, KWord's not.
Created attachment 19409 [details] KPDF-searching-text-in-KWord+KDEPrint-PrintToFile-generated-PDF-with-embedded-font.png Fonts embedded for printing are different; OOo's PDF is searchable, KWord's not.
OK, so just for the non-fun of it, I took the text of my bug comment above, and pasted it into an OOoWriter document, selected 11 pt Vera Sans, saved it as .odt and exported it to PDF. Files will be attached above: * "original" file: my-comment.odt * PDF exported directly from OOoWriter: my-comment.oowriter-pdfexport.pdf Then I opened the .odt file in KWord 1.6.1, and verified it used the same... -> ...same Font type Vera Sans, -> ...same Font size 11 pt, -> ...same page size A4, -> ...same margins 15 mm on each border At least *these* 4 tests it did fine! (Often didn't do so in the past). Then I used KDEPrint's "Print to File (PDF)" printer to create another PDF: * PDF created with KDEPrint's "Print to File": my-comment.KDEPrint-to-file.pdf But now have a close look, please: -> Font supposedly used the same by both applications: [Screenshot "OOo-showing-font-settings-as-VeraSerif11pt.png" ()] [Screenshot "KWord-showing-font-settings-as-VeraSerif11pt.png" ()] -> Font display *on screen* (even inside the 2 applications!!!) is different; There are different line and page breaks in both ODT apps for same-font/same-document (!!!); OOoWriter renders the document much prettier on screen than KWord: [Screenshot "OOo-2nd-page-bottom-(So-much-for-WYSIWIG-Fidelity).png" ()] [Screenshot "KWord-2nd-page-bottom-3rd-page-top-(So-much-for-WYSIWIG-Fidelity).png" ()] -> Fonts embedded for printing are different; OOo's PDF is searchable, KWord's not: [Screenshot "KPDF-searching-text-in-OOo-generated-PDF-with-embedded-font.png" ()] [Screenshot "KPDF-searching-text-in-KWord+KDEPrint-PrintToFile-generated-PDF-with-embedded-font.png" ()] -> OOo-PDF has click-able hyperlinks inside, KPDF hasn't. It'd be great if you helped me understand and track down all these font problems *exactly*. (I don't expect a solution next week or next month, or even this year). It's just that I'm puzzled by all these knitty-critty little-detail problems that do pop up as soon as you have to deal with customers who are used to see fidelity in their documents, when they use the same fonts. The case here is simple: only 1 font (Vera Serif), only one size (11 pt), only one standard document format (ODT) -- but still 2 different applications show the different font rendering *even* *on* *screen* (not to speak of the printing that occurs later in the chain)! Why does this happen, exactly? What's the cause? How could this be solved, theoretically? Is there anybody around who is interested to do it practically too? What is the effort + timeframe for that then? Is that all really dependent on Qt's buggy PostScript export? Can't KOffice cooperate with Scribus, and use their stuff? No doubt, it's great to see all those nice, advanced, revolutionary, creative things coming from the current KOffice development hotbed + playground! But will the "normal", "simple" things also start to work, when these Big Things see finally their release day?? ------------- (You can also keep the original .odt document for later reference.)
Kurt, I would appreciate it if you didn't use the bugreporting system to give very generic bugreports and ask 10 questions of related, but different nature. As you know, the KOffice 1.x printing solution prints to Postcript and lets Ghostscript convert to PDF. If you type; fc-match "Vera Sans" you will see what fontfile is used for this font. Maybe you are right, it is a ttf. But then either Qt3 or Ghostscript does not see that font or include it. Which unfortunately for you, can't be fixed in KOffice. The real solution to this problem is already in svn to be released in KOffice2. And PDFs created there properly include fonts. I'm pretty sure I already told you that on IRC some time ago. Its a shame you apparently did not believe me.
Wow, lot of text with a lot of different topics in it :) I guess the most interesting part (at least for me) is this use-case; [quote] The case here is simple: only 1 font (Vera Serif), only one size (11 pt), only one standard document format (ODT) -- but still 2 different applications show the different font rendering *even* *on* *screen* [/quote] * Why does this happen, exactly? Looking at the screenshots it seems the exact same line of text has different lengths at OOo/KWord. Hmmm... * How could this be solved, theoretically? Figure out why the above is the case + fix it :) At least it would be a first step. * Is there anybody around who is interested to do it practically too? I guess devels are concentrated on the work done in trunk right now. And trunk is not ready yet to be compared to 1.6 (e.g. OpenDoc-code is in place but not enabled yet). * What is the effort + timeframe for that then? That depends on what needs to be done and how it could be done. But I would expect a lot of days if not weeks... * Is that all really dependent on Qt's buggy PostScript export? Well, as we are able to see at the screenshots, there seems to be a difference at the length of the textlines already. btw, did you define the same pagemargin/etc. settings for both of them? * Can't KOffice cooperate with Scribus, and use their stuff? 1) someone needs to look at there code and compare it with our to get an impression of the time needed, 2) someone needs to implement it if possible/useful or fix "it", 3) we need to define who someone is :) Sounds for me like a lot of work... and sounds for me like it should be done on trunk by "someone" cause the whole textengine did switch between 1.6 and 2.0
@ comment 13 (Thomas): Thomas, I didn't "give a generic bug report". I commented on one, and discussed it. And I created an interesting reference document as well (I think). And I did so because that problem is a recurrent one in KDE (not just KOffice, and I said so). Yes, it may have touched 10 related topics -- so what? They are "related", and to a bit part unsolved. And to a big part also not fully understood by me (that's why I ask questions too). I'm trying to *help*, and trying to learn as well. Thanks for hinting to the "fc-match" command; I didn't know that. I'm aware that this won't be fixed in KOffice 1.6.x, and I'm not asking for doing it. What I'm asking for is help me fully understand the issues, so... ...so they can be explained to users, ...so that there may be found workarounds, ...so that we could start recommending certain setups (font sets, etc.) ...or finally be transformed into a fully HOWTO/tutorial. Is that asking for too much!? The impression that was created by the first answer was "Leave me alone, I'm not even looking closely at your problem, and I'm not interested in it." As you may know, I'm currently focussing on *all* printing + font related bugzilla entries, trying to find duplicates+invalids+fixed ones. But I don't want to just close as many as possible with for the sake of statistics, I want to gain something valuable from these investigations. As for the "interesting reference document" I mentioned above: in the end it may turn out that the interesting part of it only reveals that somehow *my* font setup s and my font-config installations are b0rken. If so, it was worth while, should it help me understand what I need to change. Because I may possibly apply that knowledge to help half a dozen or so other users in the next 5 years.... No need to tell me "as you know....$foobar", when I myself outlined the same $foobar things in my advice to the user. As you may be aware (bug 140006), I'm trying to create somewhere, somehow, a repository of test cases, reference documents, HowTos, articles and automated/scripted tests that deal with these problems (fonts, printing & PDF generation) for KDEPrint and KDE in general. And I'll take the liberty to use (in part) bugzilla comments a for getting started... ---------------------------- @ comment 14 (Sebastian): * How could this be solved, theoretically? Figure out why the above is the case + fix it :) [...] Hehe... invalid answer. Because I don't allow you to answer the second question by repeating my first one, when the first one seems to be unresolved for all of us :-) "it seems the exact same line of text has different lengths" Yes, and what's more: it seems to use an entirely different font altogether (not just different font metrics); you can see that when looking at some of the glyphs. Thomas' hint about "fc-match" may help me figure it out, finally. Thanks for that, again! What does puzzle me is that KWord still displays "Vera Sans" when indeed it seems to use a different font internally. First, that shouldn't happen IMHO. It should (in the future KWord 2.0) at least say something like "Vera Sans (emulated by FooBar)" if indeed FooBar is the underlying font, no? Second, how can I make KWord running on the same system that OOoWriter runs on use the same font that OOoWriter used to create that document?? "did you define the same pagemargin/etc. settings for both of them?" Yes. If you look again at my comment, you'll see that I created the .odt in OOoWriter, then opened in KWord, and first thing verified if the same page and margin settings were used here, and they were (because that was a previous issue I had with this kind of "conversion"). Also, the .odt is here (attachment 19401 [details]) to play with. Download it (if you've time and are interested), and open it on your own system in OOoWriter and in KWord and see if you experience the same discrepancy or not. If not, that would already narrow down the problem to one of my local setup (and the local setups of the many users who see the same thing), and it would be a first step to come up with a guide that helps avoid these issues. "[Scribus...] someone needs to look at there code" Well, maybe a 10 minute chat on IRC, from developer to developer, would already give a good overview (I myself have no idea about it, I'm just posing the question....).
> it seems to use an entirely different font altogether That remembers me, that I was reading a while back that the OOo Novell-Edition (which got also shipped by e.g. debian afaik) does include some from AGFA licensed fonts. Hmmmm... > What does puzzle me is that KWord still displays "Vera Sans" when indeed it seems to use a different font internally. Bad news are, that Abiword does it like OOoWriter. So, it seems to be a KWord issue. While the good?! news are, that I am still not sure if it's really a "font-issue" since in the document at the "In other cases, a Type3" paragraph the lines are identical till the "resulting "KPDF --> properties" line.
OK, I'm now sitting again in front of the PC in question (but have only a few minutes); it is a SUSE 10.0 with KDE 3.5.5 and many updates from their repositories: $> fc-match "Vera Sans" arial.ttf: "Arial" "Regular" On a different system (Sidux/current/unreleased) which is basically a Debian Sid (unstable), I get this: $> fc-match "Vera Sans" Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" OOo on Sid is 2.0.4.dfsg.2-3, on SUSE-10.0 it is 2.0.0.99.143-0.1. I'll need to test my .odt file on that Debian system as well, later.... One thing I see and find remarkable: OOo ships (on both systems) with a directory full of .afm files called "psprint/fontmetric/" (.afm files are metrics for PostScript fonts -- will not be relevant to TT fonts, but anyway...) So one step further I am here now, thanks to you two: it *likely* is a local setup problem: - fc-match shows different matches on SUSE and on Debian. - Debian matches exactly, and SUSE "matches" Arial for Vera Sans, - KWord on SUSE the same Vera document doesnt look like the OOo/SUSE. - Debian's actual behavior with the document I need to verify still. Cheers+thanks, Kurt
On Thursday 25 January 2007 10:30, Sebastian Sauer wrote: > [quote] > The case here is simple: only 1 font (Vera Serif), only one size (11 pt), > only one standard document format (ODT) -- but still 2 different > applications show the different font rendering *even* *on* *screen* > [/quote] > > * Why does this happen, exactly? Vera sans is not a font name. There is no 1-to-1 mapping of that name to a font. So expect different apps to pick different fonts for this. And when I say 'font' here I mean one specific file; so not just "Helvetica" but one specific implementation of that. > * How could this be solved, theoretically? By all apps using the same font and all apps using the same library that parses the font file and calculates where the glyphs are positioned. The first problem is mostly a user and distro problem. Stop using "Sans Serif" and similar fonts, but use a real font that all distros ship. The second problem is being solved by openDesktop using harfbuzz. Google if you want to figure out what that does.
'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).
I fucked up that part: # 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. Of course, it should read (and the screenshots proof it): ############################################################################## # # # Let me recapitulate. # # # # (1) Created an example document with OOoWriter, using only 1 fontsize, 1 # # fontname displayed as "Bitstream Vera Serif" in the UI. # # # # (2) Opened the same document in KWord, which displays the same fontsize, # # same fontname "Bitstream Vera Serif" in the UI. # # # ##############################################################################
> 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... I do, and I told you so in comment 13. Even better, the problem has been fixed in trunk. > Thanks also for your rather tight-lipped hint You are welcome. Do note that the bug system is not a 'lets explain the technical problems' forum. Its about reporting problems and fixing them. This problem is known, and has been known for years already and the solution is Qt4. See #47657 for example. I'd close this bug were it not for the fact that the release is still to far away and there are stable-branch releases scheduled in the mean time.
'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 [details]) (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.)
Created attachment 19533 [details] 140546_1.pdf (made from a KWord document KWord file uses only 1 font face, a TrueType font. It is 'Bitstream Vera Serif' at different font sizes, colors and variants of bold, regular and italic.
Created attachment 19534 [details] 140546_2.pdf (made from a KWord document) KWord file uses only 1 font face, a TrueType font. It is 'Bitstream Vera Serif' at different font sizes, colors and variants of bold, regular and italic.
Created attachment 19535 [details] 140546_1.pdf (made from a KWord document) KWord file uses only 1 font face, a TrueType font. It is 'Bitstream Vera Serif' at different font sizes, colors and variants of bold, regular and italic.
New attachments are not needed; the bug is accepted (status is 'new') and said to be fixed in trunk. If you want to do testing; then test trunk.