Conference iosg::all-in-1_v30

> We have a problem with postcript documents send by ALL-IN-1 via Message Router.
> Those documents came from EXEL, WORD, doc are .PS (Windows 3.1)

Are these documents transferred into ALL-IN-1 and mailed from ALL-IN-1?  If
what ALL-IN-1 options are used to do this


> Local users can normally print them
> Remote users (via MTS) most of time can't print them   
  
Do you mean that local ALL-IN-1 users can print these ALL-IN-1 documents, 
but if these documents are mailed to remote users they cannot print them.


Martine

When you say the remote users "can't" print these documents, do you mean that
when they print them the PostScript code is printed, rather than the document?

Or do you mean that the act of sending the document somehow changes or corrupts
it so that a "P"rint operation fails in some way?

I suspect the former, in which case a temporary workaround would be to set the
documents' FORMAT fields (aka Handling - use the U option to change this) to
PS - this tells ALL-IN-1 to process the document as PostScript.

What filename extension (eg .PS, .TXT, .WPL) do these files have at the sending
end?  What DSAB and FORMAT values do they have?  What filename extension, DSAB
and FORMAT do they have at the receiving end?  (I have a sneaking suspicion that
the text of thePostScript file may have been imported into a .WPL file in
ALL-IN-1...)

Is is the same version of ALL-IN-1 at both sending and receiving ends?  Which
version of ALL-IN-1 is it?

PostScript files are difficult to send by e-mail, as they are basically just
text files, and it requires that sufficient extra information be added to the
mail message to identify the text as PostScript.  Unfortunately, this isn't as
straightforward as it should be, and so in some circumstances the receiving end
gets the document tagged as just plain text.  To ensure the (ALL-IN-1) recipient
can process the document as PostScript, make sure that at the sending end it
has a filename extension of .PS, a DSAB of PS, and FORMAT of PS.

The good news is that the situation is improving, as e-mail systems and
standards are extended to cater for more diverse bodypart types.

Scott

Hello Richard,

Thanck to you for your quickly answer.

> We have a problem with postcript documents send by ALL-IN-1 via Message Router.
> Those documents came from EXEL, WORD, doc are .PS (Windows 3.1)

Are these documents transferred into ALL-IN-1 and mailed from ALL-IN-1?  If
what ALL-IN-1 options are used to do this

==> Yes, these are documents transferred into ALL-IN-1 with options WP, DT, RVC
and mailed from ALL-IN-1



> Local users can normally print them
> Remote users (via MTS) most of time can't print them   
  
Do you mean that local ALL-IN-1 users can print these ALL-IN-1 documents, 
but if these documents are mailed to remote users they cannot print them.

==> Yes the SAME document is mailed to a local user and a remote user,
the local user can print the document but the remote user can't print it.

Martine.

================================================================================

Hello Scott,

Thanck to you for your quickly answer.

>When you say the remote users "can't" print these documents, do you mean that
when they print them the PostScript code is printed, rather than the document?
Or do you mean that the act of sending the document somehow changes or corrupts
it so that a "P"rint operation fails in some way?

==> I mean that the act of sending (Via MTS) the document somehow change or 
corrupt  



>I suspect the former, in which case a temporary workaround would be to set the
documents' FORMAT fields (aka Handling - use the U option to change this) to
PS - this tells ALL-IN-1 to process the document as PostScript.

==> If the remote user change the document' FORMAT field with the U option, 
he has the error message "Invalid or missing arguments to function" when he
wants to print it.



>What filename extension (eg .PS, .TXT, .WPL) do these files have at the sending
end?  What DSAB and FORMAT values do they have?  What filename extension, DSAB
and FORMAT do they have at the receiving end?  (I have a sneaking suspicion that
the text of thePostScript file may have been imported into a .WPL file in
ALL-IN-1...)

==> the filename extension, of sending document, is .PS, the DSAB and FORMAT 
too.
The document have been imported into a .PS file in allin1 and the same 
document is sending to a local user, he has been printed this without problem 


>Is is the same version of ALL-IN-1 at both sending and receiving ends?  Which
version of ALL-IN-1 is it?

==> Yes it's the same, it's the ALL-IN-1 V3.0-1


>PostScript files are difficult to send by e-mail, as they are basically just
text files, and it requires that sufficient extra information be added to the
mail message to identify the text as PostScript.  Unfortunately, this isn't as
straightforward as it should be, and so in some circumstances the receiving end
gets the document tagged as just plain text.  To ensure the (ALL-IN-1) recipient
can process the document as PostScript, make sure that at the sending end it
has a filename extension of .PS, a DSAB of PS, and FORMAT of PS.

The good news is that the situation is improving, as e-mail systems and
standards are extended to cater for more diverse bodypart types.

==>Strangly thingh, all the documents (Excel, Word...) haven't this problem
but some users have allways this problem when they send their documents and 
other users nerver!! 

Martine.
    

>> the act of sending (Via MTS) the document somehow change or corrupt

Can you be more specific?  Do you know what exactly gets changed?

>> the filename extension, of sending document, is .PS, the DSAB and FORMAT too

This is all correct.  What is the extension, DSAB and FORMAT of the document
at the recipient's end when sent remotely to a user who can't print it?

>> some users have always this problem when they send their documents and 
>> other users never!

Are they sending the documents to other ALL-IN-1 users using mail addresses of
the form "USER @ A1 @ NODE [ @ AREA ]", or are they going through a gateway
(eg MRGATE)?

Are they sending the documents as attachments, or as the main bodypart.  It is
well-known that some PC applications produce PostScript that doesn't exactly
follow the rules.  If you mail such a document as the main bodypart, when
ALL-IN-1 prints it, it formats the message header as PostScript, then appends
the bodypart PostScript.  If the bodypart is a document that's broken the rules,
you will get printing errors.  Try FT (File Text) to move the bodypart into a
new document, and see if you can print that.  Or use SH (Show Message Status)
to get the document filename, and see if you can print the file from DCL.

Scott

	We have seen problems as you have described and many times it has been
due to the way the file is copied to VMS.  You may want to check the VMS files
(before they get imported to ALL-IN-1) to make sure they are NOT 512 byte 
records.  MR will reformat these so that they won't print - you get 
"offending command is ...." at the printer.

	Some transfer mechanisms that can do this are:

	Kermit (after doing a set file type binary)
	NFT - block mode

	Any help?

John

    Also there is a known problem with V3.0 not handling records greater
    than 256 bytes. I believe they are truncated on Send and Split into 256
    bye chunks if received as records greater than 256 bytes. 
    
    Thus if your PostScript file contains some long records it could get
    corrupted when sent remotely. Local Send only mamipulates pointers to
    the file.
    
    This can be overcome by sending the file as a Foreign document. Also
    fixed in Emerald.
    
    Regards
    Alan

    On some MTS systems there is a customization that reads files to see if
    they might be PostScript.  That might explain why they work on some
    systems and not on others.  Those systems running the standard product
    don't do this.
    
    In addition, I found that many Encapsulated PostScript files start with
    one or more blank lines, so the script doesn't realize they are
    PostScript.  I have customized our system to keep reading if the firzt
    line is blank.  This did lead to an interesting strangeness with the
    INCREMENT function which I need to check out before reporting.
    
    Ben

*** THANCK TO ALL FOR YOUR ANSWER ***

===============================================================================

Scott,

Sorry for my delated answer but I did a lot of tests around this problem...

Some results :
A SENDER_USER created a WORD (or EXCEL...) document on PC, he encapsulated 
the postscript file via WINDOWS 3.1, and copied the PS document via NFT 
(COPY/BLOCK) to ALL-IN-1 account's and create a mail attachement with it.
the SENDER_USER sent this document to too users :

to the fist user on the same machine (local mail) 
===> To :  A1 LOCAL_USER @ATY		( LOCAL_USER ) 
When this USER_LOCAL receive the document, he printed the postscript document 
without problem from ALL-IN-1 (Printer Style = PS)

and to a second REMOTE_USER on another machine (via message router)
===> To :  Remote Addressee             ( USER_REMOTE @EVO )
when he receive this, the act of sending has converted the document and it 
was impossible to print it.

The question is : Does the act of sending or the act of encapsulating 
corrupt the postscript document???... 
It seems to me that the problem come from the way on how are encapsulated 
documents on different PC's (source file), I can only say some senders users 
got the probleme, like otherone never had it, even though they proceed to the 
same way. 

Best regards.
Martine.

    

>> The question is : Does the act of sending or the act of encapsulating 
>> corrupt the postscript document?

I don't think the encapsulation is the problem, otherwise the local recipient
wouldn't be able to print it.  Verify this by printing the sender's OUTBOX copy
of the message and see if that works.

You still don't say in exactly what way the file has been corrupted.  Does it
arrive at the remote recipient with the correct data type, handling and file
name extension?

Also, you are using an MTS address: REMOTE_USER @ SITE-CODE

If, for example, the Message Router database sends that person's mail to MRGATE,
and they have VMSmail forwarding set to ALL-IN-1, things could go wrong.  Try
sending to the same person, but use their direct ALL-IN-1 address
    REMOTE_USER @ A1 @ NODE @ SITE-CODE
and see if that makes a difference.

Alan's suggestion in .6 is a strong contender too.  Get the filename of the .PS
file at both sending and receiving ends, and do $DIFF on the files.  There
should be no differences at all.

Scott