Bug 691057

Summary: Unfixed Font resource size returned by resourcestatus operator
Product: Ghostscript Reporter: Masaki Ushizaka <masaki.ushizaka>
Component: ResourceAssignee: Alex Cherepanov <alex>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P4    
Version: master   
Hardware: All   
OS: All   
Customer: Word Size: ---
Attachments: patch

Description Masaki Ushizaka 2010-01-13 23:07:17 UTC 
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 &#64257;le can contain header comments, as speci&#64257;ed in Adobe Technical 
Note #5001, PostScript Language Document Structuring Conventions Speci&#64257;cation. 
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.
Comment 1 Ken Sharp 2010-01-14 01:53:20 UTC 
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.
Comment 2 Masaki Ushizaka 2010-01-14 04:11:12 UTC 
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.
Comment 3 Marcos H. Woehrmann 2010-01-14 09:38:15 UTC 
Alex, Henry suggests the workaround in gs_cet.ps as Ken mentioned in Comment #1.
Comment 4 Alex Cherepanov 2010-01-31 15:37:16 UTC 
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.
Comment 5 Alex Cherepanov 2010-01-31 16:05:37 UTC 
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.