Description: I am experiencing a strange issue with LibO PDF export. When I use certain fonts (and most notably Adobe Source Sans 3), the PDF files produced by LibO can be displayed correctly on screen using various PDF readers (e.g. Okular). However, when I send the PDF to the printer, many characters are missing and replaced by a little square with a cross inside. Can this be a problem with the subsetting of the font done for embedding? Otherwise, it seems very similar to what used to happen with certain versions of Distiller (see https://community.adobe.com/t5/acrobat-discussions/printing-problem-when-pdf-is-sent-to-the-printer-with-certain-fonts-missing-text/m-p/5673023). Reporting the problem for 7.5.1.2, but the issue started way earlier. Steps to Reproduce: 1. Install the free Source Sans 3 font (from Adobe's github repo) 2. Create a presentation using text with the Source Sans 3 font. 3. Export to PDF 4. Print the PDF Actual Results: In multiple occasions (but not always) characters will be missing from the printout. Expected Results: PDF should print well. Reproducible: Sometimes User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: StartModule [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 185675 [details] Test document
Created attachment 185676 [details] PDF file exported from the test document
The PDF file that has just been attached does not print correctly (at least using a linux system with CUPS and HP, Brother printers and possibly others).
Latest version of the font is available here: https://github.com/adobe-fonts/source-sans/releases/tag/3.046R Looking at the attached PDF, you used: - SourceSansPro-Light - SourceSans3-Bold - SourceSans3-Regular - SourceSans3-It ...all of them reported as "Type 1" by my PDF reader. Which format did you use to install the fonts?
The fonts in the PDF document are indeed reported as Type1 (you check them with the `pdffonts` utility as well, rather than using the information window in the PDF viewer). With this you get: name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- BAAAAA+SourceSansPro-Light Type 1 Builtin yes yes yes 24 0 CAAAAA+SourceSans3-Bold Type 1 Builtin yes yes yes 19 0 DAAAAA+ArialMT TrueType WinAnsi yes yes yes 29 0 EAAAAA+SourceSans3-Regular Type 1 Builtin yes yes yes 14 0 FAAAAA+SourceSans3-It Type 1 Builtin yes yes yes 9 0 The fonts file are originally OpenType fonts. To the best of my understanding, OTF fonts can either contain font data in a TrueType-like format or in a Type1-like format, the main difference between the two being that the TrueType format encodes the font contours in quadratic splines, while Type1 uses cubic splines (and should, at least in principle, have a potential advantage in rendering quality). When the fonts get "embedded" in a PDF document, it is the actual font data that gets embedded, so that any font diagnostics will either report "TrueType" or "Type1". On github, Adobe distributes either the fonts as OTFs or TTFs. In both cases you get fonts that are recognized as OpenType by the system, but the OTF fonts contain Type-1 font data, while the TTF fonts contain TrueType font data. I am on Linux and in this case the fonts can be installed in multiple ways. If you have Arch/Manjaro, then they come with the distro, in the `adobe-source-sans-fonts` package. The Arch/Manjaro package uses the OTF version of the font, with the expectation that it should be (slightly) higher quality. However, I have also tried with an Ubuntu system, where the font is not available out of the box. In this case, I have downloaded the `OTF-source-sans-3.046R.zip` file from `https://github.com/adobe-fonts/source-sans/releases/tag/3.046R` and unpacked it into the `.fonts` directory in my home (in some systems you need to use `.local/share/fonts`). So that the fonts can be found by `fontconfig`.
As a final note, I would like to report that if you take the PDF file produced by LibO and you process it using `ghostscript` on a system that has the needed fonts, e.g. using gs -q -dNOPAUSE -dBATCH -dPDFSETTINGS=/prepress -sDEVICE=pdfwrite -sOutputFile=output.pdf input.pdf then the PDF file obtained by ghostscripts gets the fonts re-embedded as: name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- AKSFEQ+DummyName Type 1C Custom yes yes no 7 0 FNPCHA+DummyName Type 1C Custom yes yes no 9 0 LKVFDZ+ArialMT TrueType WinAnsi yes yes yes 11 0 UNQEAT+DummyName Type 1C Custom yes yes no 13 0 TFLMGS+DummyName Type 1C Custom yes yes no 15 0 Once this is done, the PDF file prints perfectly. So, I would tend to think that there is an issue in how LibO embeds the fonts in the PDF file when it exports it.
Created attachment 185687 [details] How the document prints
[Automated Action] NeedInfo-To-Unconfirmed
Can anyone reproduce the issue? Is there anyone knowing of some tool for checking the font embedding (e.g. a PDF viewer not using the system fonts but only the embedded fonts?)
The attached PDF prints fine for me, so it is possible it is a printer issue. The fonts are embedded in the PDF (according to pdffonts output you posted). There is a known complication with .otf fonts, these contains glyph outlines in CFF format (an upgraded version of Type1, what pdffonts reports as Type1C), but by the time OpenOffice got support for embedding such fonts, CFF was deemed too new and the fonts are downgraded to Type1 when embedding in PDF. This can lead to some weird bugs, and it might be the case here. I suggest you try the .ttf files and see if it makes any difference, there should be no difference in quality between the two (apart from some differences in rasterization, depending on the system). Either case, this is hard to debug since it seems to be related to the printer you are using.
Can you please report on what system you are testing my PDF? (Windows, Linux, MacOS)? Can you also verify that you do not have a printer driver that enables the downloading of the system fonts to the printer or that pre-rasters the PDF into a bitmap for printing? Unfortunately, it is not so easy to switch to TTF, because the OTF fonts are shipped with the OS and with TeXLive. When there are both OTF and TTF versions of some fonts, packagers tend to prefer OTF since they expect it to be slightly higher quality. I'll need to find out if fontconfig has some option to express priority among fonts when multiple versions of the same font are present on the system...
(In reply to Callegar from comment #11) > Can you please report on what system you are testing my PDF? (Windows, > Linux, MacOS)? macOS > Can you also verify that you do not have a printer driver that enables the > downloading of the system fonts to the printer or that pre-rasters the PDF > into a bitmap for printing? No idea, I opened the file in Firefox and hit print. I’m blissfully ignorant about how printers work in general. > Unfortunately, it is not so easy to switch to TTF, because the OTF fonts are > shipped with the OS and with TeXLive. When there are both OTF and TTF > versions of some fonts, packagers tend to prefer OTF since they expect it to > be slightly higher quality. > > I'll need to find out if fontconfig has some option to express priority > among fonts when multiple versions of the same font are present on the > system... If you can uninstall the distribution package and install the TTFs directly, that should do it. I’m not suggesting using the TTFs as a solution, but trying to narrow down the cause of the issue.
Just for the record, I tested exporting as PDF with 7.5.1 on Ubuntu 20.04 with fonts installed as .ttf, pdffonts showing me: name type encoding emb sub uni object ID ----------------------------- ----------- ----------- --- --- --- --------- BAAAAA+SourceSansPro-Light TrueType WinAnsi yes yes yes 14 0 CAAAAA+SourceSans3-Bold TrueType WinAnsi yes yes yes 9 0 DAAAAA+ArialMT TrueType WinAnsi yes yes yes 19 0 EAAAAA+SourceSans3-Regular TrueType WinAnsi yes yes yes 29 0 FAAAAA+SourceSans3-It TrueType WinAnsi yes yes yes 24 0 Printing my PDF with an Epson WF-7720, no problem. Printing your PDF with the same printer, no problem either. PDF software is GNOME's Document Viewer / Evince.
Done more testing. The problem appears to be specific to some PDF viewers, including Okular. When you print from them the font gets corrupted. Hence in the end this is probably not a LibO bug nor a font bug, but a bug in some PDF libs used in popular viewers. However, it might be the case that the PDF is not fully compliant and that some viewers can handle minor lacks of compliance while other cannot. I have opened an issue with Okular https://bugs.kde.org/show_bug.cgi?id=467328. Let's see what the Okular developers say. In the meantime, I cannot say whether it is better to keep this issue tentatively open or not.
Setting to "needinfo" for now. Seems there's already some activity on the KDE tracker. Thanks!