Bug 95221 - LibreOffice does not embed the latest urw-core35-fonts correctly
Summary: LibreOffice does not embed the latest urw-core35-fonts correctly
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-21 12:30 UTC by Tom Yan
Modified: 2018-04-30 22:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
problematic embedding (2.74 MB, application/pdf)
2015-10-21 12:31 UTC, Tom Yan
Details
working embedding (2.68 MB, application/pdf)
2015-10-21 12:31 UTC, Tom Yan
Details
broken pdf from LO with one string in Roman Regular (119.55 KB, application/pdf)
2015-10-21 14:22 UTC, Tom Yan
Details
working pdf from LO with one string in Roman Regular (115.11 KB, application/pdf)
2015-10-21 14:22 UTC, Tom Yan
Details
broken pdf from LO with one string in Roman Regular (121.81 KB, application/pdf)
2015-10-21 20:12 UTC, Tom Yan
Details
working pdf from LO with one string in Roman Regular (117.13 KB, application/pdf)
2015-10-21 20:13 UTC, Tom Yan
Details
fixed roman.pdf by replacing/injecting objects (118.86 KB, application/pdf)
2015-10-21 20:41 UTC, Tom Yan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Yan 2015-10-21 12:30:14 UTC
Attached are two PDFs with embedded urw-core35-fonts of two different versions. Somehow LO does not embeded the fonts of new version correctly anymore for AT LEAST latin alphabets with grave accent.

According to a ghostscript dev, this might have something to do with differences array for the encoding.

Although this happen only to fonts get updated in the latest version, it doesn't seem like it's an issue of the fonts themselves, since others programs (goffice, chromium, firefox...) seem to have no problem on embedding them.

Since this is the commit of the fonts the problem occurs: http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=c983ed400dc278dcf20bdff68252fad6d9db7af9

And this is the last commit working with LO:
http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=e5b3fce0aadb091699b409be325468c682bd436d

The two attached PDFs are produced with them respectively.
Comment 1 Tom Yan 2015-10-21 12:31:26 UTC
Created attachment 119822 [details]
problematic embedding
Comment 2 Tom Yan 2015-10-21 12:31:52 UTC
Created attachment 119823 [details]
working embedding
Comment 3 Tom Yan 2015-10-21 14:22:35 UTC
Created attachment 119831 [details]
broken pdf from LO with one string in Roman Regular

For easier debugging
Comment 4 Tom Yan 2015-10-21 14:22:53 UTC
Created attachment 119832 [details]
working pdf from LO with one string in Roman Regular

For easier debugging
Comment 5 Tom Yan 2015-10-21 20:12:15 UTC
Created attachment 119848 [details]
broken pdf from LO with one string in Roman Regular

uncompressed with `qpdf --stream-data=uncompress`
Comment 6 Tom Yan 2015-10-21 20:13:00 UTC
Created attachment 119849 [details]
working pdf from LO with one string in Roman Regular

uncompressed with `qpdf --stream-data=uncompress`
Comment 7 Tom Yan 2015-10-21 20:41:10 UTC
Created attachment 119850 [details]
fixed roman.pdf by replacing/injecting objects

It seems like LibreOffice has always been including useless BaseFont and CMap objects. Since they the only ones roman.pdf have, the font cannot be rendered correctly.

But in roman-old.pdf, extra useful BaseFont, Encoding and CMap objects are included in addition so the pdf works fine.

Since the embedded font stream is fine, as long as I put the useful objects into roman.pdf, it will basically work again.

Attached is a fixed version of roman.pdf created with simple editing in emacs. I just replaced the BaseFont and CMap objects, added the Encoding object, change the relevant object indexes; I also need to change "<E0>2<E8>-5<EC>3<F2F9>" to "<00>2<01>-5<02>3<0304>" in object #5.

Somehow LO no longer includes the useful objects when it deals with the newer version of fonts.

Also see this bug report: http://bugs.ghostscript.com/show_bug.cgi?id=696263
Comment 8 David Kremer 2016-03-20 15:05:40 UTC
I have such a bug when using Nimbus family font and 5.1.1.3 version.
Comment 9 David Kremer 2016-03-20 15:06:24 UTC
(In reply to David Kremer from comment #8)
> I have such a bug when using Nimbus family font and 5.1.1.3 version.

However, with most of the family fonts I used, everything went fine except the Nimbus one.
Comment 10 Buovjaga 2016-03-25 15:55:31 UTC
(In reply to David Kremer from comment #8)
> I have such a bug when using Nimbus family font and 5.1.1.3 version.

Close enough, so setting to NEW
Comment 11 QA Administrators 2017-05-22 13:19:06 UTC Comment hidden (obsolete)
Comment 12 ⁨خالد حسني⁩ 2018-04-30 22:24:56 UTC
Support for Type 1 fonts was dropped a few versions ago.