Size 0 dots are large and visible

This has been reported in the Ubuntu bug tracker by wch: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/902033

It is reproducible on Ubuntu 11.10 with evince 3.2.1-0ubuntu2 and epdfview 0.1.8-1 (poppler 0.16.7-2ubuntu2)

Ubuntu bug report:
I'm creating some PDF files with dots of 0 size. In evince, they're visible: they're pretty large and off-center. In other viewers, such as Mac Preview and Adobe Reader on Mac, the dots are not visible.

This code will generate a test file in R. There is a line of 10 dots going from lower left to upper right that should be visible. There's another line of 0mm dots going from upper left to lower right, and they should not be visible.

library(grid)
pdf("dotsizetest.pdf", width=4, height=4)
x <- y <- 1:10
pushViewport(plotViewport(c(5.1, 4.1, 4.1, 2.1)))
pushViewport(dataViewport(x, y))
grid.rect()
grid.points(x, y)
grid.points(x, 10-y, gp=gpar(fill="black"), size=unit(0,"mm"))
popViewport(2)
dev.off()

EXPECTED RESULT:
One diagonal line of dots

ACTUAL RESULT:
Two crossing diagonal lines of dots.

The PDF can be found here: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/902033/+attachment/2625606/+files/dotsizetest.pdf

Both the splash and the cairo renderer show the second line, but it is true that the cairo renderer has much worse results than the splash one (the second line in splash at least is just 1px wide)

Created attachment 56143
cairo - don't render text when text matrix is not invertable

The problem is the PDF file is using a noninvertible text matrix [0 0 0 0]. The PDF specification has this to say about noninvertible matrices:

   When rendering graphics objects, it is sometimes necessary for a
   conforming 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.

So the correct rendering of this PDF file is undefined. However to make the cairo output more closely emulate acroread behavior I attach a patch that ignores text when the text matrix is noninvertible.

Any plans to merge this patch to mainline>

I can still reproduce this bug on poppler 0.24.5.