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

[suzuki toshiya]

Dear Harie,

BTW, have you confirmed that if PDF/A document is embedded via includegraphics macro, the whole document becomes PDF/A?

On 2021/11/19 23:15, suzuki toshiya wrote:
> 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_*`?
> 
>