[cairo] Fwd: Feature request: PDF/A compliant pdf?

[suzuki toshiya]

FYI: I found that I received the off-list reply from Harie.

-------- Forwarded Message --------
Subject: Re: [cairo] Feature request: PDF/A compliant pdf?
Resent-From: mpsuzuki at hiroshima-u.ac.jp
Date: Fri, 19 Nov 2021 01:12:16 +0000
From: Harie Amjari <healer.harie at gmail.com>
To: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>

I'm using graphviz to produce pdf files which I incorporate my tex file with `\includegraphics{o.pdf}` along with `\usepackage[a-1b]{pdfx}` at the preamble of the tex file (and since graphviz uses cairo in the writing of the pdf, the whole document becomes non pdf/a compliant even though i've included `\usepackage[a-1b]{pdfx}`)

On the other hand, if I don't include `\includegraphics{o.pdf}` then the whole document produced by latex becomes pdf/a compliant, but if I tries to include it, then my whole document becomes non pdf/a compliant.

More https://gitlab.com/graphviz/graphviz/-/issues/2155

On 19 Nov 2021 08:50, "suzuki toshiya" <mpsuzuki at hiroshima-u.ac.jp<mailto:mpsuzuki at hiroshima-u.ac.jp>> wrote:
Dear Harie,

I've seen the documentation at https://www.cairographics.org/manual/cairo-PDF-Surfaces.html and so far it does not mention any support for compliant in PDF/A, other than the https://www.cairographics.org/manual/cairo-PDF-Surfaces.html#cairo-pdf-metadata-t which is required by the specification to be filled up, I believed. Is this feature possible? (to implement?)

Please could you tell me the background why you (or somebody else) require PDF/A support in cairo?
Are you developing some applications using cairo and want to emit PDF/A from your application?

There are many applications using cairo, but I guess, if cairo adds a support for PDF/A, most applications would not add new switch to use new APIs...

Possibly a function like `cairo_pdfa_*`?

I don't think the introduction of new surface and the huge set of new API is the best way.
If it would happen in future, the extension of the cairo_pdf_version_t enum would be mild solution.

--

Taking a glance on https://en.wikipedia.org/wiki/PDF/A#Description ,
it would not be so hard to ignore the prohibited contents (like JPEG2000 in PDF/A-1... oh, there's no prohibition for JBIG2 content?), but the problem would be that the metadata is classified as mandatory.

If future cairo library requests as "please give me XMP metadata to be embedded in PDF/A - if not, I cannot emit PDF/A", the application programmers can pass some appropriate XMP as "ok, here it is"? I'm afraid they would complain "oh, I don't understand what I should do. My interest is only the passing of the validation by the PDF/A validator which I'm asked to use. cairo should create the XMP by itself, even if its content is filled by blahblahblah".

Similar issues would happen for the requests of "Language specification", "Hierarchical document structure", "Tagged text spans and descriptive text for images and symbols". How do you think about these requirement?

Regards,
mpsuzuki

On 2021/11/18 22:53, Harie Amjari wrote:
I've seen the documentation at https://www.cairographics.org/manual/cairo-PDF-Surfaces.html and so far it does not mention any support for compliant in PDF/A, other than the https://www.cairographics.org/manual/cairo-PDF-Surfaces.html#cairo-pdf-metadata-t which is required by the specification to be filled up, I believed. Is this feature possible? (to implement?)

Possibly a function like `cairo_pdfa_*`?