On Wed, 25 Dec 2024 at 15:04, Norbert Preining <preining@logic.at> wrote:

Hi Hans,

On Wed, 25 Dec 2024, Hans Hagen wrote:
> It's a GS issue ... it can't handle an in itself valid

Might be, but the statement:
> │ **** file that it does not conform to Adobe's published PDF
> │ **** specification.

says something different. I am not sure about the PDF spec here, but if
an empty beginbfrange is not allowed per spec, then luatex should not
produce it.

hm , I always consider such messages from GS but I prefer verapdf.

In this case we can start from

pdf-a1b-2005.mkiv

copy the icc profile from CTAN /support/colorprofiles/sRGB.icc into texmf-dist/tex/context/colors/icc/sRGB.icc

run context --luatex pdf-a1b-2005.mkiv

run verapdf pdf-a1b-2005.pdf

that should say

make a qdf with qpdf -qdf pdf-a1b-2005.pdf pdf-a1b-2005.qdf
edit pdf-a1b-2005.qdf adding

0 beginbfrange
endbfrange

fix qdf with fix-qdf pdf-a1b-2005.qdf >pdf-a1b-2005.qdf.pdf
and finally run verapdf pdf-a1b-2005.qdf.pdf :
<validationReport jobEndStatus="normal" profileName="PDF/A-1B validation profile" statement="PDF file is compliant with Validation
Profile requirements." isCompliant="true">
<details passedRules="128" failedRules="0" passedChecks="814" failedChecks="0"></details>
</validationReport>

But even in this case, if I change

1 beginbfrange
endbfrange

I still have a

<validationReport jobEndStatus="normal" profileName="PDF/A-1B validation profile" statement="PDF file is compliant with Validation

Profile requirements." isCompliant="true">
<details passedRules="128" failedRules="0" passedChecks="814" failedChecks="0"></details>

</validationReport>

but a "warning" message ( not in the report ! )

Dec 27, 2024 12:50:01 PM org.verapdf.pd.font.cmap.CMapFactory getCMap

WARNING: Can't parse CMap CMap 19 0 obj, using default
java.io.IOException: CMap contains invalid entry in bfrange. Expected TT_HEXSTRING but got TT_KEYWORD

One could say that the pdf is not valid because it's malformed, and verapdf is wrong here.

luigi