[tex-k] Fwd: dvips: BeginPaperSize in postscript DSC
jfm at core.ucl.ac.be
Wed Nov 15 06:14:38 CET 2006
Tom R. apparently forgot to "Reply-all". Forwarding.
Begin forwarded message:
> From: "Tom Rokicki" <rokicki at gmail.com>
> Date: Wed 15 Nov 2006 05:37:45 GMT+01:00
> To: "Jean-François Mertens" <jfm at core.ucl.ac.be>
> Subject: Re: [tex-k] dvips: BeginPaperSize in postscript DSC
> Return-Path: <rokicki at gmail.com>
> Delivered-To: jfm at core.ucl.ac.be
> Received: (qmail 18624 invoked from network); 15 Nov 2006 05:03:19
> Received: from 188.8.131.52 by minouche.core.ucl.ac.be (envelope-
> from <rokicki at gmail.com>, uid 201) with qmail-scanner-1.24-st-qms
> (spamassassin: 2.64. perlscan: 1.24-st-qms. Clear:RC:0
> (184.108.40.206):SA:0(-4.8/5.0):. Processed in 8.698934 secs); 15
> Nov 2006 05:03:19 -0000
> Received: from unknown (HELO nf-out-0910.google.com)
> (220.127.116.11) by pops1.core.ucl.ac.be with SMTP; 15 Nov 2006
> 05:03:10 -0000
> Received: by nf-out-0910.google.com with SMTP id c29so537091nfb for
> <jfm at core.ucl.ac.be>; Tue, 14 Nov 2006 21:03:08 -0800 (PST)
> Received: by 10.78.139.1 with SMTP id m1mr1866468hud.1163565465663;
> Tue, 14 Nov 2006 20:37:45 -0800 (PST)
> Received: by 10.78.133.9 with HTTP; Tue, 14 Nov 2006 20:37:45 -0800
> X-Spam-Status: No, hits=-4.8 required=5.0
> X-Envelope-From: rokicki at gmail.com
> Domainkey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;
> d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-
> <2b80cd370611142037v7e9d34d3xa770731e141f4987 at mail.gmail.com>
> In-Reply-To: <C17BFB53-4561-447D-ABBF-D04288A5CF78 at core.ucl.ac.be>
> Mime-Version: 1.0
> Content-Type: multipart/alternative; boundary="----
> References: <200611132312.kADNCTd02174 at f7.net> <4559A15B.
> 3010302 at comcast.net> <C17BFB53-4561-447D-ABBF-
> D04288A5CF78 at core.ucl.ac.be>
> X-Qmail-Scanner-Moved-X-Spam-Status: No, hits=-4.8 required=5.0
> tests=BAYES_00,HTML_MESSAGE autolearn=no version=2.64
> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
> Changing the %!PS header would probably require fairly nontrivial
> changes to
> a large number of places, including:
> - Included graphics DSC
> - Included font DSC
> - Binary sections of graphics
> - Header file DSC
> - and a bunch more.
> It may well be worth doing, but it will need to be done carefully.
> On 11/14/06, Jean-François Mertens < jfm at core.ucl.ac.be> 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
> who knows them already
> (Pierre seems the better informed among us, but still uneasy like
> me...) would save a lot of time...
> 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 ...
> JF Mertens
More information about the tex-k