LibreOffice Writer crash when export to PDF file using source-han-sans font

[hubutui]

I'm not sure if here is the right place to report it, but I think I should report it. I also report a bug to LibreOffice, see https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81544 for detail.

When I use source-han-sans font in LibreOffice Writer, and export to PDF file, Writer closed immediately. The PDF file did not generated successful.

[cwchien]

I also found this issue, may be useful.

Bug 81516 - PDF: export crash when Source Han Sans CJK (OTF) font applied https://bugs.freedesktop.org/show_bug.cgi?id=81516

[ShikiSuen]

I also found this issue triggered by Noto Sans CJK series.

Tested Platform: OS X Yosemite DP3 + Most Recent Libre Office 64bit.

[kenlunde]

This is the first report of a PDF export issue with Source Han Sans. (Source Han Sans and Noto Sans CJK are identical in every way except in their names, meaning that any issue that affects one font family affects both font families.)

While I do not use LibreOffice Write, I can suggest that the first thing to do is to check whether its PDF-producing libraries simply cannot handle a font with glyphs that exceed a particular threshold. If you found this bug by using the multilingual OTFs, which have 65,535 glyphs, please try one or more of the subset OTFs, all of which have less than 32K glyphs.

In any case, I will close this issue, at least for now, but will leave it as "to track," because the bug clearly seems to be in LibreOffice Writer's PDF-producing capability.

[ShikiSuen]

@kenlunde I am using the subset of what you said and had found this issue like what I said in this thread.

[cwchien]

@kenlunde I also tried Source Han Sans TWHK/CN/JP/KR, it crashed even only one subset used.

However, "Droid Sans Fallback" with over 43K glyphs works fine with PDF exporting. (the number of glyphs is from http://www.droidfonts.com/droidfonts/)

[kenlunde]

The issue is thus not related to the number of glyphs, and something else is triggering it. At this point, I consider this issue to be in the hands of the LibreOffice Write folks unless they can point to a specific bug in these fonts. Keep in mind that these fonts push various implementation limits, though the region-specific subset OTFs do so to a lesser degree.

[audreyt]

LibreOffice Impress suffers from the same bug.

I've supplied a working patch at https://bugs.freedesktop.org/show_bug.cgi?id=81516#c14 (along with test cases). Thanks to @jimyhuang for bringing this to my attention. :+1:

[kenlunde]

I am glad to see that the bug has been found, but there seems to be some confusion about the proper fix. I don't have a login on bugs.freedesktop.org, so if someone (@audreyt) can post the following on my behalf, that would be helpful:

Source Han Sans (and thus Noto Sans CJK) include 19 FDArray elements. The maximum number of FDArray elements is 256. For testing fodder, please grab one or most fonts that are provided in the following CJK Type Blog article that I published over two years ago: http://blogs.adobe.com/CCJKType/2012/05/all-unicode-cfr.html

Thanks.

[audreyt]

Posted as of https://bugs.freedesktop.org/show_bug.cgi?id=81516#c16 — Thanks a lot for the clarification and for pushing the limits! :speedboat:

[kenlunde]

Perfect. Thanks! ☺

[audreyt]

LibreOffice team has deemed the patch hotfix-worthy and so will be part of LibreOffice 4.2.7, 4.3.1, as well as http://dev-builds.libreoffice.org/daily/ in the next 24~48 hours. Thanks to all involved!

[kenlunde]

Excellent. I like good news such as this. In case OpenOffice is using the same library, a similar bug reported against the Google-branded Noto Sans CJK should also get fixed: https://code.google.com/p/noto/issues/detail?id=76

[audreyt]

Sure. It's now tracked at https://issues.apache.org/ooo/show_bug.cgi?id=125359 — hopefully OpenOffice will merge it soon.