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.
Created attachment 157904 [details] Image of papers printed from PDF.
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
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).
[Automated Action] NeedInfo-To-Unconfirmed
(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)
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)).
(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.
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).
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.
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.
(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.
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.
(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.
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.
(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.
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.
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).
(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?
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.
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
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
Ok, let's set to new.
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.
Could somebody attach a problematic PDF?
Created attachment 172573 [details] Broken LO pdf export
Created attachment 172574 [details] Unbroken LO pdf export
Created attachment 172575 [details] Broken Mousepad print as file
Created attachment 172576 [details] Unbroken Mousepad print as file
Just following up on my request for advice as to where else I should report this. Thanks!
I have what may be another bug or this one, so I am posting it here first. I am exporting to pdf an ODT file of my own which consists of lots of pages, some of them from other sources or edited from such, and therefore in different typefaces, but a lot converted to my preferred 'LEXEND Deca'. In the original document, there are some items in Bold type (and also some in 'Lexend ExtraBold'). When I view the pdf, none of the Bold type appears on screen as such and I have tried different pdf viewers, and other people have also reported this on their computers viewing it (I haven't actually printed it on paper, as I said, it's a large file). The document itself does not appear to be at fault, a friend took my odt document, and managed from her setup (I think she uses Microsoft, but I don't know) to get Bold in the pdf. So something is going wrong on the BOLD handling, encoding or font-handling, I presume. I am not really a techie, so can't give much more info, but can give more details if you tell me where to look (I'm afraid my last computer job was in the era of COBOL, BBS work, and Paradox).