Conference vaxuum::document_ft

    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

    This sounds weird, as TeX uses the top left-hand corner of the paper
    for references. What I'm after is something like HORIZONTAL_OFFSET
    set to something in DOC$DESTINATIONS.DAT for postscript output,
    but that seems to be ignored. Anyone any answers?
    
    Peter

    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