Apache OpenOffice (AOO) Bugzilla – Issue 125359
PDF Export crashes for Source Han Sans / Noto CJK fonts
Last modified: 2022-10-28 12:54:33 UTC
Created attachment 83778 [details] Patch to cff.cxx Steps to reproduce: 1. Download and install Source Han Sans: http://sourceforge.net/adobe/source-han-sans/wiki/Home/ Or: Noto T Chinese / Noto S Chinese / Noto Japanese from: http://www.google.com/get/noto/ They are the same font. 2. New Writer or Impress file, type in any text, and apply the above font from font dropdown list. 3. Export to PDF. --> Crashes. The attached patch fixes this issue as explained by @kenlunde, main coordinator of Source Han Sans CJK at https://github.com/adobe-fonts/source-han-sans/issues/27#issuecomment-51055950 : 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 @kenlunde published over two years ago: http://blogs.adobe.com/CCJKType/2012/05/all-unicode-cfr.html The same patch has been vetted and applied as a hot-fix in LibreOffice at https://bugs.freedesktop.org/show_bug.cgi?id=81516#c14 . As for copyright status of the patch, here is my standard disclaimer: To the extent possible under law, I waive all copyright and related or neighboring rights to my past & future contributions to OpenOffice. http://creativecommons.org/publicdomain/zero/1.0 Cheers, Audrey
Created attachment 83779 [details] GDB backtrace
Already reproducible with 3.3.
I just kind-of duplicated this bug as #128392. Please merge this patch into 4-devel branches!
*** Issue 128392 has been marked as a duplicate of this issue. ***
Patch was committed to trunk in 2016: https://github.com/apache/openoffice/commit/30928f5456b84e4f631e6ab589da3fe977b55cd5
Thank you Matthias for your quick reply to bug #128392 ! I checked out branch AOO418 and the patch does not seem to have been integrated there. Apparently, it is also missing from branch AOO420. Am I looking in the wrong places? I just want to point out that this patch must absolutely (IMHO of course) be integrated into next release.
I apologize, I was wrong about branch AOO42X. The patch is there. Sorry for the noise. So, please, have it included into AOO418, if a release 4.1.8 is going to be published.
Yes, it is in AOO42X https://github.com/apache/openoffice/commits/AOO42X/main/vcl/source/fontsubset/cff.cxx I plan to cherry-pick it for AOO418 now.
Cherry-picked to AOO418 now: https://github.com/apache/openoffice/commit/971776bc74f50cdd618873d0419126920f937128 Thank you for the reminder! It would be great if you could test if that fixes your problem.
Thank you very much Matthias, it works! I understand that this patch consists of changing a somewhat-small fixed array into a somewhat-big fixed array. To me, this looks like a possible waste of memory, mostly due the fact that many people probably never bumped into this problem. Do you think it would be worth the effort to change that fixed array into a variable-sized one? I would be available to make a patch, but please tell me: 1- if it is worth this extra effort, 2- how I should implement it, to be consistent with OpenOffice's coding standards: - std::vector? - new[] and delete[]? - malloc(), realloc() and free()? - ...?
Hi Arrigo Marchiori Please see the Wiki entry here: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Improvement We want to remove all c-arrays over time. Currently no volunteer looking into this. A patch is welcome. However we prefer a pull request on github. We are still bound by C++ std GNU98, due to set supported Operating Sysytems. But it is a good thing to go for modern Programming style as much as possible. please use std::vector. If you can avoid new and delete, please do so.
Just opened PR #89: https://github.com/apache/openoffice/pull/89 I hope it helps.
(In reply to Arrigo Marchiori from comment #12) > Just opened PR #89: https://github.com/apache/openoffice/pull/89 > > I hope it helps. Thanks! Someone more knowledgeable than me will have a look. According to comment 10, I will close this issue as resolved. Looking forward for a more elegant solution.