When converting ( or viewing ) the attached PDF file sulzer.pdf to TIFFG4 ( or another format like Postscript ), you can see in the second and following pages, that letters are missing. The missing letters are shown as a little vertical lines. The file can be viewed and printed with the AcrobatReader correctly. The Ghostscript will show some warnings like: **** Warning: File has imbalanced q/Q operators (too many q's) Page 2 **** Warning: File has imbalanced q/Q operators (too many q's) Page 3 **** Warning: File has imbalanced q/Q operators (too many q's) Page 4 **** Warning: File has imbalanced q/Q operators (too many q's) **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> CVISION Technologies <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification.
Created attachment 4424 [details] sulzer.pdf
Created attachment 4426 [details] i5.pdf -- simplified sample file
This is a problem in JBIG2 decoding. The simplified sample file contains a single encoded image. The bug is confirmed in the current development version.
Current gs (r9793) shows a blank page after throwing the following errors on the simplified file: jbig2dec FATAL ERROR decoding image: runlength too large in export symbol table (839 > 18 - 0) (segment 0x0a) **** Warning: File has insufficient data for an image. evince shows the image but reports: Error (524): 17259 extraneous bytes after segment (twice)
Reproduced with r9974 on Mac OS X 10.5.7 + Xcode 3.1.2. Same result as #4.
*** Bug 691206 has been marked as a duplicate of this bug. ***
*** Bug 691081 has been marked as a duplicate of this bug. ***
Merged bug 691081 and 691206 to this. I should also note that mupdf has a same problem as it uses jbig2dec too.
Created attachment 6155 [details] i5.jbig2.zip Extracted JBIG2 files from i5.pdf. Using these, I can reproduce this with following command: ./jbig2dec i5.global.jbig2 i5.page.jbig2
Started from r9769, the "runlength too large in export symbol table" problem was covering the original problem. A coming patch is fixing it and the original problem is going to visible again. I am delegating "runlength..." problem to 691081 and record dependency.
Created attachment 6157 [details] i5.jbig2dec.png "runlength..." problem was fixed in r11057, and it starts displaying original problem. This is a result from jbig2dec command. Some letters are missing, some are replaced with vertical lines. Command line used: ./jbig2dec i5.global.jbig2 i5.page.jbig2 (Then converted .pbm to .png)
Created attachment 6158 [details] i5.luratech.png Same file processed with luratech decoder.
Created attachment 6162 [details] A patch to fix missing/vertical line glyph problem This problem was in jbig2_decode_symbol_dict(). The image number was not incremented correctly when it built symbol dictionary. This small patch fixes it.
Patch looks good. Please commit.
The patch has been committed r11074. Closing this bug.
A change in r11074 caused segmentation fault by images with SDHUFF == 1. Reopening to fix.
As I changed image number to be incremented when 'exflag' is false, the problem of 'exrunlength' when SDHUFF == 1 was unveiled. The following patch deal with this. Index: jbig2dec/jbig2_symbol_dict.c =================================================================== --- jbig2dec/jbig2_symbol_dict.c (revision 11092) +++ jbig2dec/jbig2_symbol_dict.c (working copy) @@ -693,7 +693,7 @@ while (j < params->SDNUMEXSYMS) { if (params->SDHUFF) /* FIXME: implement reading from huff table B.1 */ - exrunlength = params->SDNUMEXSYMS; + exrunlength = exflag ? params->SDNUMEXSYMS : 0; else code = jbig2_arith_int_decode(IAEX, as, &exrunlength); if (exflag && exrunlength > params->SDNUMEXSYMS - j) {
The patch has been committed in r11093. Closing again.
Changing customer bugs that have been resolved more than a year ago to closed.