XFOR: Interoperability Between Exchange Server 5.0 and 5.5

 Last reviewed: February 12, 1998
Article ID: Q177956
The information in this article applies to:
  • Microsoft Exchange Server, version 5.0

SYMPTOMS

There are a number of non-trivial interoperability issues between Exchange 5.0 and 5.5 in RTF to HTML and Imail. Some of the issues are the following:

  1. If you create an HTML in any codepage OTHER then ANSI / ISO-8859-1 and
put some international characters between <TT> and </TT>. Then convert the HTML round trip HTML->RTF->HTML the International characters between <TT>> and </TT> are corrupted. This corruption is permanent and can't be fixed y changing the browser character set or font. 2. After HTML->RTF conversion, an extra space at the line following <Hn>...</Hn> is emitted. 3. Loss of background color and bad formatting of table cells. Incorrect handling of <TD> ... <TD> sequence (with no </TD>). 4. The background color information is appended as text output after HTML- >RTF->TEXT conversion. 5. The Body tag property is corrupted when converted to Unicode. 6. There is corruption of the <TITLE> tag of an embedded message when converting to Unicode. 7. Foreign mail using extended Latin characters gets sent as US-ASCII with all the accents stripped.

MORE INFORMATION

The same corruption happens for any HTML tag implying monospace font, i.e., <TT>, <KBD>, <SAMP>, and <CODE>. The problem is caused by not marking the monospace font (second font in RTF font table) with the correct character set, which means the font is treated as ANSI.

Since cell formatting is independent of the formatting outside of the table (IE and NN behavior), we now save and restore overlapping tag stack around tables and emit \plain keyword in RTF at the table start. Also, we make sure any new cell terminates the previous one and any cell formatting is ind pendent of each other (e.g., FONT started and not terminated in one cell does not propagate to the next one).

RTF keywords \background and \shpinst needed to be marked as IGNORABLE, so that the destination gets ignored for plain text processing when in the encapsulated range.

Now we have better codepage detection. In ambiguous cases (when the character fits into multiple codepages),we use the non-Western one. Specifically, if you compose a message using a non-Western character set on a machine set to the Western locale, we will use that character set even if the first nternational character encountered fits into Western codepage.

STATUS

Microsoft has confirmed this to be a problem Microsoft Exchange Server version 5.0.

This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 5.0. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces): 

   S E R V P A C K

Keywords          : kbbug5.00 kbfix5.00 kbfix5.00.sp2 XFOR
Version           : WINDOWS:5.0
Platform          : WINDOWS
Issue type        : kbbug
Solution Type     : kbfix

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

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: February 12, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.