The customer reports and I've verified that Ghostsript 9.04 and master as well as earlier versions render the attached PostScript file with the names of the states (e.g. Missouri) missing in the "Earthquake History of the Southeastern U.S." map in the lower left hand corner (see the attached screenshot.png). The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif -r300 ./EQ.PS Apple Preview and Adobe Acrobat Distiller both include the state names.
Type 3 font in the file has incorrect setcachedevice /C81 {1741 0 1237340 1237340 1638.33 1520.33 setcachedevice This bounding box excludes most of the glyph. Changing 1237340 into 0 makes the file render correctly. We need to decide how to detect an invalid glyph bounding box.
Could we install the bbox device "before" the cache device, run the BulidChar, and then compare the accumulated bounding box with the parameters from the setcachedevice? Then, if the former is (significantly) larger than the latter, rerun the BuildChar either uncached, or with the cache device using the accumulated bbox? I know it means special things for Type 3 fonts, but it's hard to see a reliable alternative.
(In reply to comment #5) > Could we install the bbox device "before" the cache device, run the BulidChar, > and then compare the accumulated bounding box with the parameters from the > setcachedevice? Then, if the former is (significantly) larger than the latter, > rerun the BuildChar either uncached, or with the cache device using the > accumulated bbox? > > I know it means special things for Type 3 fonts, but it's hard to see a > reliable alternative. Sounds like a performance penalty for type 3 fonts to me.....
Depending on how CPSI behaves: As discussed on IRC, a simpler/safer/quicker solution for this *class* of problem file would be a fairly simple sanity check on the parameters in set_cache_device() and if the bounding box numbers are nonsense, render uncached.
The bbox device wouldn't add very much performance penalty, and Type 3 fonts aren't very common, so IMHO, the performance hit wouldn't be a big deal. Now that I said that I expect one of our high priority customers to send us a file they complain is too slow, and we will find it is due to Type 3 ;-)
Ray can you tell us the CPSI results for this file.
Created attachment 8332 [details] CPSI_render_EQ-cut.pdf Results from CPSI. I hope it has all the info you need. There were no messages in the RIP log
Please update the bug status so I can let the customer know what progress we are making.
Created attachment 8347 [details] Simple patch Reject setcachedevice calls with large arguments. This is the easiest approach. It solves the problem and causes no significant differences on the cluster. A few sporadic differences are, probably, caused by indeterminism.
The patch has been committed as: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=77a8045048a4aaa727f700187816170d7fbd072c