Are PDF matrices required to be non-degenerate?

[bdoubrov]

Does Arlington model require that all PDF matrices are non-degenerate (= invertible)? As far as I understand, this is not required (but strongly recommended) by ISO 32000-2. See NOTE 3 at the end of 8.3.4:

When rendering graphics objects, it is sometimes necessary for a PDF reader to perform the inverse of a transformation — that is, to find the user space coordinates that correspond to a given pair of device space coordinates. Not all transformations are invertible, however. For example, if a matrix contains a, b, c, and d elements that are all zero, all user coordinates map to the same device coordinates and there is no unique inverse transformation. Such noninvertible transformations are not very useful and generally arise from unintended operations, such as scaling by 0. Use of a noninvertible matrix when painting graphics objects can result in unpredictable behaviour.

[petervwyatt]

My idea of defining matrix as an Arlington type was that this kind of check could be performed since all dictionary entries and array elements that were defined to be matrices would be clearly identifiable in the PDF DOM. Ditto for rectangles too (such as degenerate width and/or height) and maybe some of those are used as matrices. So I do not intend to add predicates for this, if that is the question behind your question.

A lot of matrices are also defined only inside content streams so this wouldn't be a complete check until/unless content streams are also modelled and those matrices are also analyzed. Doing this requires software (not the model itself) to track the CTM and detect at any point if things go bad (I am assuming somewhere there is probably a place where potentially a valid PDF DOM matrix (or a bad rectangle) is multiplied by an invalid content stream CTM that would not be detectable from analysis of the PDF DOM alone). This will need to be part of the modelling of content streams in the future...

Hopefully that answers your questions.

[bdoubrov]

@petervwyatt certainly, the idea of having matrix as a separate type makes sense. The question is rather whether matrices in PDF are required to be invertible (eg., CTM, Annotation, Form XObject matrices, ...) or this is not a requirement, just a recommendation

[petervwyatt]

Clause 8.3.2.1 states "Transformations among coordinate spaces shall be defined by transformation matrices, which can specify any linear mapping of two-dimensional coordinates, including translation, scaling, rotation, reflection, and skewing." and 8.3.3 lists forms of matrices for translation, scaling, rotation and skewing while noting that these things can be combined into a single matrix. So I think from 8.3.2.1 we have a shall...

So, vaguely recalling my uni maths but also deferring to you Prof Math 😀, I think that means that the determinant of Q (= [a b c d]) must equal 1; the transpose of Q is its inverse; the dot product of any Q row or Q column with itself equals one; the dot product of any Q row with any other Q row equals zero; etc. Over to you!

[faceless2]

A degenerate matrix is perfectly normal any time you give anything zero size, and that's not uncommon in PDF (think annotations for invisible signatures). Scaling things to zero is OK - it might not produce any output, but it's mathematically sound. The fact you can't invert it only matters for computing the bounding box, but again - it's zero size, so can be discounted.

Use of a noninvertible matrix when painting graphics objects can result in unpredictable behaviour.

That sentence seems fairly implausible to me. It's trivial. A graphics system that doesn't cope with this wouldn't even pass basic testing.

[petervwyatt]

There are only a handful of places where matrix is used as a type in Arlington: XObjects, Shadings, Patterns, Type3 and FixedPrint, so don't get confused where implementations take other data (e.g. Bounding box rectangle) and then may or may not do something. The spec for annots requires the Rect entry to be zero height/width so there is not a matrix in the DOM per-se. How implementations get from there to their internal CTM is up to them.

[petervwyatt]

BTW I don't intend to add anything further to the Arlington model about the matrix type - I view this as an area implementers can extend if they wish.