While searching the reason why PS3CET 23-33.PS generates different checksums machine by machine (bug #690650), I found that '/Font resourcestatus' operation returns different 'size' values for different occasions. ---Start test code: %! /Times-Roman findfont pop [/Times-Roman /Font resourcestatus] == ---End test code: Save above code as a file 'resourcesize.ps'. Mac OS X 10.5.8: $ bin/gs -dBATCH -sDEVICE=nullpage resourcesize.ps [1 930 true] $ bin/gs -dBATCH -sDEVICE=pdfwrite -o /dev/null resourcesize.ps [1 4258 true] $ Windows XP SP3: C>bin\gswin32c -dBATCH -sDEVICE=nullpage resourcesize.ps [1 1082 true] C> This is from PLRM3 3.9.4 Resources as Files: A resource file can contain header comments, as specified in Adobe Technical Note #5001, PostScript Language Document Structuring Conventions Specification. If there is a header comment of the form %%VMusage: int int then the resourcestatus operator returns the larger of the two integers as its size result. If the %%VMusage: comment is not present, resourcestatus may not be able to determine the VM consumption for the resource instance, in which case it will return a size of �|1. And also from Chapter 8, resourcestatus: Usually, resourcestatus can obtain the size of a status 1 or 2 resource (derived from the %%VMusage: comment in the resource file), but it has no general way to determine the size of a status 0 resource. See Section 3.9.4, �gResources as Files,�h for an explanation of how the size is determined. A size value of 0 is returned for implicit resources, whose instances do not occupy VM.
We don't appear to make any attempt to use the VMusage comment at all. When we define a status 0 (defined by explicit defineresource) or status 2 (not defined but available externally) resource we always assign its size to -1. However, when we define a status 1 resource (defined via findresource) we do a vmstatus before and after defining the resource, and use the difference in the vm used as the size of the resource. This can differ depending on the memory layout and possibly the word size (32 or 64 bit) which means that the answers can be different even on the same machine on different runs. Probably the only way to fix this is to have the vmstatus operator always return the same value, or alter our DefineResource procedure to define status 1 resources with a size of -1. Perhaps another hack in gs_cet.ps to redefine vmstatus to return a fixed value would suffice, though I don't know if Genoa test this to see if it changes.
CET 23-33.PS is just examining return value of 'resourcestatus' operator. If it returns -1, it will buy it. I may be little curious about why we designed DefineResource in Font category to do that way.
Alex, Henry suggests the workaround in gs_cet.ps as Ken mentioned in Comment #1.
Created attachment 5929 [details] patch Patch font resource category for CET testing to always return the font memory usage as unknown (-1) to avoid differences between hosts.
The patch has been committed as a rev. 10679. Regression testing shows no differences. I'll return 23-33.PS to the regression test suite.