Bug 688688

Summary:	/rangecheck in --string--
Product:	Ghostscript	Reporter:	Tor Andersson <tor.andersson>
Component:	PDF Interpreter	Assignee:	Alex Cherepanov <alex>
Status:	NOTIFIED FIXED
Severity:	normal
Priority:	P2
Version:	master
Hardware:	Macintosh
OS:	MacOS X
Customer:	562	Word Size:	---
Attachments:	patch

Description Tor Andersson 2006-05-04 04:31:18 UTC

Looks like another font-related bug.

The sample pdf looks very similar to the ones in bug 688669, but
the error message is different.

Error: /rangecheck in --string--
Operand stack:
   --dict:7/7(L)--   F11   1   --dict:6/6(L)--   --dict:6/6(L)--   WKELFT+HYGoThic-Medium   --dict:11/12
(ro)(G)--   --nostringval--   --dict:7/7(L)--   --dict:7/7(L)--   9383   --dict:7/7(L)--   --nostringval--   
102036   102036

Comment 1 Tor Andersson 2006-05-04 04:31:50 UTC

Created attachment 2187 [details]
svc_12

Comment 2 Alex Cherepanov 2006-05-09 19:58:39 UTC

cmap table in a Korean font exceeds 64 K limit.
Reading the cmap table as a big table helps but the rest of the ttf
interpreter seems to assume that cmap is a short. Perhaps, this code is
not exercised in this case.

Comment 3 Alex Cherepanov 2006-07-04 17:39:32 UTC

Created attachment 2324 [details]
patch

Modify cmap table handling routines to support a large ( >= 64K ) table
represented as an array of strings.

DIFFERENCES:
Testing now.

Comment 4 Alex Cherepanov 2006-07-05 12:18:01 UTC

No difference is expected in the regression testing

Local testing shows the following insignificant differences:
409-01.ps - different order of file enumeration in .svn directory 
            reflected in the raster
215-01.ps - different order of file enumeration in stdout only
Bug687615.ps - different order of dictionary enumeration in stdout only.
Multiple differences in generated PDF files in Type1C streams.

Comment 5 leonardo 2006-07-05 14:13:21 UTC

Reviewing the patch 2324, I've got a question : isn't it simple to replace the 
string with a stream based on SubFileDecode ?

Comment 6 leonardo 2006-07-05 14:15:31 UTC

Are you sure that comment #4 is correct ? It looks same as for bug 688744, and 
I wonder why so.

Comment 7 Alex Cherepanov 2006-07-05 14:31:07 UTC

> I've got a question : isn't it simple to replace the string with a stream
> based on SubFileDecode ?
I spent a day trying to use /SubFileDecode but didn't succeed.
For instance, the file doesn't support "getinterval" operation and
requires copying. Positioning the file before every reading is not attractive
but changing the logic to reduce seeking is hard.

Yes, the differences are the same as before.

Comment 8 Ray Johnston 2006-07-05 15:03:38 UTC

I think the patch is acceptable. Please commit.

Comment 9 Alex Cherepanov 2006-07-05 17:29:41 UTC

The patch is committed as revision 6896.