Estimated read time: 2 minutes
This is how the export result looked like:
And this is how it now looks like, after fixing:
For a long time the PDF export filter had no tests at all; the current approach I introduced is that we parse the PDF export result with pdfium, which is an excellent PDF rendering library (I covered it in general in an earlier post).
So given that pdfium knows how that rectangle looks like, we should be able to query the details of it from a test as well, correct? It depends. Yes, it’s possible technically, but no, most of the pdfium functionality is actually not exposed at its public API.
The current situation is that one could use
FPDF_LoadPage() to get access to a PDF page, then
FPDFPage_GetObject() to iterate over objects on a page. We can filter for the
relevant object by using
that will give us the only path that has a yellow fill color.
But getting more info about the geometry of the path isn’t really possible. As
a workaround I went with
FPDFPageObj_GetBounds() for the test, but wouldn’t it
be nicer to get the individual segments (the objects that are the children of
a path) and then get coordinates and other properties of a segment? This is
what the recent API I added to pdfium now does. It provides the followings:
FPDFPath_CountSegments()gives you the number of segments of a path
FPDFPath_GetPathSegment()gives you a given segment, via a new
you can use
FPDFPathSegment_GetPoint()to get the coordinates,
FPDFPathSegment_GetType()to get the type (move to, line to, etc.) and
FPDFPathSegment_GetClose()to see if the segment closes the current subpath of the path (or not)
This means that after the next pdfium update in LibreOffice, PDF export tests can nicely assert these properties of paths instead of dubious bounding box should be larger after rotation assertions.