See the attached files for more info, the dev team surely has more knowledge on the file structures than I do, and the parser for whatever format is involved.

I have an Illustrator file, created out of an old EPS one. Works fine in Illustrator and everything, exporting to PNG, for example, is no problem.

However if the drawing gets pasted in Word (365, 64-bit 16.0.14228.20288) and one tries to create a PDF out of it using the COM Add-in the drawing isn't interpreted correctly leading to a garbled mess.

Office's internal PDF exporter does a better job, but you can also see how it fails to interpret the drawing, for example in the right side of the images the leaves are not fully covered; but at least it's good enough.

Would it be something that could be addressed in a newer release of Acrobat, or is it a limitation inherent to how it interfaces with Office?

I zipped it all to be able to upload the original EPS, Illustrator's file and an SVG conversion too as well as the Word base file and the two PDF files mentioned, but ZIPs are not allowed.

Just in case I left it all in a ZIP file too (Original EPS included): https://web.tresorit.com/l/gLy71#ARJV94hEWRaqCljglmEwnQ

PS. Could you add EPS and SVG to the mask of approved file types? At least SVG is common enough to be allowed I'd say.

Links are not working after converting a Word document to a PDF. After much troubleshooting, the cause of the issue is the number of pages. Four or more pages works as expected, three or less does not.

To reproduce the issue, create a Table of Contents at the top of the document that links to the Headers of each section. Then Save As Adobe PDF. The expected result is that the Table of Contents will still contain links to the Headers of each section as bookmarks in the new PDF. The observed result is that the links are broken if the document is less than four pages in length. I am using Windows 10/Office16/Adobe Acrobat Pro DC Version 2021.007.20095.

A workaround is to add blank pages to the shorter document to make it at least four pages. This will allow the links to carry over in the conversion. The pages can then be deleted directly from the PDF and the bookmarks will stay. However, this is not an ideal long-term solution.

In the attached documents the only change I made between the two PDFs was to add a blank page at the end.

Several major bugs have been documented by users in the Adobe Community Forums since Acrobat and PDF Maker were updated on September 14, 2021.

They are:

1: Alt-Text from MS Word is not converting into the PDF. Instead, it is dropped and gibberish code is inserted. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017 This violates the PDF/UA-1 standard which requires that every graphic have alt-text that verbally describes the graphic.

THIS IS A HUGE BUG. You essentially have made Acrobat unusable for those who are required by their country's laws to make fully accessible PDFs.

2: Every cell border on every table cell is being tagged as:
<P>PathPathPathPath. This violates PDF/UA-1 because unnecessary visual formatting is not being tagged at Artifacts.
See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017

3: The underline on Hyperlinks should be tagged as artifacts. Right not, it appears as one or more "PathPathPath" which is announced by different assistive technologies. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017

4: Borders and background shadings on Text Boxes are being tagged as a combination of <Figure>s and PathPathPath. This too is a violation of PDF/UA-1. https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017

5: Paragraph borders and shadings: same deal as #4 above.Per the PDF/UA-1 standard, they are visually decorative and should be artifacted. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017

NOTE: To be correctly tagged per PDF/UA-1, the borders/shading content should:
— Not appear anywhere in the Tag tree, either as <Figure> or as "Path" in a yellow content container box.
— Not appear in the Order panel.
— Should appear as Artifact in the Content panel.

6: Dragging and dropping elements in both the Tag and Order panels is now broken.

The text cursor doesn't show anymore, and the little black line doesn't show anymore and instead appears several inches away from where it really is. See https://community.adobe.com/t5/acrobat-discussions/alt-text-converting-wrong-from-word-to-pdf/m-p/12393017 and also https://community.adobe.com/t5/acrobat-discussions/acrobat-pro-reading-order-box-and-tag-dragging-no-longer-visible/m-p/12395226#M329877

And finally...
7: Once this update is installed, users can't revert back to a previous version of PDF Maker because Adobe doesn't allow that in Acrobat like it does with other Creative Suite applications.

So once the update is completed, it makes PDF Maker completely unusable for tagged accessible PDFs.

This affects millions of your government customers world wide, as well as millions of government contractors and millions of academic customers...all of whom are required by their country's laws to make accessible PDFs.

2 sets of sample Word and Matching PDF files are submitted as demonstrations of the problems in the exported PDFs via PDF Maker.

We use Acrobat Pro 2017 Classic on MacOS High Sierra. Before the school holidays, we bought a license for Acrobat Pro 2020 Classic that is installed on the same machine.

We mainly use Acrobat to OCR screenshots and combine them into one PDF. Such a PDF contains between 40 and 200 OCRed pages. Sometimes we use TIFF, sometimes we use PNG as source images that need to be "PDFed".

The workflow is this:
1- Combine source images into one PDF in Acrobat Pro
2- Crop borders of each page in Acrobat
3- Export each page to a directory as a separate pdf file (1)
4- Close (and discard) combined PDF
5- Batch OCR each PDF file in source folder and save the OCRed pdf page in another directory
6- Combine OCRed PDF into one PDF
7- Safe PDF

(1) We do this because we discovered that the OCRed results are better when we ask Acrobat to OCR page by page instead of per multi-page document. Next to this Acrobat has a limit of OCRing 500 pages.

Now that we have Acrobat Pro 2020, we noticed that Acrobat Pro 2017 sometimes mixes up page order. Source images normally have a number like IMG0626.PNG, IMG0627.PNG, IMG_0628.PNG, etc.

The error in Acrobat 2017

This mixup error happens in workflow step 1 when source pages are combined into one PDF in Acrobat Pro. It doesn't matter if we import PNG of TIFF files. The error remains.
In the test set of 46 pages, pages 24 and 25 are swapped. In larger file sets there can be several spontaneous mixups of pages.

Q: Are the sources pages correctly sorted (so page 24 and page 25 are not swapped)?
A: yes. Page 24 and 25 are NOT swapped in the source directory. They are sorted as expected.

Q: Will the same error happen when I replace the file names of the PNG of TIFF files by a sequence number nnn so we get 001.PNG, 002.PNG, 003.PNG?
A: yes

Q: Will the same error occur when I turn toggle bookmark creation when combining?
A: yes

Q: When you combine the OCRed pages back into one PDF, does the mix up happens there also?
A: no

Acrobat 2020 is dead slow combining a pdf (compared to Acrobat 2017). Is it caused by a bug?

Importing a 85MB PNG file takes 3 to 4 seconds per page in Acrobat 2017. In Acrobat 2020 it takes 10 to 11 seconds.
Importing that same source file of about 100MB in (uncompressed) TIFF takes 3 to 4 seconds In Acrobat 2017. In Acrobat 2020 it takes 14 to 16 seconds.
Combing PDF files goes fast in both Acrobat Pro releases.
In both cases Acrobat Pro is installed on the same Mac Pro 2010 running High Sierra on a 1TB SSD disk with plenty (+/- 30%) of free storage. I did reset my Adobe preferences as suggested in the Adobe Acrobat forum.

I really hope that a bug is causing Acrobat Pro 2020 Classic for taking its time to combine source images to a PDF.

OCRing

What seem to go faster is OCRing in Acrobat 2020 compared to Acrobat 2017 when OCRing to editable text and images. OCRing the same set in Acrobat 2017 takes about 32 to 52 seconds. In Acrobat 2020 it takes about 11 to 20 seconds. To be OCRed text language is Dutch.

Rare crash of Acrobat Pro when OCRing

Another error that result in a crash of Acrobat Pro is that it fails to OCR a page. It simply crashes. My source pages have a border that I crop away before OCRing. In most cases when I keep the border at a page Acrobat Pro crashes, Acrobat Pro is -- in most cases -- able to OCR the page.

This is a rare crash. I did not yet come to a page so I can test it in both Acrobat Pro 2017 and 2020 to see if this is a bug related to one or both versions of Acrobat Pro.

I am happy to provide the support team the test set that I used (compressed to a 173MB ZIP file). Unfortunately it contains copyrighted material so I can't attach it just to this ticket.