Bug 130693 - PRINTING: font or style selectively changed from Writer in PDF printout
Summary: PRINTING: font or style selectively changed from Writer in PDF printout
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.3.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2020-02-15 20:31 UTC by Nick Levinson
Modified: 2021-06-11 16:39 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Image of papers printed from PDF. (70.20 KB, image/png)
2020-02-15 20:42 UTC, Nick Levinson
Details
Broken LO pdf export (20.31 KB, application/pdf)
2021-06-02 12:33 UTC, Tom
Details
Unbroken LO pdf export (17.44 KB, application/pdf)
2021-06-02 12:33 UTC, Tom
Details
Broken Mousepad print as file (20.64 KB, application/pdf)
2021-06-02 12:34 UTC, Tom
Details
Unbroken Mousepad print as file (20.64 KB, application/pdf)
2021-06-02 12:35 UTC, Tom
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Levinson 2020-02-15 20:31:43 UTC
Description:
When I print a PDF, certain characters get a different font or style than the ODT document had, but in the header and not in the body. The ill effect is not visible by viewing the PDF in the computer or previewing it in a printer, but it is visible on the paper printout.

Steps to Reproduce:
1. Open or create a Writer .odt document with a header in the font DejaVu Serif, italic, 10 points, including letters "M" and "N" and the numeral "4", and, if not saved yet, save it.

2. Use Writer to make a PDF using File > Export As > Export as PDF... and default settings and save the PDF to a portable flash drive.

3. Displaying the PDF in my computer, in Document Viewer (Evince) v3.34.2, does not show the problem. I do not know the effect with a printer attached or networked to the computer, so look for a printer that will let you plug in your flash drive locally and read it. I had the problem with a self-service Xerox printer at a Staples store and two self-service Canon printers at two FedEx Office (formerly Kinko's) stores.

4. If your printer has its own preview function, preview the characters in question. If the problem is visible, you're done with these steps. But if you need paper proof, print.

5. If the preview shows no ill effect, print anyway.

Actual Results:
The characters appear to be bold and from another font, and so does the numeral but not as much, but I'm unable to identify the style or font other than what I see visually.

Expected Results:
The font and style should be only what is specified in the Writer document. If the PDF must have it differently, at least its Properties must list what's new.


Reproducible: Always


User Profile Reset: No



Additional Info:
The problem persists in version 6.3.4.2.0+ (build ID 6.3.4.2-2.fc31). I'm not prepared to install a newer or unstable verion.

The problem does not occur in the body in plain or roman style 11-13 points. Where it does occur, in the header designed per STR 1, most characters are unaffected.

The PDF document hamburger menu > Properties > Fonts page lists only the fonts I specified when formatting in Writer. It uses separate fonts for plain and italic but does not list a bold font. The fonts are TrueType subsets, embedded and encoded WinAnsi.

In general, the header italic problem probably occurs with 8-10 points and may occur with 10-11 points, even though it does not occur with 11 points in the body in plain or roman style.

I did not test the full character set, only the characters on key caps.

I did not try File > Export As > Export Directly as PDF.

I did not try other kinds of storage media but that shouldn't matter.

As the effect has been seen in several documents over months, my storage device does not appear defective and various LO versions (all then current) were affected.

LO's safe mode appears irrelevant.

I don't have an OpenGL setting.
Comment 1 Nick Levinson 2020-02-15 20:42:52 UTC
Created attachment 157904 [details]
Image of papers printed from PDF.
Comment 2 Buovjaga 2020-05-10 19:06:19 UTC
I put the text in the header like you described, but no problem. Exported PDF, opened in Okular and printed to PDF. Also printed to PDF from LibreOffice itself.

You can try a newer version without installing by using an appimage: https://libreoffice.soluzioniopen.com/

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.

Arch Linux 64-bit
Version: 7.0.0.0.alpha1+
Build ID: e622420c0aa8116294e85c076ff2d8fc6131595f
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; 
Locale: en-US (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 10 May 2020
Comment 3 Nick Levinson 2020-05-22 21:23:31 UTC
You say printed "to" PDF. Do you mean you exported to PDF or that you printed from the PDF onto paper? I don't see the wrong font or style in the PDF but I do get the wrong font or style on the paper from the PDF (the various printers I use are in commercial establishments for public use and won't print from the .odt file).
Comment 4 QA Administrators 2020-05-23 03:44:30 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2020-05-23 10:59:38 UTC
(In reply to Nick Levinson from comment #3)
> You say printed "to" PDF. Do you mean you exported to PDF or that you
> printed from the PDF onto paper? I don't see the wrong font or style in the
> PDF but I do get the wrong font or style on the paper from the PDF (the
> various printers I use are in commercial establishments for public use and
> won't print from the .odt file).

I said I both
- exported a PDF, printed it to PDF from Okular
- printed a PDF from LibreOffice Writer

You print a PDF from LibreOffice by File - Print - Printer: Print to file... (under Linux - under Windows you can use MS PDF printer)
Comment 6 Nick Levinson 2020-05-26 20:53:32 UTC
I'm still unclear. Did you print to paper from the LibreOffice PDF? Printing to PDF doesn't sound like paper, but maybe I misunderstand what you intended to say.

This may be a more subtle problem. Okular is an interesting workaround, but it doesn't apply to using commercial printers. Likewise, when I use the commercial printers, I bring the PDF via sneakernet: my flash drive, thus not LO. The problem I had occurred on both Xerox and Canon printers, multiple machine of each brand, over a period of weeks, in different store chains (Xerox was at Staples and Canon was at FedEx Office (formerly Kinko's)).
Comment 7 Buovjaga 2020-05-27 07:41:38 UTC
(In reply to Nick Levinson from comment #6)
> I'm still unclear. Did you print to paper from the LibreOffice PDF? Printing
> to PDF doesn't sound like paper, but maybe I misunderstand what you intended
> to say.

No, I did not print to paper.
Comment 8 Nick Levinson 2020-05-27 18:36:34 UTC
Printing to paper is where the problem becomes visible, and that's despite using different printers, different brands of printer, different models of printer, and different paper basis weights (20-lb. and 24-lb.) and printing in different store chains, in different weeks, and from different files. The problem is not visible in the ODT file, the PDF as viewed in my laptop, or either printer's screen preview. But it happens on ordinary white paper with no distinct texture, from the same flash drive (Transcend), and using the same font in a small font size in the header (it does not occur in the body and I don't use the footer).
Comment 9 Buovjaga 2020-05-28 14:14:18 UTC
Now I tried with printing (the exported PDF from Okular). I used this procedure in order to not waste paper:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer

Getting the produced PDF file from /var/spool/cups/ I see it is just fine.
Comment 10 Nick Levinson 2020-06-01 23:15:03 UTC
That's comparing apples to oranges. I still don't know why the previews in your system via Okular and in my laptop, including in Writer for ODT and Okular for PDF and, for PDF, on Canon and Xerox are all correct while the paper output from Canon and Xerox are wrong.
Comment 11 Buovjaga 2020-06-02 06:30:23 UTC
(In reply to Nick Levinson from comment #10)
> That's comparing apples to oranges. I still don't know why the previews in
> your system via Okular and in my laptop, including in Writer for ODT and
> Okular for PDF and, for PDF, on Canon and Xerox are all correct while the
> paper output from Canon and Xerox are wrong.

It's comparing apples to apples. Intercepting the spool file gives you the exact thing that would be printed. There is no need to waste paper.
Comment 12 Nick Levinson 2020-06-02 15:53:46 UTC
It should, but it doesn't. As noted above, all of the previews, yours and mine, show there's no problem, but the paper showed a problem, consistently. It's tempting to say that the printer is at fault, but that requires blaming two brands of printer in different store chains over months. You can see what it looks like on paper by viewing the attachment to this bug report. There's a problem.

The Canon is probably an ImageRunner Advance C5540i (the store I used was closed for now but it's likely the same). I tried to identify the Xerox model, but it's not labeled except on the back, to which I don't have access without bothering the store and I don't want to be told to leave. All are multifunction machines.

The problem is limited to the header and is not in the body (the footer was not tested), and differentiating between header and body requires information that would not be native to the printer. I also don't think the printer has fonts independently of a PDF. (It likely has fonts for its display but probably not for printing.) I also don't think the printer can style a roman font. There'd be no reason for the printer companies to add all that programming.

Therefore, something is wrong in LO's PDFs. We need a diagnosis.
Comment 13 Buovjaga 2020-06-02 16:11:01 UTC
(In reply to Nick Levinson from comment #12)
> It should, but it doesn't. As noted above, all of the previews, yours and
> mine, show there's no problem, but the paper showed a problem, consistently.
> It's tempting to say that the printer is at fault, but that requires blaming
> two brands of printer in different store chains over months. You can see
> what it looks like on paper by viewing the attachment to this bug report.
> There's a problem.

Just to prove that it is apples to apples when looking at the spool file, I did a physical printout (LibO -> PDF -> Okular -> Printer) just now and there is nothing wrong with it.
Comment 14 Nick Levinson 2020-06-02 16:55:58 UTC
Depends on the printer, evidently. So now we know that it fails on two and succeeds on one. What printer brand and model did you use?

I'm assuming you used the same font I did, in a Writer header, with the same 3 characters, in a similar font size, etc., yes?

Thank you.
Comment 15 Buovjaga 2020-06-02 17:13:47 UTC
(In reply to Nick Levinson from comment #14)
> Depends on the printer, evidently. So now we know that it fails on two and
> succeeds on one. What printer brand and model did you use?

Canon LBP7018C

> I'm assuming you used the same font I did, in a Writer header, with the same
> 3 characters, in a similar font size, etc., yes?

Yes.
Comment 16 Nick Levinson 2020-06-12 17:01:19 UTC
New testing found this:

--- The text being in the body, header, or footer doesn't matter.

--- Sizes affected are small: 6, 7, 8, 9, and 10pt. The following are not affected: 10.5, 11, 12, 13, and 14pt. I did not test other sizes. I chose 10.5 because it's in the menu. No other fractional font size within this range is in the menu.

--- Fonts: The problem may be limited to DejaVu Serif (similar to Garamond, which is preferred for visually-impaired users, thus not easily replaced on the platform), since the problem is absent with FreeSerif (similar to Times New Roman (Windows)), FreeSans (similar to Helvetica (Windows)), and Nimbus Mono PS (similar to Courier New (Windows)).

--- I did not test any style besides roman and italic. Thus, I did not test bold italic, which would be a reasonable test subject.

--- Prints show streaks across certain characters but the streaks are consistent across different machines of the same brand and model, different brands and models, and different store chains housing the machines. Thus, it's unlikely to be an anomaly of one machine or of bad maintenance.

--- The printer previews now show the problem. Since they didn't before and this has been going on for months, it's likely that updates to the machines fixed their preview problem. I don't know the update histories for the machines. But that still leaves the contradiction between Writer, Okular, and Evince in the previews, on the one hand, and, on the other hand, the Canon (C5540i) and Xerox paper outputs.

A Xerox machine was identified as the J-A133, and probably all the Xerox machines involved are the same model. However, I didn't find that exact designation in a Xerox.com website.

Why the other commenter's Canon LBP7018C handled the PDF well is an open and relevant question.

My tentative diagnosis is that the PDF made by LO has noncompliant code so that some machines misinterpret the PDF and do not print what was prepared in LibreOffice Writer. Some machines may be tolerant and print as intended, while some machines may be intolerant of the error and produce bad paper output.
Comment 17 Nick Levinson 2020-06-12 17:41:26 UTC
I tried to submit an attachment and would have submitted three altogether, but apparently the documentfoundation.org server for attachments has a protocol mismatch with Firefox, Web (that's the name of a browser), and Chromium. Basically, they would have shown the views in Okular (which was OK) and Evince (which was OK) and some of the paper outputs (which were not OK). Hopefully, the server will get fixed (maybe it's a TLS problem).
Comment 18 Buovjaga 2020-06-12 18:15:18 UTC
(In reply to Nick Levinson from comment #17)
> I tried to submit an attachment and would have submitted three altogether,
> but apparently the documentfoundation.org server for attachments has a
> protocol mismatch with Firefox, Web (that's the name of a browser), and
> Chromium. Basically, they would have shown the views in Okular (which was
> OK) and Evince (which was OK) and some of the paper outputs (which were not
> OK). Hopefully, the server will get fixed (maybe it's a TLS problem).

How did this problem manifest? The only thing is we have a 30 MB limit for files. Maybe it's a temporary glitch?
Comment 19 Nick Levinson 2020-06-15 17:26:20 UTC
I doubt it's a temporary glitch of the sort that gets solved without a hand. I tried in two sessions, hours apart, Friday. In the first session, I tried Firefox 77.0.1 (64-bit), Web 3.36.2, and Chromium 81.0.4044.138 (Developer Build) Fedora Project (64-bit). When I tried with Firefox, the first time it was in a waiting state and then the favicon appeared with no other signal of completion or failure. When I reclicked to submit, after a wait a failure message was displayed by the browser (more on that later). When I tried with Web, it seemed to take forever and I gave up. When I tried with Chromium, a failure message was displayed by the browser (more on that later). This was before I posted comment 17, about trying. In the second session, which was after I saw comment 18, I tried Firefox and Chromium. Firefox again failed once without a message, the same as before, and then, upon resubmission, failed with the following message from the browser: "Secure Connection Failed"/"An error occurred during a connection to bugs.documentfoundation.org."/"The page you are trying to view cannot be shown because the authenticity of the received data could not be verified."/"Please contact the website owners to inform them of this problem."/"Learn more..." (suspension points or ellipsis so in original) (https://bugs.documentfoundation.org/attachment.cgi linking through "Learn more..." to https://support.mozilla.org/1/firefox/77.0.1/Linux/en-US/connection-not-secure). This is likely what FF said in the first session. Chromium said this time, as it probably did the first time, "This site can’t be reached"/"The webpage at https://bugs.documentfoundation.org/attachment.cgi might be temporarily down or it may have moved permanently to a new web address."/"ERR_HTTP2_PROTOCOL_ERROR" (https://bugs.documentfoundation.org/attachment.cgi).

The file I wanted to attach was 238.0 kB (238,048 bytes) long. I didn't try uploading the other files, which were 232.0 kB (232,015 bytes) and 1.7 MB (1,728,845 bytes). All sizes are per Properties on my laptop. The total size of all three would have been well under the limit. All are .png files.
Comment 20 Nick Levinson 2020-06-30 15:51:13 UTC
Following up on printer model identifications in comment 16: The problem also occurred on a Xerox AltaLink C8045 multifunction printer, probably newly installed, at a Staples store, when printing from a new PDF for text in DejaVu Serif 8pt prepared in LO Writer. The problem is not visible in the PDF even at 200% of size viewed in  my laptop. It is very visible in Xerox's preview at the printer, showing a streak that probably descended (from my recollection) 10-20 points. It is a little visible, as a distorted "M" on the paper output resulting from the same session in which I viewed the preview.

From Writer > Help > About LibreOffice:
Version: 6.4.4.2
Build ID: 6.4.4.2-2.fc32
CPU threads: 2; OS: Linux 5.6; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 21 Tom 2021-05-31 19:59:09 UTC
I have this exact problem. My system XUbuntu 21.04 up to date, LibreOffice 7.1.3.2. Using packages fonts-dejavu-core fonts-dejavu-extra 2.37-2build1 this problem appears as described by Nick Levinson - the pdf on my system appears normal when viewed with Atril document viewer, but when I load the pdf on my Sony EReader the fonts are degraded as described. Downgrading to fonts-dejavu-core and fonts-dejavu-extra 2.37-1 fixes the issue. 

Perhaps the Dejavu Italic fonts are not properly exported to be embedded in the pdf and a substitution is happening? That might explain why printing from the system matters as to be able to see this problem.

Also this bug report that might be related:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961389
Comment 22 Buovjaga 2021-06-01 04:53:36 UTC
Ok, let's set to new.
Comment 23 Tom 2021-06-01 17:10:56 UTC
Hello,

So I ran a test just now using Mousepad and printing to file (choosing pdf) with the two versions of fonts-dejavu-core and fonts-dejavu-extra. The problem appeared just as it did in LibreOffice. So I'm not sure this is a LO bug, but don't know where to post it. DejaVu fonts on Github? Debian? Ubuntu? Any advice would be appreciated.
Comment 24 Buovjaga 2021-06-02 06:38:29 UTC
Could somebody attach a problematic PDF?
Comment 25 Tom 2021-06-02 12:33:10 UTC
Created attachment 172573 [details]
Broken LO pdf export
Comment 26 Tom 2021-06-02 12:33:59 UTC
Created attachment 172574 [details]
Unbroken LO pdf export
Comment 27 Tom 2021-06-02 12:34:59 UTC
Created attachment 172575 [details]
Broken Mousepad print as file
Comment 28 Tom 2021-06-02 12:35:43 UTC
Created attachment 172576 [details]
Unbroken Mousepad print as file
Comment 29 Tom 2021-06-11 16:39:51 UTC
Just following up on my request for advice as to where else I should report this. Thanks!