Created attachment 11060 [details] Sample file This sample fails with /invalidaccess on GS but works on other interpreters. Fortunately, I no longer need to decide whether it is OK to update a read-only resource dictionary and what should be done about it.
I don't see that this is a 'broken type 16 halftone'. It seems that we simply don't permit the redefinition of the /Default named Halftone resource. If you rename the resource in the PostScript file to something other than /Default it seems to work perfectly well (at least it does not provoke an error). invalidaccess is a permissible error from defineresource, so to me this looks like reasonable behaviour. It may not be the same as other interpreters but its not obviously incorrect from my reading of the spec. Its also clearly a hand crafted PostScript file, so it doesn't appear that this is being produced by applications, which we might need to worry about.
Created attachment 13270 [details] patch If the halftone dictionary was defined as a resource, it became read-only. Slurping the threshold data at sethalftone need to update the /Thresholds entry and requires forced access to the dictionary.
(In reply to Peter Cherepanov from comment #2) > If the halftone dictionary was defined as a resource, it became read-only. Yes, this was Alex's point in comment #0, whether its valid to update a read-only resource dictionary. > Slurping the threshold data at sethalftone need to update the /Thresholds > entry and requires forced access to the dictionary. I'm still unconvinced that random PostScript should even be able to alter the /Default halftone. Doing that on a real physical printer could result in very poor quality output. I'm reluctant to add yet more code which overrides a specific read-only attribute, especially when the correct way to deal with this is to alter the /Default halftone in the resource. On the other hand, setting the /Default halftone to a type 1 (for example) will work, so other types ought to as well. Or at least, we should be consistent.
The problem is not limited to the /Default halftone. The following program also fails with the same error. /AAA << /HalftoneType 16 ..... >> /Halftone defineresource pop /AAA /Halftone findresource sethalftone And changing the default halftone is the only way to ensure that the halftone survives "showpage". It is a documented and a well known way to control PS interpreter. At least, an OEM should be able to do this without restrictions.
(In reply to Alex Cherepanov from comment #4) > And changing the default halftone is the only way to ensure that the > halftone survives "showpage". It is a documented and a well known way to > control PS interpreter. At least, an OEM should be able to do this without > restrictions. Yes but an OEM can do so by modifying the resources. That's rather the point I was trying to make. If an OEM carefully tunes a good halftone, they might be annoyed if random PostScript simply overrode it without good reason. (and there's an awful lot of terrible cargo cult programming goes on in the PostScript world, I have no doubt many programs generate such PostScript without need already) Obviously there needs to be the ability to override the current (default) halftone, but that does not imply the ability to alter the *Default* halftone. If you want to override the halftone for each page, then emit it for each page. I'm still considering this, it won't likely be altered for some time.
Ken, what do you think about changing the /Thresholds entry into an one-element array? When the dictionary is marked read-only, the array remains writable and can be patched later.
(In reply to Peter Cherepanov from comment #6) > Ken, what do you think about changing the /Thresholds entry into an > one-element array? When the dictionary is marked read-only, the array > remains writable and can be patched later. But that wouldn't address other problems such as the one Alex points out in comment #4. Also the PLRM states that the Thresholds entry in a type 16 halftone dictionary is a file object.
Can somebody explain the purpose of this code proposed for deletion? This bug won't occur if the dictionary is not updated. The only other difference I can imagine is making the file different for --eq-- , but I don't see such comparisons in in the code base. diff --git a/Resource/Init/gs_ll3.ps b/Resource/Init/gs_ll3.ps index e2bffba..ee184a9 100644 --- a/Resource/Init/gs_ll3.ps +++ b/Resource/Init/gs_ll3.ps @@ -102,11 +102,6 @@ currentdict /.bind_ undef not { /sethalftone .systemvar /rangecheck signalerror exit } if readonly /Thresholds exch def /TransferFunction .knownget { /TransferFunction exch def } if - % If the original Thresholds was a file, replace it with - % a new one. - dup /Thresholds get type /filetype eq { - dup /Thresholds [ Thresholds ] cvx 0 () .subfiledecode put - } if mark /HalftoneType 5 /Default currentdict end .dicttomark { .sethalftone5 } } bind def
Its been a long time since this was last looked at, and nobody has complained since. I think its time to admit we're not going to alter this without an example from a mainstream application, or a request from a customer.