We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Font not correctly printed when using Document.Print()

Hello Support

We have an issue with a specific font not being printed correctly when directly printing using Document.Print().
Exporting the document as PDF using Document.Save() embeds the font correctly though.

The font in question is in OpenType Layout with TrueType Outlines.

We checked with latest version 18.11.

Kind regards

@ftschui,

Please ZIP and attach the following resources here for testing.

  • Input Word document
  • Font file you are getting problem with during printing
  • Aspose.Words generated PDF file showing the desired output.

We will then investigate the issue on our end and provide you more information.

P.S. If your file size is big then you may upload the ZIP file to Dropbox or any other file hosting service and share the download link here for testing.

@awais.hafeez

I attached the following items inside the .zip File:

  • Source document (.dotx Word template)
  • All the fonts in the same family
  • PDF created by Aspose.Word
  • Scan of the printout

Font_issue.zip (721.1 KB)

Kind regards

@ftschui,

We have logged your problem in our issue tracking system. Your ticket number is WORDSNET-17812. We will further look into the details of this problem and will keep you updated on the status of the linked issue.

@ftschui,

It is to update you that we are currently working on your issue (WORDSNET-17812). Can you please clarify what exactly is wrong in “scan.pdf” that you attached in your previous post? We do not really see any big difference between “scan.pdf” and “Dokumente_20181126_093840.pdf”. Thanks for your cooperation.

@awais.hafeez,

Thank you for looking into this matter.
Please look at the second and fourth line of text:

  • In the PDF exported: They look exactly the same.
  • In the scan of the printout: The second line is using a “faux bold” mechanism to being boldened instead the glyphs of the font file. Due to this, the second line looks “skinnier” than the fourth line.

Kind regards.

@ftschui,

Thanks for the details. We have logged your comment in our issue tracking system and will keep you posted on further updates.

@ftschui,

The problem appears because GDI+ cannot properly handle these fonts and performs bold simulation instead of using bold style. The same issue is observed when saving to image. In this case, we do not think that we can do much about it.

As a workaround you can try to save the document to some convenient format and print the result. For example, XPS documents can be printed via PrintQueue class, XamlFixed documents can be printed via WPF, PS (Postscript) and PCL files can be sent to printer.

Please tell us if this workaround is acceptable for you?

@ftschui,

Regarding WORDSNET-17812, we have completed the work on your issue and come to a conclusion that we would not be able to implement the fix to your issue. Your issue (WORDSNET-17812) has now been closed with ‘Won’t Fix’ resolution. Please use the workaround from my previous post. Hope, this helps.

@awais.hafeez,

We have another 3rd party library in use (for reporting purposes) that had similar issues. But they had an option to use a printer as measurement device, what solved the issues. Perhaps this might also be a possible solution to this issue?

Anyway, we’ll try to use one of the workarounds you mentioned.

@ftschui,

What is the name of the third party API you are referring to? Please share complete details about the special feature you found in that API. Do they have documentation link for that feature?

@awais.hafeez,

The 3rd party API is ComponentOne Reports (Flexreport) for Winforms.
Following API objects are used: MeasurementDevice and MeasurementPrinterName. If these properties are set to Printer with a valid PrinterName, the issues we had with rendering of RTF formatted text disappeared.

I’m not sure how they are using these settings internally though. They just mention to use it in combination with System.Drawing.Graphics in the links above.
I hope this helps.

@ftschui,

We have logged these details in our issue tracking system and will keep you posted on any further updates.

@ftschui,

We checked the details mentioned in your previous post. I am afraid, this does not seem to be helpful for us. The proposed printer metrics related feature is available only in un-managed GDI (Win32 native code), so it is not available/usable for us. In addition, printer metrics are not directly related to the choice of fonts.

@awais.hafeez,

Thanks for looking into this. I’ll check if any of the workarounds are useable in our code / workflow.

@ftschui,

Sure, if we can help you with anything else, please feel free to ask.