Working with a PDF assembled from multiple PDFs the PDF Accessibity Checker (PAC) throws an error "PAC Unhandled Exception MCID 1 already present."
Is there any way to see and/or fix this issue from within Acrobat or ?? Is the MCID visible within an element's Tag?
What are MCIDs used for and does having duplicate MCIDs cause accessibility issues??
Not an answer, but "MCID n already present" -error appears in PAC (and in axesPDF which contains PAC) as soon as one edits the existing content in a tagged PDF so that some object is somehow rebuilt. Seemingly the tagging is something extra on the basic PDF structure and PDF editing handles tags only with the left hand.
An useful thing to do is to open Acrobat's Content panel which shows the objects, their layering order and tag containers where the objects are placed to.
PAC "MCID n already present" -errors stopped to appear after my PDF edits when I moved possibly soon to be affected objects out of the tag containers in the Content panel and deleted those containers. Then I did my edits, typically moved or changed some text and retagged it.
A person who really knows what Acrobat will do when one make edits maybe could tell which objects could stay in the tag container and move out only those which will be affected by the edits. And then move them back after editing. Moving all content out of the tag container and deleting the empty container, editing and finally retagging in the usual way after the edits has anyway worked.
Related
I'm curious how to make an accessible button for screen readers which downloads PDF.
I know that there is an option using href and pass there an URL to the pdf file, and even a download attribute inside an anchor to open a download window.
But it's not a good way for a screen reader. The screen reader reads it as a link but actually, this is not a link because it triggers downloading a pdf file rather than redirect to another page. So this can be confusing for people with vision disorders who rely on their screen readers.
Is it a good accessibility way to create such a button? Or relying on <a href='path-to-pdf'>...</a> is completely enough and not confusing for people with disabilities ?
General answer and basics of file download
Both a link and a button are perfectly fine, it doesn't make much difference.
IN any case, it's very important to explicitly indicate that the link or button is going to download a file rather than open a page, to avoid surprise.
The simplest and most reliable is just to write it textually, i.e. "View the report (PDF)".
You may also put a PDF icon next to the link to indicate it, but make sure to use a real image, i.e. <img alt="PDF" /> and not CSS stuff, since the later may not be rendered to screen readers and/or don't give you the opportunity to set alt text (which is very important).
A good practice is also to indicate the file size if its size is big (more than a few megabytes), so that users having a slow or limited connection won't get stuck or burn their mobile data subscription needlessly.
It's also good to indicate the number of pages if it's more than just a few, so that people can have an idea on how big it is, and if they really can take the required time to read it.
Example: "View the report (PDF, 44 pages, 17 MB)"
Note that similarly, that's a good practice to indicate the duration of a podcast or video beforehand.
Additional considerations with PDF
First of all, you should make sure that your PDF is really accessible. Most aren't by default, sadly.
You should easily find resources on how to proceed to make a PDF accessible if you don't know.
Secondly, for an accessible PDF files to be effectively read accessibly, it has to be opened inside a real PDF reading program which supports tagged PDFs, like Adobe Reader.
The problem is that nowadays, most browsers have an integrated PDF viewer. These viewers usually don't support tagged PDFs, and so, even if you make an accessible PDF, it won't be accessible to the user if it is open inside that integrated browser viewer.
So you must make sure that your link or button triggers an effective download or opening in a true PDF reading program, rather than opening in an integrated viewer of the browser.
Several possibilities that may or may not work depending on OS/browser to bypass the integrated viewer. They have to be tested to make sure they work:
Send a header Content-Disposition: attachment; filename="something.pdf"
Send a Content-Type different than "application/pdf" or "text/pdf", e.g. "application/octet-stream" to fake out basic type detection
Make the link don't ends with .pdf
Use the download attribute of <a>
The most reliable are response headers. Most browsers don't rely only on file extension alone to decide what to do.
Either a link or a button is fine. The most important thing is that the user is informed about what the element does - i.e. it downloads/opens a PDF file. So, this should be reflected in the element's label, whether that is a visible text label or an icon that uses alt text or aria-label to explicitly describe the element's purpose.
I agree with Quentinc's suggestion to also inform the user upfront about the number of pages and size of the document - that's a nice touch that I don't see very often!
PDF accessibility is a whole other topic, but again as QuentinC points out, there's not much good in allowing a user to download or view a PDF that isn't accessible, so it's a good idea to ensure the PDF has been tested against JAWS/NVDA/VoiceOver/TalkBack to ensure it is readable.
Deleted annotation from pdf but still able to see that annotation in any viewer. What must be wrong in incremental update?
Attached pdf is http://www.filedropper.com/gettingstartedadobeencryptedtempannotations.
Please help me resolve this.
I extracted the former revision of your file and compared the first page of it with the first page of the final revision with each other as seen in Adobe Reader:
The former revision
The final revision
Quite clearly the annotation highlighting "01 Open a PDF from mail or web" is removed in the final revision.
Thus, your observation is at least incomplete, at least Adobe Reader does not show the removed annotation. Please indicate which viewers falsely do.
Furthermore inspecting the incremental update in the document it does look alright. There is just a small peculiarity, the cross reference entry for the single changed object points to the CRLF before the object, not the object itself.
Any viewer unable to cope with this will oftentimes have problems. Viewers actually are known to ignore much worse problems.
The popup for the annotation was not deleted. That's why (depending on the logic of the reader application) there's still a chance that the annotation is shown. At the end the annotation itself still exists and refereces to the page via its P entry (while it is missing in the annotations array):
You can see that the "deleted" comment (blue) is still availabe in the annotation structure:
So at the end you simply have to delete the popup annotation (183), too.
This is not a back-end programming question. I can only modify the markup or script (or the document itself). The reason I'm asking here is because all my searches for appropriate terms inevitably lead to questions and solutions about programming this functionality. I'm not trying to force it via progrmaming; I have to find out why this PDF is behaving differently.
So:
I have a bunch of links to PDFs on a page. Most of them open in new tabs, but one of them, the most recent, starts to open in a tab, but then the tab closes and the PDF gets downloaded as a file instead. All markup is consistent - there's nothing differnt about the odd-man-out except the actual URL.
You can see this here:
http://calwater.mwnewsroom.com/Investor-Relations/Financial-Reports/Annual-Reports
All annual reports up to 2012 open in a new tab, but 2013 downloads instead.
This leads me to believe that there is some meta-data property of the PDF itself that tells it how to open, and that, in this case, the 2013 PDF was created using different settings.
Apparently, the PDF was saved out to PDF from InDesign.
Does anyone have any insight?
Problem solved. There was simply an error in the string (like an extra period) that references the attachment such that it couldn't tell it was a PDF. Fixing the reference fixed the problem.
We have this big web project where the user can print the html to pdf. We are using dompdf, and have somewhat fixed the long cell issues that cause the pdf to have several blank pages. Now the issue is that the saved pdf, when closing, always asks if the user wants to save changes. I have verified that the pdf has the proper %%EOF, and have checked for object consistency. What else could be causing this problem?
After reading this introduction to pdf I realized that if the pdf was modified, I had to accomodate all the object offsets so that they would point to the object start location.
I am tagging a small PDF (4pg), and midway through the second page the tags stopped appearing in the tags and the reading order panel after I chose the tag I wanted via TouchUp Reading Order. If I open the content panel, correct containers are created, so i see:
- Container <H3>Some text
- Container <H3>Some text
- Container <H3>Some text
- Text: Some Text
Does anybody know how to get the three panels synced again?
The PDF mentioned above has some major internal errors, specifically "General Format Errors."
To find these, I ran a PDF Syntax Issue report - which provides details about the PDF in question. This PDF had ~4 pages of errors.
The conclusion was to regenerate the PDF from the source file. (I don't have this yet so I will edit this after I get it.)
To run the Report
Acrobat 9.5- Advanced menu > Print Production > Prefllight. By default, all reports/profiles will be shown. The Syntax Report is under the PDF analysis section, or use the find. Highlight the report then click analyze.
Acrobat X- The Print Production is now a panel, and there is a Preflight section.