Bug 105979 - Glyph outlines are corrupted in exported PDF
Summary: Glyph outlines are corrupted in exported PDF
Status: RESOLVED DUPLICATE of bug 126242
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-13 13:37 UTC by [REDACTED]
Modified: 2019-10-19 13:39 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
An image of corrupted glyph outlines after PDF export. (21.39 KB, image/png)
2017-02-13 13:41 UTC, [REDACTED]
Details
PDF form LibreOffice showing issue (4.08 KB, application/pdf)
2017-02-20 14:41 UTC, [REDACTED]
Details
PDF printed from LibreOffice via Ghostscript printer (no issues) (4.35 KB, application/pdf)
2017-02-20 14:42 UTC, [REDACTED]
Details

Note You need to log in before you can comment on or make changes to this bug.
Description [REDACTED] 2017-02-13 13:37:50 UTC
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
Comment 1 [REDACTED] 2017-02-13 13:41:12 UTC
Created attachment 131175 [details]
An image of corrupted glyph outlines after PDF export.
Comment 2 V Stuart Foote 2017-02-13 23:51:37 UTC
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?
Comment 3 [REDACTED] 2017-02-14 07:02:52 UTC
The issue is present regardless of OpenGL and hardware acceleration settings.
Comment 4 Buovjaga 2017-02-19 17:25:49 UTC
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.
Comment 5 [REDACTED] 2017-02-20 12:41:15 UTC
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.
Comment 6 ⁨خالد حسني⁩ 2017-02-20 13:30:53 UTC
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?
Comment 7 ⁨خالد حسني⁩ 2017-02-20 13:32:40 UTC
Attaching the PDF file can be useful as well.
Comment 8 [REDACTED] 2017-02-20 14:41:39 UTC
Created attachment 131361 [details]
PDF form LibreOffice showing issue
Comment 9 [REDACTED] 2017-02-20 14:42:45 UTC
Created attachment 131362 [details]
PDF printed from LibreOffice via Ghostscript printer (no issues)
Comment 10 [REDACTED] 2017-02-20 14:43:33 UTC
Switching to old layout engine has no effect.
Comment 11 [REDACTED] 2017-02-20 14:49:41 UTC
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).
Comment 12 ⁨خالد حسني⁩ 2017-02-20 15:14:56 UTC
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.
Comment 13 [REDACTED] 2017-02-20 15:50:08 UTC
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.
Comment 14 Buovjaga 2017-02-20 16:03:05 UTC
(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
Comment 15 [REDACTED] 2017-02-20 16:21:35 UTC
The issue goes as far back as version 3.3.0.4 (the oldest version available on https://downloadarchive.documentfoundation.org).
Comment 16 teh.schmidt 2017-05-12 03:45:44 UTC
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
Comment 17 Xisco Faulí 2018-01-15 11:20:18 UTC
(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
Comment 18 ⁨خالد حسني⁩ 2018-02-24 14:07:47 UTC
Fix for bug 114704 could potentially have fixed this as well.
Comment 19 Buovjaga 2018-02-24 14:11:09 UTC
(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/
Comment 20 Timur 2018-07-09 16:14:18 UTC
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.
Comment 21 V Stuart Foote 2019-10-19 13:39:26 UTC

*** This bug has been marked as a duplicate of bug 126242 ***