DXLImporter fails with RichText Table

hcl-bot · July 13, 2005, 7:11pm

I am running Domino 6.0 and a Notes 6.5 client. I created a NotesDXLExport Agent and successfully exported an email containing RichText to a local file.

I then created a NotesDXLImport Agent and get a failure on importing. The following message is provided by importer.Log

<?xml version='1.0'?>

Table cannot be wider than 22.75 inches

DXL importer operation failed

I reviewed the XML and see no width in the table elements that exceed 22.75 inches. I figured if the exporter worked the importer should as well.

Any suggestions?

Bruce

hcl-bot · July 13, 2005, 7:17pm

Subject: DXLImporter fails with RichText Table

What do the elements look like?

hcl-bot · July 14, 2005, 8:04am

Subject: RE: DXLImporter fails with RichText Table

Here are snippets of various elements describing widths of the table columns

#1)

 <tablecolumn width="100%" refwidth="21.7500in"/>

#2)

					<table r4spacing="true" leftmargin="1.2500in" widthtype="fitmargins" cellborderstyle="ridge" columnspacing="0.0278in" rightmargin="21.7500in">

						     <tablecolumn width="100%" refwidth="20.5000in"/>

#3)

						<table r4spacing="true" leftmargin="1.5000in" rightmargin="20.5000in" widthtype="fitmargins" cellborderstyle="ridge" columnspacing="0.0278in">

							<tablecolumn width="90%" refwidth="18.3500in"/>

#4)

						<table r4spacing="true" leftmargin="1.7500in" rightmargin="18.3500in" widthtype="fitmargins" cellborderstyle="ridge" columnspacing="0.0278in">

							<tablecolumn width="0.30%" refwidth="0.0500in"/>

							<tablecolumn width="49.92%" refwidth="8.2875in"/>

							<tablecolumn width="49.92%" refwidth="8.2875in"/>

#5)

<tablecolumn width="27.30%" refwidth="5.4597in"/>

<tablecolumn width="14.05%" refwidth="2.8097in"/>

<tablecolumn width="17.30%" refwidth="3.4597in"/>

<tablecolumn width="20.80%" refwidth="4.1597in"/>

<tablecolumn width="10.55%" refwidth="2.1097in"/>

hcl-bot · July 14, 2005, 3:16pm

Subject: RE: DXLImporter fails with RichText Table

One interesting note, the only way the DXLExport produces a richtext element is if I have a loop coded that traverses the items before writing them to the file stream. Commenting out the loop, the Notes Document richtext fields wind up as itemdata fields in Base64 encoding. I had a loop to display the information via a Messagebox about the richtext element.

Here is the code snippet:

Forall item In doc.Items

 If (item.Type = RICHTEXT) Then

Messagebox item.Name & " : " & item.Text & ":" & item.Type & "=" & ItemTypeString(item.Type)			

 End If

End Forall

Certainly this is very odd (undocumented) behavior.

hcl-bot · July 14, 2005, 3:22pm

Subject: RE: DXLImporter fails with RichText Table

Itemdata in Base64? Is the field set to store as HTML and MIME?

hcl-bot · July 15, 2005, 8:12am

Subject: RE: DXLImporter fails with RichText Table

Yes. The itemdata is Base64. I downloaded a Base64 decoder and decoded these fields. What was weird with that result was the field attributes decoded as non-ASCII characters. Perhaps they are raw data within Notes anyway. The data of those fields decoded correctly.

Not sure about your second question. I don’t know how to set the DXLExporter to do this. I am just setting two properties of the NotesDXLExporter, namely

' Create and configure the DXL Exporter

Set exporter = session.CreateDXLExporter

exporter.OutputDOCTYPE=False

exporter.ForceNoteFormat=True

hcl-bot · July 15, 2005, 8:43am

Subject: RE: DXLImporter fails with RichText Table

The base64 itemdata in this case is packed structures, so essentially binary data. It is converted to base64 so that it is easy to add to a text file.

hcl-bot · July 15, 2005, 11:53am

Subject: RE: DXLImporter fails with RichText Table

Understood.

There are multiple issues here and I will try and net them out here.

I want to export email (NotesDocuments) in DXL format and then import them and have them look the same.
In some cases, where there are RichText fields in the e-mail, the import of some of those do not look the same, i.e. formatting is lost. This appeared to me that the Base64 encoding/decoding caused the problem, but that shouldn’t be the case.
I changed the Exporter to force Mime conversion to RichText. This caused the error of the RichText table width, which is why I posted my original issue.
In further testing, I found that the behavior of the DXLExporter is different depending on whether I just highlight the email in my inbox or am viewing the email in its own form at the time of exporting.

So is there a bug in the DXLExporter, DXLImporter, or is this a user error (my configuration)?

hcl-bot · July 21, 2005, 1:57pm

Subject: Some partial answers from development

I want to export email (NotesDocuments) in DXL format and then import them and have them look the same.

Always our goal but it is hard to undergo a CD-to-XML and then XML-to-CD conversion without some differences. I think we will get a lot better in 7.0 and if you keep at us by reporting the problems in SPRs, we’ll keep getting better. You are using exporter.ForceNoteFormat=True which results in a slightly lower-level representation of documents (much lower-level for design notes) which slightly increases the chance of a perfect round-trip. There is another option eRichtextAsItemdata that would force to be written as instead, which would greatly increase the chance of a perfect round-trip. Alas, we seem to have only exposed that in the C API (see xml.h in a C API SDK). We have this open SPR to add it to the other APIs.

DANO6CSLE6: Backend class DXLExporter APIs need to support eRichtextAsItemdata option

Are you seeing richtext items be emitted as itemdata? If so, that would seem to be a bug, as the option to do so isn’t even exposed.

In some cases, where there are RichText fields in the e-mail, the import of some of those do not look the same, i.e. formatting is lost. This appeared to me that the Base64 encoding/decoding caused the problem, but that shouldn’t be the case.

We also have another open SPR

JHER6ASQ52: DXLImporter and DXLExporter do not handle base64 encoded attachments

which basically claims that attachments that are already Base64 encoded get encoded again by DXLExport, and it fails to set/use encoding=‘base64’ in either the Exporter or the Importer, meaning that the resulting attachment will still be in Base64 and Notes won’t know to decode it. This seems to be a red herring based on your description, but I mentioned it anyway.

You say richtext but maybe these are really MIME items. DXL does emit those in Base64 because it doesn’t currently support a better representation for MIME. should always be round-tripped as-is. Are you on a platform other than Windows?

I changed the Exporter to force Mime conversion to RichText. This caused the error of the RichText table width, which is why I posted my original issue.

The MIME conversions really create some ugly tables with nonsensical/invalid width/margin data. DXL can’t deal with them sometimes.

In further testing, I found that the behavior of the DXLExporter is different depending on whether I just highlight the email in my inbox or am viewing the email in its own form at the time of exporting.

I don’t get why this would be happening. Is the same DXLExporter code used in both cases? If so, it would seem that the note has been modified in one of the cases with extra/changed items.

So is there a bug in the DXLExporter, DXLImporter, or is this a user error (my configuration)?

Hard to tell yet!

hcl-bot · July 22, 2005, 3:01am

Subject: RE: Some partial answers from development

“it would seem that the note has been modified in one of the cases with extra/changed items.”

Wouldn’t exporting from the opened memo/reply cause the computed-for-display fields to be included? In which case, the content when the form is open would be SUBSTANTIALLY different. There’s a ton of that stuff in the mail template.