[tex-k] dvips: BeginPaperSize in postscript DSC

[pierre.mackay]

Jean-François Mertens wrote:
> 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
>
>
> _______________________________________________
> tex-k at tug.org
> http://tug.org/mailman/listinfo/tex-k
>
>   
In practice, and after some experimentation, I believe that Ghostscript 
handles all the 3.0 comments correctly.  I am not
in a position to do any systematic evaluation of PostScript 3.0 
operation codes. 

I do not think it a good idea to introduce %%PageMedia, and to continue 
with %%DocumentPaperSizes.  These are comments
belonging to two different worlds.  If a config.ps file uses the 
"PaperSizes" convention, it should use it consistently, and if such
a file advances to the "PageMedia" convention, it should similarly, 
retain consistency, and use "Media" throughout.

Mr. Mertens raises a legitimate question, but it is out of our control.  
Documents in Computer Modern exclusively can hope
to be absolutely archival but, I suspect, only if they abjure the use of 
type1 fonts altogether.  Documents in New Times Roman, or
any other proprietary font, can pray, and perhaps hope, to be archival 
in the sense that Knuth intended, but they are at the
mercy of commercial taste. 

I made a survey of the set widths of "Times Roman" from various 
foundries some years ago, and the
differences are enough to change a fifty-page document into a forty-nine 
page document.  Times Roman has become a progressively tighter font over 
the last 5 decades, so that I have to letter-space it by 1/36 em to 
retain the visual appearance of older documents.
The pinching of other fonts is even more extreme.  Apparently, paper 
costs have led printers to feel that seriously decreased legibility
is an acceptable price to pay if they can reduce page counts by 2%.  
This trend began a long time ago with Jan Tschichold,, but it is
worth remembering that when Typographische Gestaltung was translated 
into English, 30 years after it was first written, Tschichold
abandoned narrow cramped sans-serif fonts for Bembo. 

We are at the mercy of font styles, unless we use only those fonts that 
we can generate ourselves.  I was puzzled many years ago to discover in 
reading the PostScript output from my upgraded LaserWriter that what I 
thought was Times was really BitStream Dutch-801-ASW.  The  ASW was for 
Adobe Set Width, so far as I have been able to learn.  It was a close 
match to Linotype or Monotype Times, but over 200 pages, it would not 
have been archivally consistent. 

I don't see what we can do about this but stick to our own knitting---or 
is it weaving.  I use Baskerville (Monotype cut), Caledonia and,
whenever I get the chance, Centaur, but I do not hope that they will be 
absolutely consistent over time.  For that we would have to go back to 
lead, and to hoard our own matrices. 

Pierre MacKay