The conversion of the file page13.pdf to PDF with following command: gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=out.pdf page13.pdf fails with error message: Error: /typecheck in --run-- Operand stack: --nostringval-- --dict:6/15(L)-- F12+1 3.84 --dict:10/19(L)-- --dict:10/19(L)-- --dict:12/16(ro)(L)-- --nostringval-- --dict:10/19(L)-- --dict:12/16(ro)(L)-- --nostringval-- 68713 --nostringval-- CMapName Execution stack:
Created attachment 4015 [details] page13.pdf
An CMap stream in the sample file has a name that starts with 2 slash characters but should not be parsed as an immediately evaluated name. So it's an PDF interpreter issue.
Sounds like a job for PDFScanRules
Use PDFScanRules to scan ToUnicode CMap. Fix a case where CMap stream has a name starting with 2 slashes that should not be parsed as an immediately evaluated name. The following patch is committed as a rev. 8742. http://ghostscript.com/pipermail/gs-cvs/2008-May/008321.html Regression testing shows no differences.
Restoring the accidentally changed priority.
I activated the patch ( rev. 8742 ), but the behaviour does not change ! The conversion of the file page13.pdf still fails.
I confirm that the patch doesn't fix the bug. It just replaces one error with another error. To fix this bug we need a streamlined parser that searches for keywords in the CMap stream and ignores most of PostScript syntax. This is what Acrobat Reader does. Removing of all def operators from CMap or replacing them with random junk leaves the CMap readable for Acrobat Reader.
*** Bug 690114 has been marked as a duplicate of this bug. ***
Skip everything before 'begincodespacerange' in ToUnicode CMap stream to avoid PostScript errors in CMap headers. PDF interpreter doesn't need any data from the header. Bug 689842, customer 870. Local testing shows no raster differences. Ghostscript no longer detects and reports any errors in the CMap header. The following patch is committed as a rev. 9240 http://ghostscript.com/pipermail/gs-cvs/2008-November/008819.html