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]

[PatentGamer]

Yep, I'm evaluating this as a replacement for our adobe licensed software and this is a primary issue with presentations/submissions to said government agencies. Hope the work around can be rendered unnecessary soon? Literally this is why we have the existing license - make sure there aren't any submission hiccups. This being one of the known primary hiccups, the current process has a saved profile for submissions that embeds all on printing by default.

[Daniel - PDF-XChange]

Hello, PatentGamer

At the moment, I am sorry to say I do not have any news confirming this to come soon or not. The last item in record for both tickets is another increase in priority, but it seems it is still behind a few other items. As you have said, hopefully we can get this all configured nicely for a future release.

Kind regards,

[mCHSNUg5Pz8cPap]

[H]opefully we can get this all configured nicely for a future release.

I stated above that the best solution is to implement the tickets related to adding manual control of font embedding to the editor. Although that would be nice, since I originally posted this I have encountered a situation where a pdf file with invisible text (i.e., text with a fill color of none) had security settings that only allow it to be printed (it was digitally signed). I could print it to another pdf (so I could highlight and mark things) but PDF-XChange wouldn't pass the text through to the new pdf file because the fill color of the text is set to none. This forced me to print the document to pdf to remove the security limitations and then OCR it instead of being able to rely on the text that was present in the original document. So, even if manual control of font embedding is added to the editor, it still wouldn't cover this situation. This is why I would like to see the print process changed so that invisible text is sent to the new pdf file.

Thanks

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

To be fair, the only situation where you could not manually change the text color is the example you provided, where security on the document prohibits changes. Security that we as a PDF producer are supposed to respect, is what you are currently asking us to offer a method to circumvent.

I am sorry but I cannot say a solution to that scenario is likely to be forthcoming. Any case that does not involve security preventing changes would allow you to use the "edit text" tool, and manually change the font or color, right then and there, no need for printing, and no need for OCR.

Adding the long awaited "manually embed font" function would also not work on secured docuemnts which prevent changes, as moving from a local font to an embedded font does constitute a "change". As such, that feature will not resolve this particular scenario you have proposed either.
If the font should be embedded, it needs to be done before any security is applied, or you need to have a valid method to remove the security (knowing the password, or having the correct certificates on hand), not printing.

Kind regards,

[mCHSNUg5Pz8cPap]

Hello, mCHSNUg5Pz8cPap

To be fair, the only situation where you could not manually change the text color is the example you provided, where security on the document prohibits changes. Security that we as a PDF producer are supposed to respect, is what you are currently asking us to offer a method to circumvent.

I am not asking to "circumvent" the security. The security allows printing. My request was simply to have the Editor pass text with a fill color of none through the printing process. Text in the document with literally any color gets sent through the printing process without it being considered "circumventing" the security (even white on a white background, which is functionally invisible).

For example, here is an example of a file with security settings that only allow printing (password is Test1). The file includes a box of text with no fill color, a box of white text and a box of black text.

TestDoc_secure.pdf

Here is the file that is created when I print the secured file.

TestDoc_print.pdf

The printed file contains the box with white text and the box with black text but the box with text that has no fill color is completely gone. Passing text with no fill color through the print process does not violate the security settings of the document.

This thread, combined with a few others, has given me the vibe that the true motive for rejecting this request is: (a) it's too niche and/or (b) a general hostility to any suggestion to improve the process of printing a pdf to create another pdf. If so, I am sympathetic because it is niche and I prefer things being implemented so that they do not require printing a pdf to pdf. However, if these are the actual reasons, then it would be better to just say so rather than giving what feels like multiple incorrect answers (e.g., the first answer above that fonts are never sent as part of the printing process and now the answer that doing so would expressly circumvent the security requirements, which ALLOW printing).

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

There are times when topics are avoided because they are niche, however, when those come about, that is the reason we give, you can see it happening quite a few times even here on the forums. Font embedding is certainly not a niche feature, but it is a highly complicated one. So getting it the attention it needs, is quite difficult, which would be why it is "on hold" at the moment.

Like our support team, we have a very small dev team compared to some other companies. This of course means they have an immense load on their shoulders, and unlike many companies out there, we don't expect our team members to work overtime to meet artificial/self set deadlines. If a delay is needed, that is acceptable. As such, our cadence may sometimes feel slow, and I can only apologize for that, but we are working as efficiently as we can to deliver the most popular features, while keeping up with as many bug reports as we can, utilizing the skillsets we have on hand moment to moment.

Regarding printing transparent text, I have seen enough requests for similar actions, (however, usually in the vein of bypassing security), that I don't think the "desire" for it is niche. The number of valid use cases for it however, are definitely a bit more of a niche situation. I was clearly a bit too focused on the security concerns here because that is usually the desire when I see that request, so my apologies for the misunderstanding.

Beyond that, upon asking around some more, the concept of sending invisible text to printers can often result in problems with the physical print output. Since invisible text, unlike solid white text, usually directly overlaps other page content, that could cause worthless printed output. Indeed, It may be handled nicely by a virtual printer, but the vast majority of print jobs from our software, are to physical devices, not the virtual printers, so we need to keep track of that... and sadly, there is no notable way to distinguish whether what type of printer we are sending to, we just prepare it all for a physical print job.

Kind regards,

[mCHSNUg5Pz8cPap]

Beyond that, upon asking around some more, the concept of sending invisible text to printers can often result in problems with the physical print output. Since invisible text, unlike solid white text, usually directly overlaps other page content, that could cause worthless printed output. Indeed, It may be handled nicely by a virtual printer, but the vast majority of print jobs from our software, are to physical devices, not the virtual printers, so we need to keep track of that... and sadly, there is no notable way to distinguish whether what type of printer we are sending to, we just prepare it all for a physical print job.

That makes sense. If something like this was ever implemented, it would need to be as an option kind of like what I suggested above except perhaps "Include invisible text and images" so that those using physical printers can leave it unchecked and avoid problems.

[Daniel - PDF-XChange]

Hello, mCHSNUg5Pz8cPap

Indeed, and perhaps sometime in the future that will be revised, but for now I cannot make any promises along that line.

Kind regards,