Matrix::getShearY() - does it return the correct value?

Hi, I do have a question concerning the class Matrix and its function getShearY(). When a new object of class Matrix is created from a PDF document the constructor takes the COSArray of the PDF document and initializes the member variable float[] single with single[1] = ((COSNumber)array.getO

Re: PDFA extension value type case sensitivity

As Tilman said, my question was about the casing of value types (Text, Integer etc) and in this case the `choice`. I also saw the one with "closed" and "Closed" - did also not help with my overall confusion :D (VeraPDF seems to ignore the casing because they claim the PDF with the above XMP metada

Re: PDFA extension value type case sensitivity

Hi Peter, This one is not about the conformance levels, he has closed *c*hoice of Text in his zf schema definition (first posting), but we expect closed *C*hoice of Text and it's not even sure if we're correct there or should accept any case. Tilman On 04.04.2025 13:29, Peter Wyatt wrote:

RE: PDFA extension value type case sensitivity

Don't confuse the specification of the XMP serialization with the use of XMP as separately defined by the ISO standards such as PDF/A. The correct answer here is specified in the PDF/A (ISO 19005) standards (specifically ISO 19005-3:2012 for ZUGFeRD e-invoices). ISO 19005-3:2012, Table 8 "PDF/A

Re: PDFA extension value type case sensitivity

Not that Tilman needs it, but to support his point, we use JempBox in Apache Tika because it is much more relaxed. On Fri, Apr 4, 2025 at 5:55 AM Tilman Hausherr wrote: > Hi, > > It gets weirder, I found the XMP specification, sometimes they write > "closed Choice", sometimes "Closed Choice". >

Re: PDFA extension value type case sensitivity

Hi, It gets weirder, I found the XMP specification, sometimes they write "closed Choice", sometimes "Closed Choice". I could change it, but it's possible you'd get other problems with xmpbox anyway. You can try Jempbox which is also from us, but has a smaller API and is more relaxed (xmpbox

PDFA extension value type case sensitivity

Hi all, i have a question regarding parsing PDFA extension data with xmpbox and the DomXmpParser. I did not find a concrete answer to it in the xmp specs. Are the value types case sensitive? We received a ZugFERD pdf and i tried to read the xmp metadata with xmpbox but it fails because of an unkn