T.R | Title | User | Personal Name | Date | Lines |
---|
3798.1 | FORMAT master entry? | IOSG::NEWLAND | Richard Newland, IOSG, REO2-G/L2 | Mon Jan 24 1994 10:40 | 15 |
| > I would have thought that the processing in WPPRINT or FILEFORMAT would
> have stopped this operation taking place on a FOREIGN document and
> generated some sort of FOREIGN documents cannot be printed message.
WPPRINT and FILEFORMAT uses information in the FORMAT master to find out
how a document should be formatted. 'FOREIGN' means that the format is not
fully supported by the Text dataset mechanism, but it does not necessarily
mean that a document cannot be formatted by another mechanism, e.g. CDA.
Is there a POWERPOINT2 FORMAT master entry. Such an entry tells ALL-IN-1
how to format the document for printing? If there is not an entry ALL-IN-1
will default to ASCII formatting, which appears to be what is happening.
Richard
|
3798.2 | It works OK when I read document | SEDOAS::DAVIES_G | GLYN DAVIES @ESO | Mon Jan 24 1994 11:35 | 28 |
| Richard,
No I havnt got an entry in the FORMAT master for POWERPOINT2 as I havnt
written any special formatting script for this format.
Basically I want the same thing to happen when the document is printed
as when it is read. ie a FOREIGN document type cannot be displayed
message.
I dont particularly want to have to create a FORMAT master entry for
every possible format that a user might receive attached as a mail
message.
I think that the problem may be around the file extension that the
document receives when it is inserted into the file cabinet.
If I do a DT RCV on the file a copy of it with a .FGN extension is
created and I get the FOREIGN document cannot be displayed message.
If the document is detached from a mail message sent from a TeamLinks
user it is created with a .PPT file extension and I get the COPY error
when trying to print.
Something appears to be going wrong here.
regards,
Glyn
|
3798.3 | More information on problem | SEDOAS::DAVIES_G | GLYN DAVIES @ESO | Mon Jan 24 1994 14:00 | 45 |
| Richard,
The problem does seem to be with the .FGN file extension. I have done
the following tests on an ALL-IN-1 IOS system that will be supporting
both interactive VT users together with TeamLinks users.
1. From a TeamLinks session I sent a mail message with a PowerPoint
attachment to an interactive ALL-IN-1 IOS user.
- The interactive ALL-IN-1 user reads the message and gets the
following message:
Document with ".PPT" file type cannot be displayed
- The interactive ALL-IN-1 user files the attachment. The attachment
is stored with a FOREIGN DSAB and given a file extension of .PPT.
If the ALL-IN-1 user now tries to print the filed attachment I get the
error message relating to the COPY function as outlined in .0
2.. From a TeamLinks session I sent a mail message with the same PowerPoint
attachment to the same interactive ALL-IN-1 IOS user. However this
time I force the message through Message Router.
- The interactive ALL-IN-1 user reads the message and gets the
following message:
FOREIGN document type cannot be displayed
- The interactive ALL-IN-1 user files the attachment. The attachment
is stored with a FOREIGN DSAB and given a file extension of .FGN.
If the ALL-IN-1 user now tries to print the filed attachment I get the
FOREIGN document type cannot be displayed message as I would expect.
This would seem as if it is going to be a major problem with customers
who are using the same IOS server for interactive and TeamLinks users.
Any ideas on what can be done to address this.
Regards,
Glyn
|
3798.4 | Add FORMAT master entry | IOSG::NEWLAND | Richard Newland, IOSG, REO2-G/L2 | Tue Jan 25 1994 14:56 | 19 |
|
You did not say what version of ALL-IN-1 you are using but if it is V3.0A
then the only way of getting a better error message displayed is to add a
FORMAT master entry. The Print Function in the FORMAT master entry should
call a script which returns displays a suitable message and returns an
error status.
Since ALL-IN-1 V2.2 (and perhaps earlier but that's before I worked on
ALL-IN-1) formatting for printing has always defaulted to ASCII formatting
if no other method is defined. This may no longer be the best thing to do
but any changes we make also have to consider sites which rely on the
current behaviour.
The issue is noted and improvements will be considered for inclusion in a
PFR.
Richard
|