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

Free Support Forum - aspose.com

How can I get Aspose.PDF to embed fonts when printing to an XPS printer driver

I am using source code from the Aspose.PDF-for-.NET github repository.

In particular I am using the PrintoXPSPrinter.Run() method, which opens a PDF file and then prints it to the Microsoft XPS Document Writer.

The source pdf contains text, but when I open the XPS file created by the printer driver, it contains no XPS <Glyphs> records at all. Every glyph from the source document is rendered instead as an XPS <Path> record.

Some implications of this are:

  • If you subsequently open the XPS file in an XPS viewer, no text can be selected, because the XPS viewer looks for <Glyphs> records.
  • the XPS is much larger than it needs to be. There is no <Path> reuse, so instead of rendering say 40 <Path> items, one for each glyph shape, the XPS contains thousands of <Path> items, many of which are duplicates.

You will be able to demonstrate this reported behaviour immediately using the unmodified source code from your github repo.

My question is: what changes do I have to make to the supplied PrintoXPSPrinter.Run() method so that the generated XPS file contains <Glyphs> records instead of <Path> records?

@Brian_THOMAS

Would you kindly try converting PDF directly into XPS using following code snippet and share your feedback with us if you are able to obtain expected output. We will further proceed to assist you accordingly.

// Load PDF document
Document pdfDocument = new Document(dataDir + "input.pdf");

// Instantiate XPS Save options
Aspose.Pdf.XpsSaveOptions saveOptions = new Aspose.Pdf.XpsSaveOptions();
            
// Save the XPS document
pdfDocument.Save("PDFToXPS_out.xps", saveOptions); 

The XPS produced using the code snippet you supplied does use <Glyphs> instead of <Fonts>

This is the technique we used in our code originally, but we logged issue PDFNET-46334 and switched to a workaround method, printing instead to an XPS printer driver. But there are longstanding open issues with both techniques:

What I’d like is one aspose method that reliably produces XPS from a PDF. Currently aspose pdf provides two unreliable methods of XPS creation.

Please would you answer the original question here, which is “how can I modify the sample code so the generated XPS uses <Glyphs> instead of <Path> records?” Also would you give some timescale for when these issues will be resolved?

@Brian_THOMAS

Thanks for sharing your detailed feedback.

We have noticed your requirements and comments on both cases and would like to share with you that PDFNET-46334 is currently under the process of investigation and we will surely update you on its progress as soon as we make some.

We are afraid that currently this feature is not available in the API and for the sake of its implementation, a ticket as PDFNET-47527 has been logged in our issue management system.

We will surely look into the details of both of your tickets and assure you that they will be resolved. We are afraid that we cannot share any promising ETA or timeframe due to other issues which were logged prior to these ticket but, we will certainly inform you as soon as some definite progress is made towards their resoltuion. We greatly appreciate your patient and comprehension in this regard.

We are sorry for the inconvenience.

@Brian_THOMAS

We have investigated the ticket and found that the XPS file is created by Microsoft XPS Document Writer driver. We have no control over its functioning. It always works this way. We never could get selectable text, whatever files we tried to print. It is found that such behavior is due to the undesired embedding of fonts that are not freely distributed.