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

[Harie Amjari]

Here, I have created two repository, https://gist.github.com/harieamjari/
d4c634ce2ddb2c6e6c666a3985de2909 and https://gist.github.com/harieamjari/
c4aeac23ac0fecd8d938a7a03118b743

The former contans a pdfa compliant document while the latter contains a
nonpdf/a compliant document.

Each of this repository can be compiled online with latexonline.cc. Here is
the them respectively:

https://texlive2020.latexonline.cc/compile?git=https://gist.github.com/
harieamjari/d4c634ce2ddb2c6e6c666a3985de2909.git&target=t.tex&command=
pdflatex&force=true&download=outpdfa.pdf output contains pdfa compliant pdf.

https://texlive2020.latexonline.cc/compile?git=https://gist.github.com/
harieamjari/c4aeac23ac0fecd8d938a7a03118b743.git&target=t.tex&command=
pdflatex&force=true&download=outnonpdfa.pdf output contains non pdfa
compliant pdf.

The result for outpdfa.pdf from verapdf.com is it passed the verification
while the outnonpdfa.pdf has failed.

You can verify yourself the pdfa.pdf and nonpdfa.pdf from each gist
repository.

On 19 Nov 2021 22:25, "suzuki toshiya" <mpsuzuki at hiroshima-u.ac.jp> wrote:

> 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<ma
>> ilto: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_*`?
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20211120/b8757433/attachment-0001.htm>