Created attachment 6301 [details] Order document from ERP system. Generated using Versy pdf tool. Conversion fails. #> gs -q -sPAPERSIZE=a4 -dBATCH -dNOPAUSE -sDEVICE=pswrite -sOutputFile=/tmp/test.ps 20100428_160627_Ordre605055.PDF Error: /limitcheck in --run-- Operand stack: --dict:6/15(L)-- Fnt1 1 FontObject --dict:9/18(L)-- --dict:9/18(L)-- 58385 --dict:9/18(L)-- --nostringval-- --dict:216/256(L)-- --dict:65534/65534(L)-- 65609 32 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 4 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- 10 2 31 --nostringval-- %for_pos_int_continue 33 1 39 --nostringval-- %for_pos_int_continue --nostringval-- Dictionary stack: --dict:1156/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:108/127(ro)(G)-- --dict:290/300(ro)(G)-- --dict:23/25(L)-- --dict:6/8(L)-- --dict:27/40(L)-- --dict:40/50(ro)(G)-- --dict:50/80(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 8.71: Unrecoverable error, exit code 1 On 8.62 it gives a different error: gs -q -sPAPERSIZE=a4 -dBATCH -dNOPAUSE -sDEVICE=pswrite -sOutputFile=/tmp/test.ps 20100428_160627_Ordre605055.PDF Error: /rangecheck in --run-- Operand stack: --nostringval-- --dict:6/15(L)-- Fnt1 1 --dict:9/18(L)-- --dict:9/18(L)-- 58385 --dict:9/18(L)-- --nostringval-- --dict:216/256(L)-- --nostringval-- 8212 8182 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 4 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- 2 2 31 --nostringval-- %for_pos_int_continue 8183 1 65506 --nostringval-- %for_pos_int_continue --nostringval-- Dictionary stack: --dict:1153/1684(ro)(G)-- --dict:1/20(G)-- --dict:97/200(L)-- --dict:97/200(L)-- --dict:108/127(ro)(G)-- --dict:275/300(ro)(G)-- --dict:23/25(L)-- --dict:4/6(L)-- --dict:27/40(L)-- --dict:40/50(ro)(G)-- --dict:50/80(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 8.62: Unrecoverable error, exit code 1
Created attachment 6302 [details] possible patch The problem is caused by a TrueType font with what appears (to me) to be an invalid CMAP subtable. Decoding the CMAP subtable gives: Binary data meaning ------------------------------- 00 00 version 00 02 Number subTables table 1 00 01 platformID 00 00 platformSpecificID 00 00 00 14 Offset table 2 00 03 platformID 00 01 platformSpecificID 00 00 01 1A Offset mapping table 1 00 00 format 01 06 length of subtable 00 00 language .... 256 bytes omitted mapping table 2 00 04 format 01 30 length of subtable 00 00 language 00 22 segCountX2 00 22 searchRange 00 02 entrySelector 00 00 rangeShift 00 00 endCode[segment 1] 00 26 endCode[segment 2] 00 2A ... 00 3A 00 50 00 57 00 70 00 79 00 B2 00 C5 00 C6 00 D8 00 E5 00 E6 00 F8 20 13 FF FF endCOde[segment 17] 00 00 reservedPad 00 20 startCode[segment 1] 00 25 startCode[segment 2] 00 28 The problem is that segment 1 has an end code of 0, and a start code of 32. The specification doesn't make any mention of a special meaning for this, and indeed the documented method for using the arrays seems like it wouldn't work properly in this case: "To use these arrays, it is necessary to search for the first endCode that is greater than or equal to the character code to be mapped. If the corresponding startCode is less than or equal to the character code, then use...." If the endCode is 0 then it seems to me that a strict application of this rule would never match a code in this range. Acrobat is happy with the font, but it could be that it is using the format 0 subtable. The ttfdump utility, however, also does not complain and simply substitutes an endCode equal to the startCode. The Microsoft Font Validator tool does give an error that the startCode is greater than the endCode. The attached patch simply sets the end code to be the same as the start code if it is smaller. This works for the attached file, but please note that the bug is actually in the font embedded in the PDF file. I'll leave it to Alex to decide if there's a better way to achieve this.
Created attachment 6303 [details] patch Ignore cmap entry that has endCode < startCode. According to the spec, "to use these arrays, it is necessary to search for the first endCode that is greater than or equal to the character code to be mapped. If the corresponding startCode is less than or equal to the character code ...". I.e. an entry with endCode < startCode has no effect. Bug 691326.
(In reply to comment #2) Cool. Thanks. I had some trouble applying the patch - I can't find rev. 11270 anywhere. Instead I edited the file by hand and the conversion succeded without errors. However, looking at the output, there seems to some problem with tab. Looking at the top of the document, all the address lines are mashed together on the left side. I tried both the gs_ttf.ps from the 8.71 debian package (r10577) and the one from trunk (r11116).
Ken's patch is committed as a rev. 11299. The patch matches observed behavior of Adobe Acrobat.
(In reply to comment #4) > Ken's patch is committed as a rev. 11299. > The patch matches observed behavior of Adobe Acrobat. Yes. Checked out from trunk (r11305) and build package. Output is correct. The document must have been affected by another (fixed) bug or something. Should have checked that before posting previous comment. Sorry for the inconvenience.