PDF export not transferring alt text

#1

Hi everyone,

I am using the McLuhan theme and PrinceXML for my PDF exports.

Does anyone know why the alt text I’ve added to images doesn’t seem to transfer when I export a digital distribution PDF? When I run the Adobe Acrobat Accessibility Checker, it reports that there is no alt text attached to any image, so I end up having to re-enter it in the PDF myself.

Thanks for the input!

Amanda

#2

Hi Amanda! I don’t know the answer more generally, but can look into it. In the meantime, I saw a similar question in the PrinceXML forums. There, the user was asked if they were “enabling a PDF/A profile and using the latest builds of Prince.” Might be a good starting place to check?

1 Like
#3

While I’m investigating, it occurs to me that @jgray might have some insight or relevant expertise here?

1 Like
#4

Hi Steel,

I opened this issue up on github a couple weeks ago:

It seems like PrinceXML has much more accessibility capabilities than we are currently using. Selecting a PDF that style that includes more accessibility options might be good in the long run.

Even if we continue to use the current PDF for Print exports, there may be a strong case to transition to PDF-UA for PDFs for digital distribution. PDF-UA was a profile of PDFs created specifically for accessibility.

I have been able to download Pressbooks and run them through prince using the PDF-UA command, and although I get errors (usually specifically around correct nesting), it creates much better documents that require the least amount of remediation. Ned taught me how to run prince from the command line in this thread, and thats how I can confirm that this will probably work.

2 Likes
#5

Thanks Ed! I’ll bring this to our dev team shortly. Amanda, I suspect that Ed is right and that this may be something we can improve by changing the PDF profile we use to make exports with. I don’t know if there will be other consequences/work needed, though, and we’re just at the beginning of a sprint dedicated to unrelated work, so it may be a few weeks before we have something useful to share.

#6

To enable tagged PDF without using one of the profiles that already imply it, the command-line option --tagged-pdf can be used.

https://www.princexml.com/doc-prince/#pdf-output

1 Like
#7

You’ll want to play around with both PDF profile & PDF output intent.

PDF profile:

PDF output intent (aka ICC profile):

(Then, make similar changes in the Covergenerator )

Here’s some info on PDF profiles:

Here’s some info on PDF output intent:

Note that I’m linking to PrinceXML 12 docs. We’re using PrinceXML 11 (DocRaptor Pipeline 6) on our hosted networks. It doesn’t support as many profiles:

https://www.princexml.com/doc/11/pdf-profiles/

Earlier versions of princexml support less.

On Pressbooks.com, we use the pb_pdf_for_print_profile and pb_pdf_for_digital_profile filters to set PDF/X-4. This enables transparency so that we can include our watermark, so that the watermark doesn’t block background colours.

We could code up a new feature, maybe a select box (dropdown) that let’s you pick your profile and icc:

The big, non-trivial problem with this idea is that it’s complicated. In the past, print-on-demand services we use have rejected our files because we had the wrong settings. We had to scramble to fix things for paying customers who care very much about printing physical books. We’re locked down to what works right now. We’d have to open that can of worms again to get this working.

1 Like
#8

Right, I missed this part. Focus on Digital PDFs. Maybe this is a much simpler solution.

Supported in Prince XML 12. Not supported in Prince XML 11. Would require lots of regression testing.

1 Like
#9

Since you mentioned that you are using Docraptor pipeline 6, you are already probably aware that Docraptor pipeline 7 is also available, uses Prince 12, and supports the tagging and accessibility of PDFs.

Just dropping the link here for future reference.

https://docraptor.com/blog/pipeline-7-with-flexbox-support-and-prince-12/

1 Like