View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013787 | Scribus | Import / Export | public | 2016-03-02 20:51 | 2016-03-03 01:18 |
| Reporter | Jehan | Assigned To | jghali | ||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Product Version | 1.5.2.svn | ||||
| Summary | 0013787: PDF export crashes Scribus with some fonts embedded/subsetted | ||||
| Description | This issue was encountered on a real-life file which had several fonts. When trying to embed/subset them, Scribus crashed (not when outlining, or when not embedding). I have reproduced with a simpler test file (contains only a text frame with "Test." in it, cf. attached), and using the font "Noto Sans CJK TC". The original file had more fonts, and I have not tested them all to see if the crash would be reproduced with another of the fonts as well. I stopped at the first which crashed the export (some of them would not crash Scribus). | ||||
| Steps To Reproduce | - Get font "Noto Sans CJK TC". For instance downloadable here: https://github.com/googlei18n/noto-cjk/blob/master/NotoSansCJKtc-Regular.otf - Open the attached crashtest.sla with Scribus from svn. - Click "Save as PDF". - In fonts tab, make sure the embedding mode is "Embed or Subset". - Fonts can be in any of the embed or subset list, it does not matter. - Click "Save". Result: Scribus crashes with a popup "Scribus crashed due to Signal 0000006". The terminal has more information: --------------------------------------------------- ASSERT failure in QList<T>::operator[]: "index out of range", file /usr/include/qt5/QtCore/qlist.h, line 518 scribus: /home/jehan/dev/src/Scribus/scribus/scribuscore.cpp:88: void abort_on_error(QtMsgType, const QMessageLogContext&, const QString&): Assertion `false' failed. Scribus Crash ------------- Scribus crashes due to Signal 0000006 Calling Emergency Save --------------------------------------------------- | ||||
| Additional Information | Scribus from svn: r21046 This has been reproduced on 2 machines (the other was using a version barely older: r21043). Both machines were under Fedora 23, 64 bit. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
|
|
|
|
|
|
I looked a little more into this crash. So first I uploaded the backtrace of the crash (crash.bt). Second I localized where it crashes: In scribus/fonts/cff.cpp, there are a few lines where you try to get the value at id cff_dict_Private from a QMap<operator_type, CFF_Variant>. It seems that for some fonts, this value does not exist. Actually checking the QList size() on my example font "Noto Sans CJK TC", it was size 12. cff_dict_Private being 18, this is normal to end up "out of range". I tried at various places to add some: > if (m_fontTopDicts[fontName].contains(cff_dict_Private)) around these lines of code, since I saw you were doing so for other fields. The PDF successfully exported but the pieces of text with this font were not visible in the resulting PDF. So I assume that this is not that easy. :-) In the end I don't know the meaning of these various fields and why some font would have it or not. So I can't help much more than this. Also I can't make the time to continue investigating more unfortunately, so I will leave the rest to you. I hope this will be enough to debug, fix the crash and have these fonts usable as embedded/subset in Scribus (and not only outlined). :-) |
|
|
By the way, we used to be able to have some fonts embedded while others could be outlined. Now it seems to be all one or the other. Why did you remove the possibility to have both depending on the fonts? |
|
|
The meaning of "outline" is different in 1.5.0 and 1.5.1. In 1.5.0, "outline" was really meaning "subset as a Type 3 font". 1.5.1 can now export true CFF and TrueType subsets so using Type 3 subsets is not desirable anymore. The uses of Type 3 subsets also did not provide what some users wanted ie true conversion of text to paths. So in 1.5.1, "outline" means just that, full conversion of text to paths without any use of font in the final PDF. This way of exporting text respond to use case where you do not want any font to be present in the final PDF while being able to print reliably. Hence the different behavior in 1.5.1. |
|
|
Thanks for your work however this issue with Noto Sans is already known as 0013293. More generally I think this affect OpenType CID keyed fonts. For those fonts the cff_dict_Private key usually does not exist. However as you've seen this is not just a matter of testing if this key exists or not. Parsing CID-keyed fonts is just more complicated. Unfortunately the guy who really know that stuff is not available currently. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-03-02 20:51 | Jehan | New Issue | |
| 2016-03-02 20:51 | Jehan | File Added: crashtest.sla | |
| 2016-03-02 22:05 | Jehan | File Added: crash.bt | |
| 2016-03-02 22:19 | Jehan | Note Added: 0038954 | |
| 2016-03-02 22:22 | Jehan | Note Added: 0038955 | |
| 2016-03-03 01:08 | jghali | Note Added: 0038956 | |
| 2016-03-03 01:17 | jghali | Note Added: 0038957 | |
| 2016-03-03 01:17 | jghali | Relationship added | duplicate of 0013293 |
| 2016-03-03 01:17 | jghali | Status | new => resolved |
| 2016-03-03 01:17 | jghali | Resolution | open => duplicate |
| 2016-03-03 01:17 | jghali | Assigned To | => jghali |
| 2016-03-03 01:18 | jghali | Status | resolved => closed |
| 2016-03-27 22:39 | jghali | Relationship added | has duplicate 0013857 |
