Which metadata properties do you wish to include?

Hi Mike,

Actually, I want add the attached xml xmp meta into pdf properties. Please look into this file and guide us.

Thanks & Regards,
Chella|TNQ Technologies
+91 98 84 504995

1. sample.xml‎ 2.6 kB ‎
   xmp meta xml

Hmm which do you think would be more convenient for you: providing this metadata as a single XML file, or setting individual metadata properties via the Prince JavaScript interface? The reason I ask is that Prince also has to add its own metadata needed for PDF/A or PDF/X, and ensure that the XMP metadata is consistent with the title/author/creator properties in the document catalog, so it is slightly complex.

Hi Mike,

Thank for your frequent reply, single xml file is convenient for us.

Thanks & Regards,
Chella|TNQ Technologies
+91 98 84 504995

Hi,

How can I include xmp meta data with single xml?

Thanks & Regards,
Chella|TNQ Technologies
+91 98 84 504995

Edited 26 Aug 2015 by Chella

This is not possible yet, we will need to extend Prince to add new features to support this.

Hi Mike,

Thank you for your reply!

In your earlier reply, you mentioned there are two ways to include xmp meta data in prince pdf,

1 Single xml file feed
2 Setting individual metadata properties via the Prince JavaScript interface

So, I thought the feature is available in prince. May I know both the options(above) are taking up in support request or 2 option is already available in current version? If so, how can I do it?
Note: I'm talking about only xmp meta data not default properties like subject/keywords/title etc.

Thanks & Regards,
Chella|TNQ Technologies
+91 98 84 504995

We have not implemented either of these yet, I was asking because I wasn't sure which one would be more helpful.

Oh Thank you! mike. We feel xml file is convenient for us.

Thanks & Regards,
Chella|TNQ Technologies
+91 98 84 504995

Okay we will investigate this feature.

I was wondering if there is any updates on this feature?

Not yet, currently we are focusing on PDF/X profile and color management.

I saw that the first question about accessibility was placed in 2005, it's now 2017 and correct me if I'm wrong but Prince still don't generate an accessible PDF. As you know we have to deal with legislation and as a bank we can't afford that we exclude customers. So I ask the the same question again when can we expect a change in that direction?
If we have to wait another 12 years we are forced to look for another solution. I'm looking forward to your reaction.

It's been a long 12 years for us too -- this feature haunts our dreams and sometimes our nightmares.

We have some new ideas to try, so hopefully we will be able to deliver it this year.

Any update on this? We periodically get requests from customers with accessibility needs - and are unable to accomodate them at this point.

Yes we are making progress and still expect to deliver support for tagged PDF this year.

It was a close run thing but the latest build now has support for Tagged PDF via the PDF/A profiles (PDF/A-1a, PDF/A-3a), finally delivered 12 years after the original request.

Is there some documentation on how to create a properly tagged PDF with PrinceXML?
When I enable one of the above with the command line option
--pdf-profile="PDF/A-1b"
then open the resulting PDF in Adobe Acrobat Pro and do a "Full Check" regarding accessibility, it reports the document is not tagged.

PDF/A-1b is not tagged, you need to use PDF/A-1a or PDF/UA-1 with a recent latest build of Prince.

Ah, I see, thank you. I downloaded the latest build (prince-20171214-win64.zip) and it worked successfully.

Is there a reason neither PDF/A-1a nor PDF/UA-1 are mentioned on the PDF profiles page?

Sorry about that, the documentation will be updated for the release of Prince 12, due soon.

I am evaluating latest Prince 12 ability to support accessibility before making decision to use prince or other tools.

So, java, setPDFProfile("PDF/A-1a"), when i generate PDF that has header and footer. Adobe Acrobat Pro says anything in header and footer is not tagged.
so, what is the solution for this?

1. Capture.PNG‎ 23.0 kB
2. testADA (3).html‎ 0.4 kB

Edited 17 Jan 2019 by foo

You can target PDF/UA-1 or combined PDF/A-1a+PDF/UA-1, which will explicitly tag headers and footers as pagination Artifacts. We will consider doing this for all tagged PDF in future.

This change has been made in Prince 12.5, available now.

So, if you're using PDF/UA-1 with version 13, but your headers and footers are still not tagged in Adobe, what options would you suggest to troubleshoot the cause?

Is there a reason that using page-groups or running headers would break this?

Can you provide a small example? Headers and footers should be marked as pagination Artifacts.

Sure. I've attached a streamlined version of our scss file, examples of the generated html and a screen capture of the reading order for the generated statement.

We have a list of sections defined in an scss variable, we then loop through those sections and assign either the section header or section subheader.

We're calling prince through the command line with exec

async function callPrince(htmlPath, pdfPath, licensePath) {
  const command = [
    getPrinceBinaryPath(),
    htmlPath,
    '--page-margin=0',
    '--page-size="letter landscape"',
    '--raster-threads=1',
    '--no-system-fonts',
    '--pdf-profile=PDF/A-1a+PDF/UA-1',
    `--license-file=${licensePath}`,
    `-o ${pdfPath}`,
  ].join(' ');
  await promisify(exec)(command);
  return null
}

1. Screen Shot 2021-02-15 at 10.18.32 AM.png‎ 56.9 kB ‎
   screen capture of reading order
2. example-statement.scss‎ 1.6 kB ‎
   streamlined .scss file
3. header-subheader_examples.html‎ 0.7 kB ‎
   examples of the generated html

If I understood correctly, you are expecting the "Royalty Statement" and "February 2020" headings to be tagged and show up in the reading order.

As those headings come from elements that have been removed from the normal flow and placed into page header regions, their contents will be marked as pagination Artifacts (i.e. not "real content") and won't show up in the reading order. This is normally desirable as you don't want screen readers to read out running headers, page numbers, and so on.

There is currently no way to tell Prince to treat the contents of header and footer page regions as real content, but we are considering it.

That makes sense. Thank you.