Embed Fonts: Save as PDF/A Works but Print to PDF Does Not

[mCHSNUg5Pz8cPap]

Forget all this and go to my second post.
I want to embed the fonts in this file:

Test File.pdf

.
Printing the file as pdf removes all the fonts. It appears that it rasterizes the pages, but I'm not sure.
Saving the file as PDF/A embeds the fonts.

Can you reproduce this? If so, why does print to pdf not embed the fonts (even with the box checked to embed all fonts) and save as PDF/A does embed the fonts?

I prefer printing the file to pdf because the resulting file usually passes the USPTO's embedded font checks while saving as PDF/A does not (I created a separate post about this but the response I received from PDF-Xchange was, to paraphrase "the PDF/A file looks fine to us; if it doesn't pass the USPTO's checks then that's their problem").

On a separate note, a useful feature would be to include a check box in the OCR options to embed the identified fonts. This would be a really nice feature.

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

Printing very commonly will remove font data in favor of the more "physical printer friendly" concept of vector shape objects. Our software is no exception.
It is worth noting that most of those "font embedding" check systems are not looking for embedded fonts present in the file, they are usually looking for font data which is not embedded. If any is present, it is a fail, so long as no unembedded font data is present (including cases where no font data is present at all) the document will usually pass. This is most likely what has happened with your previous printed submissions.

Sadly, with the exception of our own software (in which "print" operations are only intended to go to a physical format, we never recommend printing a PDF to PDF, when using save as is faster and retains the digital aspects of the file better), we have no control over how third party applications handle this process. If they provide our printer with vector shape data instead of a complete font pack, we have no font information to embed into the resultant file.
I should probably also note that printing any PDF document to any printer, physical or virtual, will result in loss of document internal data, such as metadata, links, bookmarks, and destination.

Moving past this, we have touched on the topic of offering a dedicated "Embed used fonts" button for the Editor. At the moment it is not in active development, however, it is on the list for a future implementation.

Kind regards,

[mCHSNUg5Pz8cPap]

Thanks for the reply Daniel. I think I did a poor job explaining the issue I am facing, and I included an aside that seems to have sent the conversation down the rabbit hole of my previous post. I edited my original post to strike it in its entirety in attempt to get this post back on track.

The issue I'm inquiring about is this. The following pdf file includes fonts that were produced by OCRing the file.

Test File.pdf

Printing this file to pdf with PDF-XChange (I have PDF-XChange Pro) using the default options and the check box for "Embed All Used Fonts" checked (see below) does not embed the fonts.

image.png

.
Why are the fonts not embedded in the pdf file?

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

Your original explanation was fine, and I don't think the key part of my reply was quite as far down the rabbit hole as you expect, though I may have glazed over some important details in my explanation, which I apologize for.
In a brief summary, fonts are not embedded because they were not provided to the printer.

What you are seeing is expected. The Printer can only perform embedding actions if there is actual font data sent to the printer by the printing application. It is at the mercy of the printing application, and the data that application chooses to provide it to work with.

• Most modern applications (including the Editor) will not send any actual font data for a virtual printer to work with. In turn, we have no data on hand to embed into the file. In essence, the Editor, MS Word, most Web browsers, etc. are usually converting the text into a physical printer friendly format, long before any data is passed to the printer.
  Generally this is done as an "assist" step, because your computer can do it much better than the printer. A physical printer may not have access to the needed font data, the character-set may be too large for it to process quickly (usually oriental sets), or it might fail to read it properly, resulting in a different appearance than the preview/intent and garbled/useless output, wasting paper.
  
  The situation you are encountering is exactly one of the reasons why we do not advise printing a PDF to PDF, "Data Loss". To retain all of its function, PDF should stay digital at all times.
  The "save as" feature can be used to make a duplicate of any file when needed, instead of printing. For this reason, printing is expected to be a conversion to a physical format. With virtual printers, re-printing a PDF to PDF will see some loss of data no matter what we do. The Editor is only intended to play nicely with physical printers.

So my answer is unchanged here, despite the new explanation. We do not offer a manual "embed" fonts option to fit your needs (yet), so the save as PDF/A option is still the best method I can offer.
The only exception would be if the recipients have no need to "edit" the text in your files later on. If they do not need to make any such edits, You may print, or rasterize the document to remove all text, and thus all "unembedded font" data which could result in a fail.

Kind regards,

[mCHSNUg5Pz8cPap]

If I understand correctly, you are saying that when printing a pdf to a virtual printer (such as the PDF-XChange printer) with PDF-XChange, the fonts are not sent and, therefore, the output does not include any fonts (this also has the side effect of making the "font" settings for the virtual printer irrelevant).

I'll be honest and say I'm not sure I believe this explanation (or perhaps I'm still misunderstanding something) because print to pdf works in other situations to embed fonts.

I tested your explanation by doing the following.
1. I converted the pdf file I provided above (Test File) to MS Word using the following settings (I think these are the default because I almost never use this feature):

image.png

.
The resulting Word file is here:

Test File_1.zip

.
2. I then created a pdf file from the Word file by printing it in Word to the PDF-XChange Standard printer using the default settings (i.e., the embed fonts box was not checked) thereby producing the following file with unembedded fonts.

Test File_2.pdf

.
3. I then used PDF-XChange to print this pdf file to pdf with the default settings except with the box checked to embed all fonts. The result is this file with the fonts embedded.

Test File_3.pdf

.
This shows that PDF-XChange is capable of printing a pdf file to pdf and embedding the fonts. If your explanation is correct, then PDF-XChange sends the fonts to the virtual printer in this case but not when printing the original Test File to pdf. Why is that? And there seems to be no indication to the end user whether or not it will send the fonts to the virtual printer.

[mCHSNUg5Pz8cPap]

After some more testing, it appears that printing to pdf does not embed fonts if the "Fill Color" of the text is "None." Instead of embedding the fonts, the fonts are just discarded. I cannot find a setting that I can change that will cause PDF-XChange to embed fonts such as this.

If the Fill color is anything else, then printing to pdf will embed the fonts. You can test this by changing the fill color of any of the text in the "Test File" to something other than "none."

I think this behavior is problematic because the text produced by OCRing a file with the output option set to "Searchable Image" produces a file filled with text having the "Fill Color" as "None." If this file is printed to pdf, then I do not think users expect the text to be discarded. I think the user expectation is that the text will be retained and embedded in the resulting document even if the "Fill Color" is set to none.

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

My apologies, you are correct, and I was mistaken on a the Editor side of this. (The way the printer works however is as I said, very much at the mercy of what is provided to it).
The Editor will send font information when it would be compatible with, and not detrimental to, a physical printer. The locally installed Times new Roman and Arial are good examples of this.
However, that is not to say this is a 100% reliable fact. There will be times when due to other factors in the document or your environment, as you saw today, it is not always possible for font data to be provided to the printer.

In the case of the OCR version of your file from earlier, what I missed was that the text present is invisible. As it would not appear on print if it has no color value at all, it gets removed beforehand. The conversion process you used beforehand in this second attempt, made the text visible, and uses locally available fonts, in turn allowing it to be sent during the print process.
In practice, if you were to use the "Enhanced OCR" engine to generate "editable text", the printed output should contain the needed font data for embedding...

Kind regards,

[mCHSNUg5Pz8cPap]

In the case of the OCR version of your file from earlier, what I missed was that the text present is invisible. As it would not appear on print if it has no color value at all, it gets removed beforehand. The conversion process you used beforehand in this second attempt, made the text visible, and uses locally available fonts, in turn allowing it to be sent during the print process.
In practice, if you were to use the "Enhanced OCR" engine to generate "editable text", the printed output should contain the needed font data for embedding...

I don't understand the focus on printed paper. The PDF-XChange printer driver is never used to print to paper. It is always used to create another pdf file, which means it will always have capabilities that printed paper does not have. For example, I cannot print bookmarks to printed paper. This doesn't mean, however, that the PDF-XChange printer driver should delete all the bookmarks in a file when it is printed to pdf.

I also note that the PDF Specification ISO 32000-2:2020(E) says:

14.8.2.4 Hidden or invisible page content
For a variety of reasons, elements of a document’s real content can be invisible on the page: they can be clipped; their colour can match the background; or they can be obscured by other, overlapping objects. For the purposes of tagged PDF, page content shall be considered to include all graphics objects in their entirety, regardless of whether they are visible when the document is displayed or printed.

NOTE For example, invisible elements can become visible when content is repurposed, or a text-to-speech engine could choose to speak invisible text.

Even though the text is hidden or invisible, it is still considered "real" by the PDF specification (as opposed to being an artifact). Also, the use case I'm advocating for clearly falls within the note in the sense that a text to speech engine could choose to speak the invisible text as long as PDF-XChange does not delete it as part of the print to pdf process.

Now that we know what is happening and that you do not believe it is a bug, my post should be considered a feature request to either: (1) stop deleting text having a fill color of none so text from OCRed files is retained through the print to pdf process or (2) make the deletion of invisible text optional (and maybe other invisible content) as part of the optimization options in the printer options (see below for an example of such an option).

image.png

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

The section of the ISO you mention is not relevant to this particular discussion, as it states:

• "For the purposes of tagged PDF[...]"
  Indicates that this specific purpose refers to the use of "Accessibility tagging" features (which also would not be retained during a print operation). This feature requires that the document "remains" in PDF format at all times, without any conversion to a "Printing" format which cannot hold this data, and then back to PDF.
  
  The ISO in general, does not dictate any special considerations for data sent to Virtual Printers over Physical printers (and in most cases, Virtual Printers don't identify differently at the application level, they are all just "device drivers"). The Spec defines how a PDF document should be created while it remains in the PDF format. Printers work with a unique format, which cannot hold most of PDF's special functions, like accessibility items.

Now, on to the main request:

my post should be considered a feature request to either: (1) stop deleting text having a fill color of none so text from OCRed files is retained through the print to pdf process or (2) make the deletion of invisible text optional (and maybe other invisible content) as part of the optimization options in the printer options (see below for an example of such an option).

The best I can offer here is that I have requested a formal increase in the priority on our tickets (RT#4138 & RT#4790), relating to adding manual control of font embedding to the Editor. I cannot promise any changes to print handling, but hopefully we can offer a better solution for you that does not involve printing in the first place.

Kind regards,

[mCHSNUg5Pz8cPap]

The best I can offer here is that I have requested a formal increase in the priority on our tickets (RT#4138 & RT#4790), relating to adding manual control of font embedding to the Editor. I cannot promise any changes to print handling, but hopefully we can offer a better solution for you that does not involve printing in the first place.

Yes, this would be the best solution, so this is appreciated. Thanks.

In the meantime, a work around for those who cannot embed OCRed text using the "Save As" PDF/A process (because certain government agencies will reject it for having unembedded fonts) is to select all the text in the document (content pane > right click on a page > Select > Text (see image below) and change the color of the text to literally any color.

image.png

Print the document to pdf with the embed fonts option checked, select all the text again, and change the color back to none. The result is a perfectly fine pdf document with all the fonts properly embedded.

[Daniel - PDF-XChange]