Conference iosg::all-in-1_v30

    
>    	1.  A document is created with multicolumns. In WP, R and P
>    options work fine with this document ie it is outputed in real multicolumn
>    effect. However, when the same document is read with R in EM menu, it
>    is displayed as pages of column text. 
    
A Read from WP (see OA$DO:WPLIST) will put the WPS-PLUS document through
the WPS-PLUS formatter and then list the output from the WPS-PLUS
formatter. 

A Read from EM will sometimes list the document directly and sometimes call
WPLIST.  When directly listing the document the WPS-PLUS formatter is not
used which results in multi-column regions not being formatted.   This 
means that the behaviour depends on which sub-system (WP or EM) you are 
using.

You will probably find that the handling for the document is blank.  If you
change this to WPSPLUS then a Read from EM will call WPLIST and therefore 
call the WPS-PLUS formatter. 


In ALL-IN-1 V3.0 we have changed the rules for when a Read from EM does or 
doesn't call WPLIST.  It is now determined only by the document type and 
handling.  The sub-system (WP or EM) does not make any difference.  
Therefore if you think the V2.4 behaviour is a problem it's fixed in V3.0.



>    	2.  When a HPLaserjet is attached to PC as local printer, the
>    postscript file will be printed fine if the number of lines per page is
>    set to 64 but when it is set to 60 lines per page, then the printing
>    will start at about 2 inch from top of page. The destination is set to
>    PORT and format is PS.
    
Does this problem only occur with HPLaserjet printers as port printers, or 
does it also occur when these printers are used from VMS print queues?


Richard

    Hi Richard,
    	The HPLaserjet printer has not been tested from VMS print queue.
    	However, when printed as port printer, the result is inconsistent
    when different settings are set eg. number of lines per page, top and
    bottom margins; ie some lines could be missing.
    	I hope you can explain what the purpose of format style field is in
    print option when for eg. PORT is selected as destination and PORT has the
    printer device as LP11 while PS is selected as format style. In this
    case, which .PRA is used ie PS.PRA or LP11.PRA ?
    	Thank you for your prompt reply!
    Regards.

The destination field determines where the document is printed.  The format
style controls how the document is formatted and printed.  For documents
which are formatted with the WPS-PLUS formatter the format style is used to
select which WPS-PLUS Printer Table is used.  This is controlled by the
Device Type field of a Printer Type entry. 

Each printer destination has a default format style but a user is allowed
to select a different style. 

When you select the PORT destination you are saying that you want the
document to be printed on the port printer.  As shipped in SSB kit the
default format style for PORT is LP11, and the device type for the LP11
style is LP11 and therefore LP11.PRA will be used.  If you change the
format style to PS then a device type of PS and therefore PS.PRA will be
used. 


Using ALL-IN-1 V3.0 (WPS-PLUS V4.1) I created a 60 line WPS-PLUS document
and printing it to a LN03-R PostScript printer.  The printed document had a 
large top margin, which is the type of problem you reported in the original 
note.  I remember reading in another note that for PostScript output if you 
create a document with a page size smaller than the paper sheet size then 
the page is positioned at the bottom of the sheet of paper.  You may get 
some further information about this in the WPS-PLUS conference.


Richard

Hello and Greetings,

Customer running ALL-IN-1 V3.0 (British)
customer doesn't like multicolumn display when reading an EM. I suggested that 
he either change the Handling to WPSPLUS (his site has changed the 'handling' 
field so that it is now called 'document type'), or do a print to terminal..

Customer claims that his users will not accept the notion of doing a print to
terminal - even though it works. He also claims that changing the handling
doesn't work.

Any ideas on what can be done for this customer?

Thanks & regards,

Chele B
(disclaimer - I have also read note 1324)

The decision on whether to list the message via the compound document text 
dataset, or to format it, is taken in the OA$DO:WPLIST script.

If the Handling field is set WPLIST will look to see if a Read or Print 
function has been defined.  Normally the WPSPLUS Format Master entry does 
not have these fields defined which results in the message being listed via 
the compound document text dataset.

If you created a script containing:

   get #PRINT_DOCUMENT = OA$CURDOC
   get #PRINT_PRINTER = "TERMINAL"
   do WPPRINT

and set the WPSPLUS Format Master 'List function: ' field to invoke this 
script a read of message with the Handling set to 'WPSPLUS' will be turned 
into a Print to TERMINAL.  If the Handling is not set a Read of the message 
will be listed as before.


Richard