SUMMARY ------- When exporting a LibreOffice Writer document into PDF, the color of the font is ignored. The PDF document shows the text in black regardless of the actual font color in the original document. OBSERVED BEHAVIOR ----------------- Created a document using LibreOffice Writer and, after exporting it to a PDF file, the font's color, which had originally been set to white, was still black. EXPECTED BEHAVIOR ----------------- The text that had been set to white in the original document should've had white as it color in the PDF file, thus making the text "invisible" against the white background. STEPS TO REPRODUCE ------------------ 1. Create a new LibreOffice Writer Document. 2. Write some text to it. 3. Select the text and change the font's color to a different color (e.g. white). 4. Export the document into a PDF. 5. Use a PDF viewer and check the exported font's color.
I can not confirm with Version: 6.0.0.0.alpha1+ Build ID: c79467ba954987f1d239c594c1e1b3af3f5515f6 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; Locale: en-GB (cs_CZ.UTF-8); Calc: group
@raal: Can you confirm with the version I listed to see if there was an actual fix or if something else might be going on then?
Do you, by any chance, have the option “Print text in black” enabled in File > Print > LibreOffice Writer tab?
@adolfo: Yes. I unchecked the box and tried exporting again and it solved the problem. Is there a way that the UI can be improved on this? It is not at all obvious that "exporting" a PDF will be using the same options as sending the file for "printing" on a printer. In fact, the option is not even shown in the exporting options dialog presented to the user (e.g. File > Export as PDF...). If printing options are going to affect exports, then the relevant settings should be displayed to the user. I understand the reply may be "We're just printing to a file, so it makes sense to use print settings", which is fine and is not the issue. The issue is that it is not at all clear/obvious to the user that this is the case. Hope this can be improved and further false positives like mine avoided.
(In reply to xghost from comment #4) > @adolfo: Yes. I unchecked the box and tried exporting again and it solved > the problem. > > Is there a way that the UI can be improved on this? It is not at all obvious > that "exporting" a PDF will be using the same options as sending the file > for "printing" on a printer. > > In fact, the option is not even shown in the exporting options dialog > presented to the user (e.g. File > Export as PDF...). If printing options > are going to affect exports, then the relevant settings should be displayed > to the user. > > I understand the reply may be "We're just printing to a file, so it makes > sense to use print settings", which is fine and is not the issue. The issue > is that it is not at all clear/obvious to the user that this is the case. > > Hope this can be improved and further false positives like mine avoided. Let's ask UX.
Tools > Options > LibO Writer > Print provides the option to print text in black. That's fine, more or less, and the question is rather if users understand that exporting a PDF is printing. I would say yes. The alternative to duplicate all these options for PDF sounds much more awkward to me. => WFM in my opinion
I disagree here: If I use "Export to PDF", then I expect, that the PDF looks like the document on screen. "Export to PDF" is no printing. Printing is always in regard to a special printer. But the resulting pdf-file can be printed to varies printers having different properties. "Export to PDF" is no printing, because it allows embedding the document, security settings, signatures and watermark. It is a setting in section "print". Such setting should not influence other exports. For example, if you select "Brochure" in the printer settings, I'm sure, you still want the pdf to have the normal page order.
(In reply to Regina Henschel from comment #7) > I disagree here... Reasonable arguments. But how about "Print to PDF"?
(In reply to Heiko Tietze from comment #8) > Reasonable arguments. But how about "Print to PDF"? That is a different operation. Windows 10 has a "Microsoft print to PDF" as printer in the printing dialog. There I expect, that my printer settings are honored, because it is listed as printer. There it is no problem, because the printing preview shows, what I get. The problem is, that printer settings affect "Export to PDF".
Mind that for the automatically inserted blank pages, we already have a separate setting for printing and PDF eport
(In reply to Regina Henschel from comment #7) > I disagree here: > If I use "Export to PDF", then I expect, that the PDF looks like the > document on screen. > "Export to PDF" is no printing. Printing is always in regard to a special > printer. But the resulting pdf-file can be printed to varies printers having > different properties. > "Export to PDF" is no printing, because it allows embedding the document, > security settings, signatures and watermark. > It is a setting in section "print". Such setting should not influence other > exports. For example, if you select "Brochure" in the printer settings, I'm > sure, you still want the pdf to have the normal page order. I agree. I also understand Heiko Tietze's point about not wanting to duplicate the Print settings/UI in the PDF export UI. It seems (to me) like a fundamental part of the issue is that some have coupled two different concepts/ideas: 1. printing a document in a printer; and 2. exporting a document in one format X to another format Y To me, printing implies an actual physical printer and physical paper whereas exporting implies more of a transformation (i.e. format conversion). For example, GIMP can "export" its .xsd files into other formats such as .png, .jpeg, etc. and I think that makes sense. None of those involve printing a document. (In reply to Heiko Tietze from comment #6) > the question is rather if users understand that exporting a PDF is printing. I would say yes. I disagree. I think that was more of an unintended coincidence where it simply turned out well and/or people figured it out in most cases, at least until a more obscure issue like this one comes up, rather than it being an instance of actual conscious understanding and awareness. For example, I see the "Export to PDF" option more like a "Convert my current document to a PDF file" and not as a "Print this document to a PDF". In other words, I had always interpreted "export" as a synonym for "convert" or "transform" rather than for "print", which tends to imply the use of an actual physical printer. Thus, when it became clear that the options meant for my printer were actually affecting the options for my exports/conversions, it stood out as a very awkward and unexpected thing. The idea of calling it "Print to PDF" I think will blur an important, even if subtle, conceptual distinction and may cause more problems than it solves. I think the idea of printing and exporting should be decoupled more explicitly, as they're (IMHO) two different/separate concepts that should not be thought of as being one and the same thing. To me, that'd be similar to saying that a dog and a cat are the same thing simply because they both have hair, 4 legs, and a tail :) In fact, this very issue caused me a *lot* of extra work during my MS Project report, especially with code snippets that I had painstakingly highlighted with different colors in the original document, but would always get rendered in black in the PDF I was exporting it to... I had to spend a significant amount of time/effort working around the issue by replacing all the code snippets in the document for TextBox objects just to get the syntax highlighting to show up correctly, among other details and issues I won't go into. Needless to say, it was very frustrating. I didn't report this at the time, because I didn't have time to go around discussing things, and I think this will be the case for most people who do end up running into this kind of situation. (In reply to Heiko Tietze from comment #6) > The alternative to duplicate all these options for PDF sounds much more awkward to me. I agree. My comment there was more about getting the conversation going, rather than seriously requesting that everything be duplicated. I'm more interested in the conceptual distinction that leads users to expect certain specific and different behaviors.
tl;dr: Please clean-up the PDF export from printing options. We discussed this question in the design meeting. The user expectation is to export a document like it is shown (WYSIWYG), so the recommendation is to neither adopt the print options not to duplicate those. That means a red font is always exported in this color, even when print text in black is checked. If the user wants black text in the exported pdf, the supposed way is to use a tool/driver that supports print to pdf (available out of the box under Windows).
(In reply to Heiko Tietze from comment #12) > tl;dr: Please clean-up the PDF export from printing options. > > We discussed this question in the design meeting. The user expectation is to > export a document like it is shown (WYSIWYG), so the recommendation is to > neither adopt the print options not to duplicate those. That means a red > font is always exported in this color, even when print text in black is > checked. If the user wants black text in the exported pdf, the supposed way > is to use a tool/driver that supports print to pdf (available out of the box > under Windows). I would love to see that worked out in detail and discussed. Since - as I can understand it now - it seems to break the known work flow that I refer to in my comment #10. & Also want to check if being dependent on an external tool, will not limit the use of options that LibreOffice offers for PDF-export, in case the user wants e.g. black.
(In reply to Cor Nouws from comment #13) > I would love to see that worked out in detail and discussed. Yeah. There's considerable overlap conceptually between printing and pdf export (i.e. using pretty much the same code path on Linux, with the CUPS pdf print queue). There's also features in the PDF export one *cannot* get from OS-level 'print to PDF', e.g. working hyperlinks. So on balance, I'd hesitate to chop off rendering options that affect both PDF and print, if as in this case the option could simple be described better?
Design team's assessment was that users expect PDF export in full WYSIWYG and not related to printing. Users rather see PDF as a kind of export filter. But it's absolutely clear that code rules everything and compromises are okay.
(In reply to Heiko Tietze from comment #15) > Design team's assessment was that users expect PDF export in full WYSIWYG > and not related to printing. Users rather see PDF as a kind of export > filter. But it's absolutely clear that code rules everything and compromises > are okay. Then did the team on duty ;) also decide to clean up the whole thing, make choices clear, explicit, optional per action?
(In reply to Cor Nouws from comment #16) > Then did the team on duty ;) also decide to clean up the whole thing, make > choices clear, explicit, optional per action? The team on duty didn't go into detail. And I think it's pretty clear to get PDF similar to file export; ideally we do not need choices and options. https://wiki.documentfoundation.org/Design/Meetings/2017-12-06
Daniel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=08441d466dd70c203a519a133aaf1a5997adbbd3 tdf#113866 print text in black print option doest not affect PDF export It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Notes for unit test writers: Revert has to be done manually. PDF exports can be checked with pdfium, see for example sw/qa/extras/globalfilter/globalfilter.cxx
Adam Seskunas committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/380081381ff3b3cae64a40c6cc2a82772cb663c1 tdf#113866 Add test. It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.