| In my "extensive" comparsion of LN03 and LPS40 PostScript output
(1 document), I noticed a significant difference in page positioning on
A4-size paper.
As I recall, it looked like the LN03 output was printed relative to the
top of the page and the PostScript output was relative to the bottom.
-- Ward
|
| After having opened my PostScript manuals and hacking around one of
Documents postscript files, I've found the problem, its a bug. After
Document has included the prolog section it sets the page margins,
thus:
1000 BP 39600 30600 PM 0 0 XY
Unfortunatley, this is 8.5 x 11 in. European LPS40s are shipped
with A4 and A3 paper trays. This line needs to be modified depending
upon the /PAPER_SIZE qualifier. An oversight?
The fix at the moment is change this line to (in the editor do a
find on "%%EndProlog" )
1000 BP 42120 29880 PM 0 0 XY
Peter
|
| Re: .1
> As I recall, it looked like the LN03 output was printed relative to the
> top of the page and the PostScript output was relative to the bottom.
That is precisely what is happening. LN03s build the page with the origin
at the top, while PostScript interpreters build the page with the origin
at the bottom.
Re: .3
> [...a discussion of changing " 39600 30600 PM " to " 42120 29880 PM "...]
Yes, this will extend the page image up (39600 -> 42120) and cause it to
define a narrower page (30600 -> 29880), and this is what the
device converter will eventually due. In the meantime, you should be
able to print your files as they come of the device converter by using
the VERTICAL_OFFSET parameter to the /DEVICE_CONVERTER qualifier:
$ DOCUMENT/DEVICE=(VERT=22) ...
The default that the converter assumes is 1 inch down. Since the
VERTICAL_OFFSET is specified in points, its default value is 72.
For the adjustment you want, the proper value ought to be 22.
If your document does, in fact, span more than 11 inches from the top
line of text to the bottom line of text, you should get an OFFPAGE error
from the device converter as it now stands. Otherwise, the vertical offset
specified ought to be an acceptable workaround for the moment.
> Hard coded constants!!!
Actually, it's done with a variable whose variability has not yet
been implemented -- which brings us to the last point...
> [... bug ... oversight...]
This is a known deficiency in V1.0. Our desire to address it, and
subsequent failure to complete that implementation by V1.0, is
discussed (if sometimes obliquely) in a variety of topics including
numbers 74, 293, 611 and 740.
We have a strategy for its full implementation, but elected not to
delay product release to implement that strategy fully. We recognize
that this is crucial to our loyal non-U.S. users, and will definitely
provide the full solution.
(Of course, from the user's point of view, it's a bug that we let through.
And I can't really argue with that classification.)
We're sorry for the inconvenience it causes many of our users.
--Mark
|