HTML-to-RTF conversion: Bare text nodes at start of HTML body lose leading digits and render with huge font in Outlook

Aspose.Email Product Family
1

When converting HTML bodies to RTF format, if the HTML fragment begins with bare text (not wrapped in tags), Aspose emits the first text run immediately after the \fs24 control word with no delimiter. RTF readers then absorb leading digits into the font-size parameter, causing:

  • Leading digits to be dropped from the text
  • Text rendered in extremely large font size in Outlook

Reproduction:

  1. Create an HTML body starting with bare text containing digits: "2026-06-15 16:25:50\tuser@x.com\thello<br>"
  2. Convert to RTF via setBodyContent(html, BodyContentType.Html)
  3. Open resulting MSG in Outlook
  4. Observe: missing “2026” and huge font

Affected Versions:

  • Aspose.Email 22.9, 24.3.1, 25.4 (verified across all three)

Workaround:
Wrap bare HTML fragments in <html><body> tags before conversion:

if (firstNonWhitespace != '<') {
  html = "<html><body>" + html + "</body></html>";
}

This forces Aspose to emit an htmltag group delimiter, preserving text integrity.

Expected Behavior:
RTF control words should not absorb following text content; bare text at document start should render at normal font size with all characters intact.

2

Hello @SaiRamNayak,

Welcome to our support forum!

We were able to reproduce it exactly as described.

SetBodyContent(…, BodyContentType.Html) stores the body as RTF-encapsulated HTML and
does not write the optional PR_HTML property, so that RTF stream is the only copy of the
body.
MapiMessage.BodyHtml is de-encapsulated back out of it. The consequence is that
the digits are lost from our own round-trip, not just from Outlook’s rendering:

input    : 2026-06-15 16:25:50<tab>user@x.com<tab>hello<br>
BodyHtml : <meta …>-06-15 16:25:50<tab>user@x.com<tab>hello<br>

So the original text cannot be recovered from the saved message by any consumer.

Wrapping the fragment in <html><body> is correct and safe to keep using; it makes the
writer emit an {\*\htmltag…} group between \fs24 and the text, which supplies the
delimiter. Two lighter alternatives, if they suit your code better:

  • Prepend a single space to the fragment, enough on its own.
  • Wrap in any block tag, e.g. <p>…</p>.

We will log this for the development team as a defect in the RTF writer.

Your expected behaviour is right, and thank you for the clean reproduction steps; they made this quick to confirm.