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
Created attachment 2187 [details] svc_12
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.
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.
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.
Reviewing the patch 2324, I've got a question : isn't it simple to replace the string with a stream based on SubFileDecode ?
Are you sure that comment #4 is correct ? It looks same as for bug 688744, and I wonder why so.
> 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.
I think the patch is acceptable. Please commit.
The patch is committed as revision 6896.