Character deformed in PDF exported by LibreOffice

[m13253]

Information for package libreoffice:
------------------------------------
Repository     : openSUSE-20170403-0            
Name           : libreoffice                    
Version        : 5.3.1.2-1.3                    
Arch           : x86_64                         
Vendor         : openSUSE                       
Installed Size : 269.0 MiB                      
Installed      : Yes                            
Status         : up-to-date                     
Source package : libreoffice-5.3.1.2-1.3.src    

The version of Source Han Serif I'm currently installing is "language-specific OTF". I can confirm the problem on both OTF and SuperOTC versions.

This problem is also observed on Windows, where Mojibake is shown instead.

I'm not sure it is totally LibreOffice's fault. I'll cross-post after confirmed.

[m13253]

Adobe Acrobat PDF printer also crashes if I use the "print" function: (Screenshot provided by my friend)

%%[ ProductName: Distiller ]%%
%%[ Error: undefinedresource; OffendingCommand: findresource ]%%

Stack:
/CIDFont
/SourceHanSerif-Bold
{--pop-- 4 --index-- --add--}
/SourceHanSerif-Bold-hf
/WinCharSetFFFF-H
/SourceHanSerif-BoldH

%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
%%[ Warning: PostScript error. No PDF file produced. ] %%

[kenlunde]

There are similar LibreOffice issues posted in the Source Han Sans project, all of which point to LibreOffice issues. If the behavior is different than Source Han Sans, then it is probably due to LibreOffice not being able to deal with the style-linking that is present in Source Han Serif, which links Regular to Bold. If fontconfig is used by LibreOffice, the Bold weight needs to be specified as the "Bold" style of the Regular weight, and not by explicit name.

[dantmnf]

@m13253 I found Adobe PDF printer won't work with OTC version font (in both LibreOffice and Microsoft Word), seems it's not the same issue.

[m13253]

I'm trying to figure out the cause of this problem and trying different font weights. But I'm getting weird results: different PDF viewers are having different results. At least I'm now sure the problem is related to specific font weight settings. I will take notes here.

Original document:

Rendered with "evince" (Gnome PDF viewer, the default viewer for many Linux):

Rendered with PDF.js (seems it falls back to my default sans-serif font, Source Han Sans):

Rendered with Chrome PDF viewer:

For reference, here are the files: Untitled 1.docx Untitled 1.pdf

The version I'm currently installing is "language-specific OTF". I can confirm the problem on both OTF and SuperOTC versions.

[miguelsousa]

@m13253 some of your screenshots suggest to me that the library that LibreOffice uses for generating PDFs does not fully support CID-keyed fonts.

I have no idea if LibreOffice uses Nodebox, but this issue might be useful for the LibreOffice developer that plans to look into the problem https://github.com/nodebox/opentype.js/issues/132

[kenlunde]

Another useful datapoint is whether Source Han Sans and Source Han Serif exhibit different behavior.

[m13253]

Bug cross-posted on https://bugs.documentfoundation.org/show_bug.cgi?id=107056

[khaledhosny]

LibreOffice does not support embedding CFF fonts in PDF, it converts them to Type1 fonts, any chance that there is something uncommon in Source Han fonts that would potentially affect such conversion?

[kenlunde]

@khaledhosny: You wrote:

…any chance that there is something uncommon in Source Han fonts that would potentially affect such conversion?

Yes, their size.

[khaledhosny]

I thought about that, but they are subset as well so shouldn’t be a problem when only a few characters are used like the samples here.

[khaledhosny]

BTW, the reason pdf.js is showing fallback fonts is because OTS is rejecting the fonts pdf.js is generating for bad CharString data.

[kenlunde]

The source (original) fonts are not rejected by OTS, so the conversion process must be corrupting the data. Another possibility is the CFF size, not in terms of number of glyphs, but the number of bytes.

[miguelsousa]

@khaledhosny a CFF-to-Type1 converter will need to be aware that CID-keyed fonts (the "flavor" of CFF commonly used for CJK fonts) can have multiple hint dictionaries (FDArray) and that subroutines are stored and accessed differently. See Adobe Tech Note #5014 circa page 30 for a general overview.

[khaledhosny]

A quick look at the code shows there is some support for CID-keyed fonts, also the glyphs of the light font are fine so might be something different. Anyway it is clearly a LibreOffice bug, will try to debug it if I got some time. Thanks for the helpful pointers.

[KrasnayaPloshchad]

LibreOffice does not support embedding CFF fonts in PDF, it converts them to Type1 fonts,

Is it possible to give LibreOffice an ability to embedded OT-CFF fonts directly in PDF?

[KrasnayaPloshchad]

LibreOffice 6.01 seems fixed it.

[KrasnayaPloshchad]

LibreOffice Chinese Community (LibreOffice 中文社区, http://www.libreofficechina.org/) also reported LibreOffice 5.4.5 fixed it too.