Save as PDF/A Not Creating Compliant PDF/A Documents

[mCHSNUg5Pz8cPap]

I want to create a PDF/A compliant document from a Word file and upload it to the U.S. Patent and Trademark Office (USPTO). The USPTO checks all uploaded files to make sure all fonts are embedded. The embedded font check fails depending on the method I use to create the pdf file. I'll describe each method below.

Method 1 - Print document to PDF-XChange printer (this works)
I created the PDF/A file by printing the Word document to the PDF-XChange printer with the compatibility set to PDF/A-2b. This is the resulting file, which PDF-XChange says is PDF/A-2b compatible.

EP3054857A2_Description-PDFA-PDFXPrintPDFA2b.pdf

(157.31 KiB) Downloaded 63 times

This file can be uploaded to the USPTO's website without any problems.

Method 2 - Use PDF-XChange to save pdf file with unembedded fonts to PDF/A document (does not work)
I created a pdf file by using the built-in function of Word to save the document as a pdf. This results in the following pdf file, which does not have all fonts embedded.

EP3054857A2_Description.pdf

(149.63 KiB) Downloaded 65 times

I opened this file with PDF-XChange and then used the Save As option to save it as a PDF/A document (the PDF/A option is available in the drop down menu of file types). This results in the following file, which PDF-XChange says is also PDF/A-2b compatible.

EP3054857A2_Description-PDFA-PDFXChangeSaveAsPDFA.pdf

(216.41 KiB) Downloaded 65 times

If I upload this file to the USPTO's website, it throws an error saying it contains an unembedded font.

It seems that method two is not creating a pdf file that conforms to the PDF/A specification.

[TrackerSupp-Daniel]

Hello, mCHSNUg5Pz8cPap

Thank you for the report, I have forwarded this to our Development team and they are investigating it now. Hopefully this can be resolved in time, but for the moment, you can continue using the print method as a workaround.

Kind regards,

[David.P]

Hello mCHSNUg5Pz8cPap,

a short question in the context of your above post, which I'm quite sure you can answer from your experience.

When submitting (i.e. uploading) drawings to the USPTO that are rendered as 1bit pure black and white at, say, 300 dpi: will these be included in the electronic file by the USPTO at the same color depth and resolution, or will the PDFs be degraded with JPEG compression, as shown below (admittedly somewhat exaggerated).

Regards
David

[Tracker Supp-Stefan]

Hello David.P,

I hope mCHSNUg5Pz8cPap gets back to you quickly!
It's always great to see people helping each other.

Kind regards,
Stefan

[mCHSNUg5Pz8cPap]

When submitting (i.e. uploading) drawings to the USPTO that are rendered as 1bit pure black and white at, say, 300 dpi: will these be included in the electronic file by the USPTO at the same color depth and resolution, or will the PDFs be degraded with JPEG compression, as shown below (admittedly somewhat exaggerated).

If the file you upload is a 300 dpi binary image, then it will show up in the USPTO image file wrapper without any modifications. The image is not degraded by any kind of compression.

As a side note, this is why the rasterize feature in PDF-XChange is so key. The dithering algorithm it uses to create the binary image is really good. I've tried a lot of other dithering algorithms and found one that was slightly better, but not enough to justify paying an extra $70/year for the license.

If you upload an image that is not binary or not 300 dpi, then the USPTO will convert it to a 300 dpi (at least if it is over 300 dpi; I have never uploaded a lower resolution image) binary image using a stone age algorithm that usually makes the resulting file look like trash.

[David.P]

If the file you upload is a 300 dpi binary image, then it will show up in the USPTO image file wrapper without any modifications. The image is not degraded by any kind of compression.

Thank you for the information. Good to hear that!

Officially, the USPTO accepts both Letter and A4. Do you happen to know if this works in practice? Or should Letter be used in any case?
https://www.uspto.gov/web/offices/pac/mpep/s1606.html#:~:text=The%20size%20of%20the%20sheets%20on%20which%20drawings%20are%20made%20must%20be

As a side note, this is why the rasterize feature in PDF-XChange is so key. The dithering algorithm it uses to create the binary image is really good.

Does this mean that you also uploaded (binary rasterized) grayscale images to the USPTO, and the USPTO has put them into the image file wrapper without any resampling as is?

Similar as below (first the original, then rasterized in black and white with PDF-XChange Editor).

using a stone age algorithm that usually makes the resulting file look like trash

True. I wonder how many thousands of proceedings have been compromised by this practice....

[mCHSNUg5Pz8cPap]

Officially, the USPTO accepts both Letter and A4. Do you happen to know if this works in practice? Or should Letter be used in any case?

Yes, the USPTO will accept either letter or A4 without any problems. I usually resize everything in PDF-XChange to letter size. As an aside, the one button page resizing is another great feature of PDF-XChange! Now we just need one button font embedding and it would be perfect!

Does this mean that you also uploaded (binary rasterized) grayscale images to the USPTO, and the USPTO has put them into the image file wrapper without any resampling as is?

Yes, although technically grayscale is different than a binary image so it's better to refer to the image as binary, bitonal, or 1-bit monochrome. If you upload any form of grayscale, it will get mangled by the USPTO. If the file meets the USPTO's requirements (binary image; 300 dpi), then the USPTO does not make any changes.

Similar as below (first the original, then rasterized in black and white with PDF-XChange Editor).

I don't know how you rasterized the second image, but it looks like you did it the same way as the USPTO, which is to say it looks awful. The rasterized version you show is what I want to avoid.

I took the first image, put it in a Word file, converted it to PDF (using PDF-XChange), and then rasterized it in PDF-XChange with the following settings:

The image in the pdf file barely changed from what it looked like before I rasterized it. Here is the final pdf file:

Image.pdf

(163.16 KiB) Downloaded 64 times

If I uploaded the PDF file to the USPTO's website, it would look exactly the same as it does in the attached file.

True. I wonder how many thousands of proceedings have been compromised by this practice....

I know of at least one case where a third party filed some prior art (i.e., a third party submission) that was illegible.

A high-quality rasterized version makes it so fine details in documents, especially prior art documents and informal invention disclosure documents filed in provisional patent applications (e.g., schematics), are legible and easy to understand. It also makes the drawings look really good in the printed patent, which is something I like.

[Paul - Tracker Supp]

Thanks for this mCHSNUg5Pz8cPap,

Thanks especially for posting the settings that can be used for the USPTO to upload images that do not get mangled!

[David.P]

Yes, the USPTO will accept either letter or A4 without any problems.

If I uploaded the PDF file to the USPTO's website, it would look exactly the same as it does in the attached file.

Thanks, that's very good to know.

If you upload any form of grayscale, it will get mangled by the USPTO.

It sure will, because the USPTO indeed uses a stone age algorithm.

It's called "Ordered Dithering" and does things like this:

I don't know how you rasterized the second image, but it looks like you did it the same way as the USPTO, which is to say it looks awful. The rasterized version you show is what I want to avoid.

No, that's "Diffusion Dithering" as used by PDF-XChange Editor

It can be seen when zooming in or out, or copying the image into a PDF file.
Below is another version with very low resolution and then enlarged, in order to see the dithering:



Here are different dithering versions from a related Wikipedia article:

https://en.wikipedia.org/wiki/Dither#Algorithms

It can be clearly seen that the method on the left that is used by the USPTO has by far the worst results.

A high-quality rasterized version makes it so fine details in documents, especially prior art documents and informal invention disclosure documents filed in provisional patent applications (e.g., schematics), are legible and easy to understand. It also makes the drawings look really good in the printed patent, which is something I like.

True. However, you probably wouldn't want to use dithering with black-and-white line drawings, which are best when simply converted to 1 bit bi-tonal without applying dithering:

[mCHSNUg5Pz8cPap]

A high-quality rasterized version makes it so fine details in documents, especially prior art documents and informal invention disclosure documents filed in provisional patent applications (e.g., schematics), are legible and easy to understand. It also makes the drawings look really good in the printed patent, which is something I like.

True. However, you probably wouldn't want to use dithering with black-and-white line drawings, which are best when simply converted to 1 bit bi-tonal without applying dithering:

I convert all black and white line drawings to 1-bit bitonal format. If I don't then there is always the risk that there will be one grayscale line in the drawings that causes the USPTO to run the entire file through it's bi-tonal conversion algorithm.

I don't understand why, but when I use dithering to recompress the same image, it results in a much higher quality version (I cannot figure out how to get an animated png file to work like what you did:

I'm trying to figure out why I'm getting different results than you when I convert images into bitonal format. Going back to the image of the machine you posted earlier, if I open the image directly in PDF-XChange and convert it to bitonal, then I get the same terrible image you posted (at least it looks roughly the same to me). Here it is:

However, if I paste the image in Word and then convert the file to a 300 dpi PDF file using PDF-XChange (the Word add-in, not by printing to the PDF-XChange printer; also the conversion does not include any image compression), then I get a pdf file where the original image has been split into four pieces each of which is 300 dpi. I can covert it to bitonal and it looks great.

PDF_ConvertedFromWord.pdf

(3.71 MiB) Downloaded 51 times

I rasterize the PDF file and get a really high quality file I can upload to the USPTO.

PDF_USPTO.pdf

(162.56 KiB) Downloaded 51 times

I think the difference is that when I convert it in Word to PDF, it does so at 300 dpi, which increases the resolution when making the bitonal file.

[mCHSNUg5Pz8cPap]

I think I've figured it out.

If I take the original machine image you posted:


And convert it to a 1-bit bitonal image using the recompress images feature, it keeps the resolution at 72x72 and produces this lousy image:


However, if I rasterize the original image using the settings I posted earlier in this thread, then I get the following high quality 1-bit bitonal image:


The difference appears to be the setting in the rasterize menu that puts the resolution to 300x300. The crappy looking 1-bit bitonal image has a resolution of 72x72 while the high quality bitonal image at the bottom as a resolution of 300x300.

NOTE: The last two images I posted above are not 1-bit bitonal because I had to export them from PDF-XChange. I exported them in true color because it most accurately reflects what they look like in PDF-XChange. However, the images are 1-bit bitonal images in the pdf files (which I can post if anyone wants to see them).

[David.P]

I don't understand why, but when I use dithering to recompress the same image, it results in a much higher quality version

I don't think so. You should never apply dithering to a line drawing, this will always degenerate the quality, because it tends to eat away pixels from your lines.

At best, it's like in the example you posted: the two images are identical:

(I create animated PNG with a small open source tool called APNG Assembler).

And convert it to a 1-bit bitonal image using the recompress images feature, it keeps the resolution at 72x72 and produces this lousy image:

That image is also lousy because it no longer has the original black and white quality and resolution, but is re-sampled in grayscale, for some reason -- possibly because of this setting from the image context menu in PDF-XChange Editor not being activated:


In 72 dpi and pure black and white it looks like this:



Below is the maximum resolution and quality that makes the image just about fit on a DIN A4 sheet at 300 dpi:


The high resolution image you had posted has over 700 dpi on DIN A4:

(It seems that you have replaced it with a lower resolution, color/greyscale version in the meantime)

So you would have to use about DIN A1 to get this image down to 300 dpi, where it would not be resampled by the USPTO.

[Paul - Tracker Supp]

Thanks for that - it looks great!

Nice work sorting that out.

[mCHSNUg5Pz8cPap]

I don't think so. You should never apply dithering to a line drawing, this will always degenerate the quality, because it tends to eat away pixels from your lines.

When it comes to the drawings you file with the USPTO, I strongly disagree with this and here's why.

A couple of years ago I started asking why some drawings in issued patents looked good and others looked awful. I learned that the USPTO stores all drawing files as black and white, 300 dpi, 1-bit bitonal images (technically, all files are stored that way except supplementary content, which is another topic altogether). If a file does not meet these requirements, then the USPTO will convert it to this format using a terrible dithering algorithm that makes the result look awful.

To stop the USPTO from mangling the file, it must already meet the requirements before it is uploaded. I looked for software that can do this and found the Black Ice Monochrome printer driver. It provides fine detail control of the algorithm and other settings used to create the pdf file for upload to the USPTO.

After a lot of testing, I found two settings that worked really well. The first setting was for "line drawings" that do not contain any grayscale, color, etc. The setting converted the file without any dithering and used a black/white threshold of 50. The second setting was for everything else and used a dithering algorithm (Stucki set at 95 intensity). The second setting worked on features that were already black and white like lines and numbers. The result was visually indistinguishable from the first setting, but the file was bigger. This is the reason I initially didn't just use the second setting for everything.

This worked until I encountered reality in the form of the crapshoot of drawings patent illustrators would send me. The files they sent often included things like grayscale, shading, and even color (honestly, they have no idea what happens to them when they are uploaded to the USPTO). I quickly realized that converting the drawings without dithering resulted in random features being rendered unrecognizable. For example, the shading of a part would become solid black or white.

I was faced with: (1) converting the drawings without dithering, find the parts that got messed up, redo those with dithering, and hope I didn't miss anything or (2) use dithering on everything, which would produce a larger file, but there was no chance anything got screwed up. I chose option 2.

I found PDF-XChange sometime after this and found the dithering algorithm used by the rasterize pages feature to produce a smaller file that was about 96% as good as the Black Ice printer driver. I switched to it because it is easier to use and I could stop paying for a license to Black Ice (it cost almost as much as PDF-XChange).

So, you are technically correct that using dithering on lines and text in images that are black and white may slightly reduce their quality (I cannot tell the difference visually). However, anyone who does that when filing drawings with the USPTO is playing with fire. It's just a matter of time before they file drawings where something important gets rendered as pure black or white. If the error is discovered after the filing date, then there is no way to fix it. This is why you should always apply dithering to a line drawing filed with the USPTO.

The rest of your comment deals with issues with the images I included in the last post. Shortly after making the last post, I edited it to add a note explaining what happened to the images.

The pdf files created from your original image show the correct result. Here they are.

PDFcreatedbyrecompressingimage.pdf

(35.89 KiB) Downloaded 54 times

PDFcreatedbyrasterizingpage.pdf

(370.81 KiB) Downloaded 50 times

The recompress image process produced a crappy looking 72x72 DPI 1-bit bitonal image while the rasterize page option produced a high quality 300x300 dpi image. I always use the rasterize page feature. It creates the absolute best PDF files for filing with the USPTO. The rasterized image looks almost the same as the original 8-bit grayscale image you posted.

[David.P]

[...]
To stop the USPTO from mangling the file, it must already meet the requirements before it is uploaded. I looked for software that can do this and found the Black Ice Monochrome printer driver. It provides fine detail control of the algorithm and other settings used to create the pdf file for upload to the USPTO.
[...]
This worked until I encountered reality in the form of the crapshoot of drawings patent illustrators would send me. The files they sent often included things like grayscale, shading, and even color.
[...]
However, anyone who does [not use dithering] when filing drawings with the USPTO is playing with fire.
It's just a matter of time before they file drawings where something important gets rendered as pure black or white. If the error is discovered after the filing date, then there is no way to fix it. This is why you should always apply dithering to a line drawing filed with the USPTO.

Given the background you described, I fully agree, of course. If you are not absolutely sure to have a pure black and white drawing to begin with, the way you described is the high road with the USPTO.

Decades ago I had used a similar software as the one you mentioned, which was able to rasterize images using different error diffusion methods. Using this software in the 90s, I used to send faxes with images and photos to people or business partners in a virtually photorealistic quality previously unseen.

In my current practice however, the circumstances you describe do not normally occur, since I create the drawings myself and can therefore be absolutely sure that they are in pure black and white from the start, without any shading or even color.

The recompress image process produced a crappy looking 72x72 DPI 1-bit bitonal image while the rasterize page option produced a high quality 300x300 dpi image.

Of course, if using the Recompress Image method, the image must already have the correct dpi number (e.g. 300) beforehand.

Regarding the two different renderings of our example photo, I have attached your files slightly edited.

Generally, the pure dpi number of an image doesn't say much as long as it is not at the same time referring to a physical image size, e.g. to a paper size.

If you apply this to the two differently sized above images as rasterized with PDF-XChange Editor, it can be seen that the images have the same quality at max. USPTO resolution -- just at a different image size. By the way, the second image of yours has a resolution of more than 300 dpi when it is placed on a letter paper sheet in maximum size (see attached).

In this context, I'd be interested to know how the USPTO handles pure black-and-white line drawings that are submitted at higher resolutions, e.g. at 600 or 900 dpi -- should you have tried this already.

PDFcreatedbyrecompressingimage-resized to 300dpi.pdf

(1.41 MiB) Downloaded 48 times

PDFcreatedbyrasterizingpage-resized to Letter.pdf

(1.79 MiB) Downloaded 46 times

[mCHSNUg5Pz8cPap]

Of course, if using the Recompress Image method, the image must already have the correct dpi number (e.g. 300) beforehand.

Regarding the two different renderings of our example photo, I have attached your files slightly edited.

Generally, the pure dpi number of an image doesn't say much as long as it is not at the same time referring to a physical image size, e.g. to a paper size.

If you apply this to the two differently sized above images as rasterized with PDF-XChange Editor, it can be seen that the images have the same quality at max. USPTO resolution -- just at a different image size.

I'm not as familiar as you are with the underlying details of how this all works. However, if I zoom in on the smaller image until it is the same size on my screen as the larger image, then it is apparent that the larger image is higher quality and better shows the details of the machine.

By the way, the second image of yours has a resolution of more than 300 dpi when it is placed on a letter paper sheet in maximum size (see attached).

Yes, it is slightly larger dpi. I don't normally rasterize a single image. Instead, I first change the page size to letter (one button page resizing is fantastic), add headers/footers, and then rasterize everything as the final step. In that case, it will be 300 dpi.

In this context, I'd be interested to know how the USPTO handles pure black-and-white line drawings that are submitted at higher resolutions, e.g. at 600 or 900 dpi -- should you have tried this already.

The USPTO's website used to say that drawings needed to be "at least 300 dpi" (it also said elsewhere that they "should be 300 dpi"). Up until mid-2020, I filed 1200 dpi drawings thinking that if 300 dpi was good, then 1200 dpi would be fantastic! In mid-2020, I had a few cases in a row where the drawings got mangled to the point that whole pages were blank or had random black marks that looked like chicken scratch. I called the USPTO and they said the drawings need to be 300 dpi (they also said the website was wrong to say "at least 300 dpi"). I filed 300 dpi drawings after that and never had any problems (this is also what set me on the quest to figure out what it would take for the drawings to look good). I haven't had the inclination to press my luck by filing higher resolutions such as 600 dpi or 900 dpi. The hassle of fixing the drawings when they get mangled isn't worth it just to be the guy who figured out the maximum resolution for drawings filed with the USPTO.

[TrackerSupp-Daniel]

Hello, mCHSNUg5Pz8cPap

I am sure you noticed, we sort of stepped away form this while you two were discussing the USPTO, since that it a bit outside of our reach. I just wanted to check in and ask if there was anything else we can help you with here? If not, it would be appreciated if you could mark some part of this topic as "solved".

Kind regards,

[David.P]

Hello all,

Sorry for the late answer on my part.

Just briefly one more time about the dpi number of images. A dpi number alone doesn't say anything about the quality of an image.

The quality of an image can really only be judged by the size of the image in pixels, for example by the pixel count of the larger side of the image.

In this respect, the larger of the two images discussed above has a side length of 3058 pixels, and the smaller has a side length of 734 pixels.

While the two images have the same dpi count (in the sample PDFs), and thus the same "resolution quality", the larger one obviously carries more information, and therefore is the "better image".

Anyway, thanks for the further info on submitting higher resolution drawings with the USPTO.

The reason I asked about this is that I usually release the drawings at higher resolution, usually at 600 to 1200 dpi, because various addressees in various countries process the drawings in a variety of ways. In some cases, the drawings are further processed and possibly filed on paper, in other cases digitally.

It also happens that people take screenshots of the drawings, paste them as JPEGs into Word, print the whole thing, then change something by hand or with post-its, and finally scan everything again or send it by fax............

In any case however, the drawings are at least scaled, re-sampled, distorted or otherwise degraded, which is why a submission with exactly 300 dpi can factually not be ensured.

[Paul - Tracker Supp]

[mCHSNUg5Pz8cPap]

I just wanted to check in and ask if there was anything else we can help you with here? If not, it would be appreciated if you could mark some part of this topic as "solved".

The original problem was that PDF-XChange did not create PDF/A compliant documents using the save file procedure. Was that fixed? We went off on a tangent, but I don't recall seeing a post saying it was fixed. You were going to have the development team review it, but that is the last thing I saw.

[mCHSNUg5Pz8cPap]

Anyway, thanks for the further info on submitting higher resolution drawings with the USPTO.

The reason I asked about this is that I usually release the drawings at higher resolution, usually at 600 to 1200 dpi, because various addressees in various countries process the drawings in a variety of ways. In some cases, the drawings are further processed and possibly filed on paper, in other cases digitally.

It also happens that people take screenshots of the drawings, paste them as JPEGs into Word, print the whole thing, then change something by hand or with post-its, and finally scan everything again or send it by fax............

In any case however, the drawings are at least scaled, re-sampled, distorted or otherwise degraded, which is why a submission with exactly 300 dpi can factually not be ensured.

In my case, I'm the person filing the drawings so I can guarantee they are 300 dpi (and 1-bit bitonal). When I receive drawings, I like them to be vector drawings so it makes them easy to modify if needed. One thing that helps those who do not use PDF-XChange to rasterize the drawings is to only use black and white. The presence of a single pixel that is almost black but not quite pure black will cause the USPTO to dither the image and make it look awful. Using black and white can help prevent that.

As for those who print the drawings, mark them up, paste them into Word, etc., there is nothing you can really do to prevent that. Any problems this causes is on them.

[David.P]

Yes, vector drawings are king.

I have essentially dedicated my life to the furtherance of end-to-end vector drawings.

And I can't overstate the crucial role PDF-XChange Editor has in "it".

[Tracker Supp-Stefan]

Yes, vector drawings are king.

I have essentially dedicated my life to the furtherance of end-to-end vector drawings.
And I can't overstate the crucial role PDF-XChange Editor has in "it".

All I can reply here with is a few more wide-open smiles
Thanks for the kind words David and happy that we are contributing to 'vectorizing the world'

Cheers,
Stefan

[mCHSNUg5Pz8cPap]

Yes, vector drawings are king.

I have essentially dedicated my life to the furtherance of end-to-end vector drawings.

And I can't overstate the crucial role PDF-XChange Editor has in "it".

I'm curious to know what role PDF-XChange plays in the furtherance of end-to-end vector drawings. It doesn't seem like it can do much when it comes to vector graphics.

I suggested this feature: https://forum.pdf-xchange.com/viewtopic.php?p=154050#p154050
but it was a no-go.

Although I really like PDF-XChange for most tasks, I still have a copy of Kofax Power PDF Advanced on my computer in case I need to edit vector lines in drawings. It's the only other pdf editor I have on my computer.

[bqxmprij]

Hello, mCHSNUg5Pz8cPap

I am sure you noticed, we sort of stepped away form this while you two were discussing the USPTO, since that it a bit outside of our reach. I just wanted to check in and ask if there was anything else we can help you with here? If not, it would be appreciated if you could mark some part of this topic as "solved".

Kind regards,

Hello,

As you can see from the comments of 'mCHSNUg5Pz8cPap,' not all dithering is equal. There is a request/suggestion at https://forum.pdf-xchange.com/viewtopic.php?t=37170 for more options and specific algorithms. It would be great if these two threads were links for feature implementation, and the dithering options and algorithms are increased.

I also need pdf/A documents and have experienced a PDF-XChange Editor created pdf/A document failing a test to determine that "are all fonts embedded."

When that test fails, I use a third party pdfcreator (named as such) to 'convert' a pdf to a pdf. That never fails. I don't know why or how or even if it is embedding all fonts. But it never fails the test to determine that "are all fonts embedded." Also, I did notice such files are drastically smaller in file size than a pdf/A document--I get that is not your fault, but the file is still smaller.

So, in addition to the initial request, please add a sub request to have a way to force embed all fonts.

I don't know what software is used to test whether "are all fonts embedded," but I bet it is Adobe.

[TrackerSupp-Daniel]

Hello, bqxmprij

Thank you for the followup, the topic you mention does already include a feature request ticket for the issue at hand there, so I will leave that in place as it is.

As for checking which fonts are embedded or have an embedded subset. You can do this within the Editor by opening the Document properties (Ctrl_D) and looking under the "fonts" category, any which are embedded, will state that they are, and any which are not, will not show the "embedded" terminology:

Kind regards,

[Ivan - Tracker Software]

In regards to the original post with non-embedded font in PDF/A - I checked all font objects in the provided PDF file at a low level, and I can assure you that all fonts are embedded. I don't know at the moment what exactly USPTO's tool does not like in that file (I suspect /Type0 fonts), but will try to find that out.
Also, I checked all other online PDF/A validation tools I'm familiar with, and all of them confirm that the file is PDF/A compliant.

[bqxmprij]

In regards to the original post with non-embedded font in PDF/A - I checked all font objects in the provided PDF file at a low level, and I can assure you that all fonts are embedded. I don't know at the moment what exactly USPTO's tool does not like in that file (I suspect /Type0 fonts), but will try to find that out.
Also, I checked all other online PDF/A validation tools I'm familiar with, and all of them confirm that the file is PDF/A compliant.

Thank you. To highlight another thread, https://forum.pdf-xchange.com/viewtopic.php?p=152988#p152988, we pointed out that PDF/A might not actually embed all fonts--I bet it does sometimes and sometimes not. I don't want to speak for the others, but I am not sure they actually want a pdf/A compliant document. What I want, and what I think they want, is a pdf that has embedded fonts sufficient to the pass the 'are all fonts embedded?' test. The disconnect here is that a pdf/A validation test is probably not the same as 'are all fonts embedded?' test.

You note a possible issue with Type0 fonts. What would you do to a pdf to ensure that a document with Type0 fonts would pass a 'are all fonts embedded' test? What would you do to a pdf to ensure that a document with no matter what fonts would pass a 'are all fonts embedded' test?

If any department at the PTO will actually respond to a request for information about the software check for embedded fonts, it is the EBC. https://www.uspto.gov/learning-and-resources/support-centers/patent-electronic-business-center

[Paul - Tracker Supp]

Hi mCHSNUg5Pz8cPap,

OK - I am doing that, reaching out to the USPTO via that link. I was just about to send them your PDF , this one, then realized I should ask your permission first!

I want to ask them "Hey, what's wrong with this file? The fonts are embedded, why are you rejecting it?" - worded more politely of course. I'm just not prepared to pass that on without your expressed permission first.

Is it OK to send the attached?

EP3054857A2_Description-PDFA-PDFXChangeSaveAsPDFA.pdf

(216.41 KiB) Downloaded 46 times

[mCHSNUg5Pz8cPap]

Hi mCHSNUg5Pz8cPap,

OK - I am doing that, reaching out to the USPTO via that linnk. I was just about to send them your PDF , this one, then realized I should ask your permission first!

I want to ask them "Hey, what's wrong with this file? The fonts are embedded, why are you rejecting it?" - worded more politely of course. I'm just not prepared to pass that on without your expressed permission first.

Is it OK to send the attached?

EP3054857A2_Description-PDFA-PDFXChangeSaveAsPDFA.pdf

Yes. Use the files for any purpose you like.

[Paul - Tracker Supp]

Awesome.

Letter sent. Lets see what they say.

cheers

[Paul - Tracker Supp]

These people are not quick to deal with, nor do they seem to read the letters sent them.

After 2 exchanges I had them tell me this:

Hello Paul,

It comes down to the PDF type actually being PDF/A. If you're using adobe professional it'll be a selection in the same drop down as PDF. If you're on a MAC you can use PREVIEW to convert the document into a PDF, and lastly if the document is in MsWord on a PC you can select PDF, then select options and select PDF/A compliant.

I am truly gob smacked. He seems to have either completely misunderstood every word I typed or is a robot...
I've written back with the sample yet again asking to escalate the case if they won't answer directly.

[David.P]

Haha Paul, I know! This seems to happen to me all the time and almost everywhere.

I write my request two or three times in detail and with examples and photos and screenshots, and then I get a reply with a boilerplate text block that proves that (at most) the subject of the request had been read and/or understood.

Maybe this is due to the kind of questions p*tent att*rneys like to ask...

On the other hand, it has never happened to me in my approximately 1000 questions on this forum

[Paul - Tracker Supp]

he he - are you then by inference a "p*tent att*rney"?

Dare I tell my lawyer joke here?

[David.P]

I believe that there are several p*tent att*rneys present in this thread, so probably the right audience for your lawyer joke

[Paul - Tracker Supp]

ha ha - well at the risk of disappointing, here goes:

A lawyer was cross examining a police officer, the credibility of whose testimony hung on the inherent trust this officer has in his fellow police officers. In an attempt to catch him out the lawyer asked:

"There are change rooms in this building intended for the use of the members of the police department. These change rooms have lockers in them, if as you claim, that you can absolutely and completely trust your fellow police officers, why then would there be a need to have lockers?"

To which he replied:

"Well your honour, from time to time a lawyer has been known to use those rooms...".

This is an urban legend, allegedly on this response the judge had to order a recession because of the uncontrolled laughter from the gallery. I don't know if it's true but I love the story...

[David.P]

[mCHSNUg5Pz8cPap]

These people are not quick to deal with, nor do they seem to read the letters sent them.

After 2 exchanges I had them tell me this:

Hello Paul,

It comes down to the PDF type actually being PDF/A. If you're using adobe professional it'll be a selection in the same drop down as PDF. If you're on a MAC you can use PREVIEW to convert the document into a PDF, and lastly if the document is in MsWord on a PC you can select PDF, then select options and select PDF/A compliant.

I am truly gob smacked. He seems to have either completely misunderstood every word I typed or is a robot...
I've written back with the sample yet again asking to escalate the case if they won't answer directly.

This is how I figured your inquiry would end. Those of us who actually work with the USPTO know that you rarely reach the people who can actually help with questions/issues.

As for the lawyer joke,

[mCHSNUg5Pz8cPap]

Now that we have established the USPTO is useless when it comes to customer support, I have some leads to pursue regarding the original problem. Although the USPTO reps are not helpful, I believe the USPTO developers coded the website correctly, which means the problematic files do not have embedded fonts and are not actually PDF/A compliant.

Before I go any further, I will describe how you can use the USPTO's website to test if a file has embedded fonts. The steps are as follows:
1. Go to patentcenter.uspto.gov
2. At the very bottom of the page, click the link "Switch to training mode."
3. A popup will appear. Click on the button "Enter into training mode."
4. Near the top left of the screen, click "New Submission," which opens a drop down menu. Click on "Utility-nonprovisional."
5. A warning popup appears. Click "Continue."
6. Near the top right of the screen a timeline appears. Click the link for "Upload documents."
You are now on the page where you can upload documents. If you upload a document that does not have an embedded font, then it will show an error. If all the fonts are embedded, then it will not show an error.

The initial file used to create the pdf documents is this Word file: https://docs.google.com/document/d/1DqjzbAln-MRnOfNed6lbfXJZoof9xrfG/edit

Using Word, I saved the document as a pdf using the following settings:

.
Doing so produces this pdf file:

EP3054857A2_Description.pdf

(127.65 KiB) Downloaded 41 times

.
The fonts in this file are:

.
Note that the pdf file has two entries for TimesNewRomanPS-ItalicMT with one showing as not embedded and the other showing as embedded (and the encoding of the two is different). Based on my research, I think Word did something weird when it created the file and incorrectly shows the one font as embedded when it actually isn't. At a minimum, pdf files created by Word produce weird font embedding issues. See https://community.adobe.com/t5/adobe-fonts-discussions/word-not-embedding-fonts-in-pdf/m-p/10827749#M1622

I created a PDF/A document using the "save as" dialog and selected the file type as "PDF/A Document." This produced the following conversion report:

.
This is the pdf file created:

EP3054857A2_Description_SaveAsPDFA.pdf

(204.44 KiB) Downloaded 37 times

.
The fonts in this file are:

.
Note that there are four fonts listed in the first pdf file. When it is converted to PDF/A, three of the fonts are fixed. It appears that the font originally shown as being embedded was not touched by the conversion process presumably because it said it was embedded. My theory is that Word incorrectly said it was embedded and PDF-XChange skipped over the font in the conversion process because it is shown (incorrectly) as being embedded.

If I upload this to the USPTO using the method described above, it displays an error that the TimesNewRomanPS-ItalicMT font is not embedded. This is the font that was allegedly embedded in the first pdf file. It does not show an error for the other fonts that were fixed in the conversion process.

I used the first pdf file and printed it to pdf using the PDF-XChange printer set to conform to PDF specification PDF/A-2b. This is the pdf file it created.

EP3054857A2_Description_PrinttoPDFA.pdf

(149.63 KiB) Downloaded 35 times

.
The fonts in this file are:

.
Note that the print method used a different process to embed the fonts because the font that shows as being embedded in the first pdf file has been changed to X@F338D.tmp (Embedded Subset). We know this is the same font because they are the only files that use encoding: Identity-H.

If I upload this file to the USPTO, it does not display an error.

The bottom line is that the Save As method should be modified to: (1) have an option to re-embed fonts that are allegedly already embedded or (2) embed fonts like the print method so that the font that says it is embedded, but actually is not, gets embedded. Otherwise, the Save As method does not produce a valid PDF/A compliant document because the one font is not actually embedded.

[Paul - Tracker Supp]

Well at least you guys appreciated my Lawyer joke.

I was a bit worried it might offend actually.

Not sure what's going to be the end result of this but I'll keep on them.

[bqxmprij]

The bottom line is that the Save As method should be modified to: (1) have an option to re-embed fonts that are allegedly already embedded or (2) embed fonts like the print method so that the font that says it is embedded, but actually is not, gets embedded. Otherwise, the Save As method does not produce a valid PDF/A compliant document because the one font is not actually embedded.

Hello,

Are there any updates on the (i) font embedding and (ii) dithering algorithm? Looks like mCHSNUg5Pz8cPap discovered fonts being embedded two ways, with one way being superior. Thanks.

[Sean - Tracker]

Hi bqxmprij,

I have asked the team for their input on this issue and we will get back to you with any feedback/information they have

Kind regards,

[David.P]

In this context, I'd be interested to know how the USPTO handles pure black-and-white line drawings that are submitted at higher resolutions, e.g. at 600 or 900 dpi -- should you have tried this already.

The USPTO's website used to say that drawings needed to be "at least 300 dpi" (it also said elsewhere that they "should be 300 dpi"). Up until mid-2020, I filed 1200 dpi drawings thinking that if 300 dpi was good, then 1200 dpi would be fantastic! In mid-2020, I had a few cases in a row where the drawings got mangled to the point that whole pages were blank or had random black marks that looked like chicken scratch. I called the USPTO and they said the drawings need to be 300 dpi (they also said the website was wrong to say "at least 300 dpi"). I filed 300 dpi drawings after that and never had any problems (this is also what set me on the quest to figure out what it would take for the drawings to look good). I haven't had the inclination to press my luck by filing higher resolutions such as 600 dpi or 900 dpi. The hassle of fixing the drawings when they get mangled isn't worth it just to be the guy who figured out the maximum resolution for drawings filed with the USPTO.

FWIW, I just came across a US Patent application (US20230012006) with 900dpi drawings, including rasterized photos.

[Tracker Supp-Stefan]

Hello David.P,

Thanks for the update!

Kind regards,
Stefan

[mCHSNUg5Pz8cPap]

FWIW, I just came across a US Patent application (US20230012006) with 900dpi drawings, including rasterized photos.

I guess I don't understand dpi because when I open the file it says each page is an image that is 2480x3508 and 72x72dpi.

The images in the file don't look too bad. However, they would look better if the applicant had not allowed the USPTO to convert them to 1-bit black and white and instead rasterized them in advance.

[Tracker Supp-Stefan]

Hello mCHSNUg5Pz8cPap,

Is the above sarcasm? Or is some file showing inconsistent/unexpected DPI values?

Yes - the DPI would be the result of calculating the pixel count for the image spread over x,y amount of centimetres on a physical sheet of paper (or the PDF version of such), and that DPI value might differ than what is actually recorded in the image (some image formats do carry 'dpi' information in themselves), as this value is dependent on the way the initial pixels are spread over some distance.

Kind regards,
Stefan

[David.P]

Hello all,

m*Pap is probably right. It seems that the copy that I got is not an original from the USPTO, but that someone has run some OCR software (or something) over it that for some reason has tripled (and smoothed ) the resolution of the images.

However, the images in the original file are all 300 dpi, which is easy to see when you open the "Recompress Images" dialog with any of the images selected.

Thanks
David

[Tracker Supp-Stefan]

[mCHSNUg5Pz8cPap]

Hello mCHSNUg5Pz8cPap,

Is the above sarcasm? Or is some file showing inconsistent/unexpected DPI values?

Lol. No, I'm actually a dummy when it comes to these things . I did some research and now I understand it ... and I understand what was confusing me. If you download the pdf file directly from the USPTO, the page size is something stupid like 35.556 inches by 45.833 inches. So, when I looked at the dpi using recompress images, it showed as 72 x 72.

Now that I understand how it works, I resized the pages to be letter size (you know, the size normal people use and the size I expected it to be) and ... viola! the dpi is now 300 x 300 (roughly).

I never realized the page size of published patent pdf documents is stupid big. I just always thought they were 8.5 x 11. From now on I should be able to carry on a semi-intelligent discussion of dpi values.

[David.P]