[tex-k] dvips: BeginPaperSize in postscript DSC

[Jean-François Mertens]

On 14 Nov 2006, at 11:58, pierre.mackay wrote:

> Karl Berry wrote:
>>     All that is needed is to add an explicit PageMedia comment  
>> after each of     the specific  @+ ! %%DocumentPaperSizes: lines.
>>
>> It seems fine to me to add a %%PageMedia for each %% 
>> DocumentPaperSizes
>> entry in config.ps.  That seems like it can only help.  (Tom,  
>> unless you
>> see a problem with it, I will make that change.)
>>
>> We definitely want to solve the problem with Ghostscript.  So if/ 
>> since
>> the %%PageMedia does that, great.
>>
>> My concern is with replacing the %%BeginPaperSize...%%EndPaperSize  
>> with
>> %%BeginFeature...%%EndFeature.  I understand that [b/e]Feature is the
>> current way to do it, but who knows what still wants [b/e] 
>> PaperSize?  I
>> don't know, it just seems (probably needlessly) worrisome to me.
>> I also somehow doubt that it's desirable to put in both.
>> Hmm.
>>
>> Thanks,
>> Karl
>> _______________________________________________
>> tex-k at tug.org
>> http://tug.org/mailman/listinfo/tex-k
>>
>>
> Ghostscript seems to be no problem at all.  It is very permissive.   
> Of course, if one continues to run an outdated version of  
> Ghostscript it might go so far back that it could not understand %% 
> BeginFeature, but then, a backup version of config.ps would provide  
> %%BeginPaperSize.  At some time, the 3.0 Structuring Conventions  
> have to take precedence, just as LaTeX2e is elbowing out the old  
> LaTeX. The real problem is the !PS 2.0 vs PS 3.0 header, because  
> there is more to PS 3.0 than the format of Structuring Comments.

A )
Slightly more precisely maybe :
1) is correct ps code under PS2 (I mean, code produced by dvips)  
still correct ( apart from the comments mentioned)
under PS3 (and here I think we should mean it, formally so..)
I.e, is the only diff between PS2 and PS3 the addition of some more  
commands, or did existing commands (used by dvips) change meaning ?
2) I have always understood in this discussion level 2 and level 3 as  
referring at the same time to comments and the code itself.
But is this really correct, or are there just independent Adobe  
documents describing for some, changes in comments,
and for others, changes in the code?
3) Independently, would PS3 code be understood correctly by any  
reasonable output device by now ? (here I would of course guess yes
_ but who knows ?)

I'm very sorry we seem all to be in the same situation of  ignorance  
here _ people full of goodwill groping for a "correct" solution _,
and I would have hoped to get some input on this list from people who  
know a little bit of postscript...
(I once sent a bug report to Tom R., directly (and not that long  
ago), and he was extremely responsive
_ dvips was changed in a matter of weeks; maybe we should try another  
list, or him directly
_ trying to put him on cc...)
	If needed I'll try to study the documents, but a reply from someone  
who knows them already
(Pierre seems the better informed among us, but still uneasy like  
me...) would save a lot of time...

B)
Independently of the above, I'm worried that the bulk of all existing  
ps-documents (at least all those
produced by dvips ...) is no longer interpreted correctly by gs. It  
would seem a trivial matter for gs to
interpret "#!Adobe-PS-2.0" correctly.
It might seem helpful to write a joint bug-report to gs _ just asking  
them to interpret correctly the first line _.

> Adobe has done a not-too-bad job of maintaining backward  
> compatibility, but I am not sure that it is the responsibility of  
> the TeX
> community to guarantee that old PS documents will have the same  
> archival consistency that TeX source is supposed to have. I have to  
> take archival stability rather seriously, but I would not store PS  
> documents to achieve that.  I would store *.tex source, and rely on  
> the maintenance of trip-tested TeX engines.

I would have problems with that point of view : as soon as you have  
slightly complex documents _ using eg
both omega and pstricks, or other a bit specialised packages, you  
find out that even after a few years, they no longer run
_ so you would have had to save not only the source, but even the src  
of all binaries used at that time _ ie. basically save
the whole the whole relevant subtree (including probably ps fonts) of  
CTAN, and hope that it still compiles correctly
decades (or centuries , like paper documents do...) from now...
While emulating a few centuries from now a small HP calculator like  
postscript seems much less of a challenge _ and seems
something completely doable by gs
And the difference in the size to be saved is tremendous !
So I think it is important thar gs continues to recognize correctly  
the first line...

C) Possibly if we get in contact with them this way they might help  
us with precise answers to the problems sub A ...

Best,

JF Mertens