On Nov 7, 2006, at 9:33 AM, Jean-Fran=E7ois Mertens wrote:
> Dear Jens,
>
> Thanks a lot !
> You're a wonderful maintainer !
> [would suggest you send this as bug-report to gs
> _ or to gs and dvips, and let them discuss the issue
> between themselves...]
>
>
> On 07 Nov 2006, at 05:43, Jens Noeckel wrote:
>>
>> On Nov 6, 2006, at 8:59 AM, Jean-Fran=E7ois Mertens wrote:
>>
>>> Hi,
>>>
>>> Sorry if this is not fink-specific _ but I'd like to check first if
>>> other users can reproduce the problem...
>>>
>>> Given my (dvips) config.ps, a typical .ps file here specifies twice
>>> A4 paper :
>>> %%DocumentPaperSizes: a4
>>> (in the initial comments) , and
>>> %%PaperSize: A4
>>> (in the final Setup)
>>>
>>> Yet when using ps2pdf (or ps2pdf14) on that file, the resulting .pdf
>>> contains
>>> for each page :
>>> <</Type/Page/MediaBox [0 0 612 792]
>>> ie, specifies letter paper
>>>
>>> I can"fix" this by un-commenting the line
>>> /DEFAULTPAPERSIZE (a4) def
>>> in /sw/share/ghostscript/8.54/lib/gs_init.ps, but this should NOT be
>>> necessary:
>>> the ghostscript documentation ( file:///sw/share/ghostscript/8.54/
>>> doc/
>>> Use.htm#Paper_size ) specifies :
>>> "Individual documents can (and often do) specify a paper size, which
>>> takes precedence over the default size. "
>>>
>>> JF Mertens
>>
>> Hi JF,
>>
>> I can confirm this with a ps file generated from a minimal latex
>> [a4paper]{article} using dvips. But for me the same behavior
>> results when I use pstopdf (Apple's built-in converter) instead of
>> ps2pdf. Moreover, this does _not_ happen if I produce a minimal ps
>> file using Adobe Illustrator, or by printing to a file from Camino
>> (after choosing A4 as the Page format).
>>
>> So I think it must be blamed squarely on dvips. I can make dvips
>> behave correctly by giving it the explicit command line option "-t
>> a4". Here is the diff between the ps files produced without and
>> with that flag:
>>
>> < %DVIPSCommandLine: dvips -o new2.ps newfile1
>> ---
>>> %DVIPSCommandLine: dvips -o new1.ps -t a4 newfile1
>> 273c273,275
>> < %%PaperSize: A4
>> ---
>>> %%BeginPaperSize: a4
>>> a4
>>> %%EndPaperSize
>>
>> The file "new1.ps" has the correct dimensions in Preview (i.e.,
>> after PDF conversion), the file "new2.ps" doesn't. The reason for
>> this discrepancy is probably due to the fact that dvips thinks it's
>> sending stuff to a printer, and different printers expect different
>> syntax.
>> Here is a page I found on this:
>> http://www.tug.org/texinfohtml/dvips.html
> (or `pinfo dvips` ...)
>>
>> What it boils down to is that we want dvips to write a ps file that
>> obeys the "right" syntax - Quoting:
>>
>> "Virtually all of the PostScript commands you use here are device-
>> dependent and degrade the portability of the file; that is why the
>> default first paper size entry should not send any PostScript
>> commands down (although a structured comment or two would be okay).
>> Also, some printers want `BeginPaperSize' comments and paper size
>> setting commands; others (such as the NeXT) want `PaperSize'
>> comments and they will handle setting the paper size. There is no
>> solution I could find that works for both (except maybe specifying
>> both)."
>>
>> For purposes of processing by ps2pdf, we apparently want the syntax
>> with "BeginPaperSize: a4", not the other one. So we have to tell
>> dvips to do that. I guess it could be put into the configuration
>> file (e.g., ~/.dvipsrc)
> or config.ps _ just put the 'a4' entry on top ( or a line with just a
> "@" right above it).
>> using the commands in section 4.2. of the above reference,
>> "Configuration file paper size command".
>
> Not sure I agree with your conclusion; a bit further the same info
> page is even more explicit :
> "Executing the `letter' or `a4' or other PostScript operators cause
> the document to be nonconforming and can cause it not to print on
> certain printers, so the default paper size should not execute such an
> operator if at all possible."
>
> dvips is very careful to write conforming PS (and the other examples
> you mention are probably less so,
> maybe because they are designed to work in a more specific =20
> environment).
> And, for gs, even without the above quote from their doc, you would
> expect it to respect
> the PaperSize comments in the source... (and not only non-conforming
> PS code like "a4" or "letter").
>
> Jean-Francois
>
Jean-Francois,
you're right, this should be a bug report. But I'm sticking with my =20
claim that it's a dvips bug. Looking at the Postscript specifications =20=
on Adobe's website, it's quite clear that _both_ of the ways dvips =20
tries to specify paper sizes are incorrect. The correct way since =20
1992 (!) is given in Appendix A of the document "PostScript Language =20
Document Structuring Conventions Specification" at
http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf
Discontinued Comments For Version 3.0
%%BeginPaperSize:
%%EndPaperSize
The comments %%BeginFeature: and %%EndFeature should be substituted.
So dvips is way behind in its implementation of the proper DSC =20
comments for page size information. I've sent an email about this to =20
the tex-k@... mailing list.
Regards,
Jens
|
