Description: After exporting PDF from LibreOffice Writer via built-in PDF Export function some glyphs of certain typefaces have slightly corrupted outlines (see attachment). This is noticeable in print for larger font sizes (think, title page). The same does not happen if Ghostrscript-based virtual printer is used instead of LibreOffice export function. Unfortunately I'm able to reproduce it only with proprietary Garamond Premier Pro font at this time (though it is hardly an issue specific to this font). Steps to Reproduce: 1. Install Garamond Premiere Pro (Adobe) OpenType font. 2. Create a new document in Writer. 3. Set a font to Garamond Premier Pro. 4. Type "Te" characters. 5. Export PDF via built-in PDF Export function. 6. Open exported PDF. 7. Zoom into characters. Actual Results: You see corrupted glyphs as in left part of attached image. Expected Results: You see uncorrupted glyphs as in right part of attached image. Reproducible: Always User Profile Reset: No Additional Info: OS: Windows 10 x64 LibreOffice 5.3.0.3 (x64) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36 OPR/43.0.2442.806
Created attachment 131175 [details] An image of corrupted glyph outlines after PDF export.
Is OpenGL rendering enabled? Disable OpenGL and do the export, any affect? Is "Hardware acceleration" enabled? Disable it and allow CPU only processing, any affect?
The issue is present regardless of OpenGL and hardware acceleration settings.
Please try to find a non-commercial font we can use to reproduce this. Set to NEEDINFO. Change back to UNCONFIRMED after you have found the font.
After testing with a whole bunch of free fonts I can't reproduce the issue with any of them. Maybe the problem is peculiar to OpenType (I have no freely available OpenType fonts). I'm a software developer (C++), so if you are willing to provide some guidance and depending on the amount of labour involved I might be able to investigate the issue.
Is this a regression in 5.3 or an old issue? If it is a regression, does using the old layout engine (by e.g. setting SAL_NO_COMMON_LAYOUT env variable) make any difference? (the About window should tell which layout engine is used). Few more question, are you converting the text to outlines some how or just regular PDF export where text is selectable etc. Is this a font with TrueType (usually .ttf) or PostScript (.otf) outlines?
Attaching the PDF file can be useful as well.
Created attachment 131361 [details] PDF form LibreOffice showing issue
Created attachment 131362 [details] PDF printed from LibreOffice via Ghostscript printer (no issues)
Switching to old layout engine has no effect.
The font in question is OpenType font (with PostScript outlines). This is a regular PDF export (just typed two characters in a blank LibreOffice document and selected "Export as PDF" in menu).
I extracted the font from both PDFs, the GhostScript one embeds the font as CFF font and the glyphs inside the font are indeed fine, but ours embeds it as Type1 font and the glyphs there are broken. I suspect something is wrong with our CFF to Type1 conversion (our subsetter does not support producing CFF fonts). The code in question should be in vcl/source/vcl/source/fontsubset/cff.cxx (CffSubsetterContext::emitAsType1(), particularly the code that loops over glyph ids). This might require a bit of understanding of Type1 and Type1 CharString. If this is a regression, then finding the last version this worked might help finding out what broke it.
Thanks for the info. Regarding regression I have no info as I started to use professional OpenType fonts only recently and immediately found this issue. I'll start by trying the previous versions.
(In reply to Pavel from comment #13) > Thanks for the info. Regarding regression I have no info as I started to use > professional OpenType fonts only recently and immediately found this issue. > I'll start by trying the previous versions. You might start with a really old version like 3.5 or 3.6: https://wiki.documentfoundation.org/Installing_in_parallel/Windows Then to pinpoint it more closely: https://wiki.documentfoundation.org/QA/Bibisect https://wiki.documentfoundation.org/QA/Bibisect/Windows
The issue goes as far back as version 3.3.0.4 (the oldest version available on https://downloadarchive.documentfoundation.org).
Printing gridlines seems to be part of the same issue. I get this same issue in the Windows version. Printing misses a lot of the lines on a simple spreadsheet grid. Same thing exporting to PDF. However, the Linux version works fine. There I can print everything as it should be. Version: 5.2.6.2 Build ID: a3100ed2409ebf1c212f5048fbe377c281438fdc CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Locale: en-US (en_US); Calc: group
(In reply to teh.schmidt from comment #16) > Printing gridlines seems to be part of the same issue. > > I get this same issue in the Windows version. Printing misses a lot of the > lines on a simple spreadsheet grid. Same thing exporting to PDF. However, > the Linux version works fine. There I can print everything as it should be. > > Version: 5.2.6.2 > Build ID: a3100ed2409ebf1c212f5048fbe377c281438fdc > CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; > Locale: en-US (en_US); Calc: group Could you please provide a clear set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
Fix for bug 114704 could potentially have fixed this as well.
(In reply to Khaled Hosny from comment #18) > Fix for bug 114704 could potentially have fixed this as well. Ok, everyone affected please test with this: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Since no reply to Khaled's question, I'll close. If you test again and experience issue with current versions, feel free to set Unconfirmed, with steps for testing.
*** This bug has been marked as a duplicate of bug 126242 ***