Email to PDF produces vertically overlapping text layer

Aspose.Words Product Family
1

Hi guys!
We are struggling with vertically overlapped text in PDFs created out of emails.
Code is very simple (basically from your example: Saving an Email as PDF|Documentation):

Aspose.Email.MailMessage mailMsg = Aspose.Email.MailMessage.Load(@"c:\temp\email3.eml");
            
MhtSaveOptions mhtSaveOptions = new MhtSaveOptions();
mhtSaveOptions.MhtFormatOptions = MhtFormatOptions.WriteHeader;

MemoryStream ms = new MemoryStream();
mailMsg.Save(ms, mhtSaveOptions);

var loadOptions = new Aspose.Words.Loading.LoadOptions();
loadOptions.LoadFormat = LoadFormat.Mhtml;
var document = new Aspose.Words.Document(ms, loadOptions);

var saveOptions = new Aspose.Words.Saving.PdfSaveOptions();
document.Save(@"c:\temp\email3.pdf", saveOptions);

Unfortunately i’m not able to upload the EML.
Any idea how EML could be uploaded here?

But if you open the attached PDF, you can clearly see something like this:

email3.pdf (105.6 KB)

950×512 8.65 KB

929×495 11 KB

“C” and “F” letter bounding boxes verticaly overlapping significantly.
And here is a visualization of PDF text layer bounding boxes:

1094×521 75.6 KB

For sure it has something to do with fonts used on email.
But do you have any idea how such vertical text overlap could be avoided or limited?

Hope it’s somehow clear. :wink:
Thank you!

2

@ondrej.hanak
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSNET-27581

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

3

The issues you have found earlier (filed as WORDSNET-27581) have been fixed in this Aspose.Words for .NET 24.12 update also available on NuGet.

Acrobat calculates selection height by using /FontBBox ymin and ymax values from /FontDescriptor. The difference between AW and MW output is that MW writes font Descent/Ascent values there and AW writes font ymin/ymax values. Here is quote from specification: “A rectangle (see 7.9.5, “Rectangles”), expressed in the glyph coordinate system, that shall specify the font bounding box. This should be the smallest rectangle enclosing the shape that would result if all of the glyphs of the font were placed with their origins coincident and then filled.” So the font ymin/ymax values are more suitable here than Descent/Ascent. Also despite the MS Word, all other producers we checked writes ymin/ymax values. Also the selection height calculation is a PDF viewer specific. Chrome and Foxit for example uses Descent and Ascent values (which are also written to the PDF) and there is no difference between Aspose.Words and MS Word output.
Considering the above, Aspose.Words behavior is correct here and we should not copy MS Word behavior. Closing this issue as “Not a Bug”.

4

Hi!
Okay, so it means there was nothing fixed/changed, correct?

I mean, because of this:
" The issues you have found earlier (filed as WORDSNET-27581) have been fixed in this Aspose.Words for .NET 24.12 update also available on NuGet."

5

@ondrej.hanak

Yes, you are right, there is nothing to fix on our side.