LibPDF: Add basic tiled, coloured pattern rendering

[X-yl]

LibPDF vs PDF.js :)

So I've added some basic pattern rendering to LibPDF, mainly targeting Adobe's example on p176 of the spec (pictured above). There's a couple structural-y changes that I'm not too sure about:

• Changing all the ColorSpaces to output PaintStyles instead of Colors: This is so the pattern space can output a PaintStyle that generates the bitmap, but it is a bit overkill for the normal device spaces that have to output a SolidColorPaintStyle.
• The PatternColorSpace sort of blends in with the Renderer code a bit since it has to render the pattern, so I decided to make it a friend class and pass in a reference to Renderer. Not too sure how to structure it tbh.

Also my C++ is a bit rusty (in more ways than one) so let me know if there's better ways to do things :)

[X-yl]

Hmm discovered by tweaking the text matrix of he file I can stop the text clipping:

With a change like this:

--- a/Tests/LibPDF/pattern.pdf
+++ b/Tests/LibPDF/pattern.pdf
@@ -23,7 +23,7 @@ stream
 BT % Begin text object
 0.0 -0.05 TD % Move text position
 /F1 1 Tf % Set text font and size
-55 0 0 55 7.1771 2.4414 Tm % Set text matrix
+55 0 0 55 7.1771 10.4414 Tm % Set text matrix
 0 Tc % Set character spacing
 0 Tw % Set word spacing
 1.0 0.0 0.0 rg % Set nonstroking colour to red

But I'm wondering if that's a bug or if we expect the text matrix to be different because of different fonts or something?

[nico]

This is is super cool!

The PaintStyle change looks extremely clean. However, we use the ColorSpace machinery for transforming images too (cf Renderer::load_image() towards the end) and I worry a bit that creating one PaintStyle object per call to style() will make performance even harder to optimize.

Maybe we should instead just special-case Pattern in Renderer more and do a bunch of is pattern then call style else call color or something like that?

Also, do you think we could pass Renderer to create() and have the Pattern object remember it, instead of passing it to style() all the time?

Finally, the "preferences" object is for user-settable things I think. Maybe we can add a parameter for the bg color?

[X-yl]

Perhaps we could have the style function return a Variant<Color, RefPtr<PaintStyle>> (typedef'd to something less clunky ideally) and then branch on whether it produced a RefPtr<PaintStyle> or a Color?

[X-yl]

Made changes based on feedback :)

I do recognise the difference in semantics between checking if the ColorSpace is pattern and then calling style() or else color() versus having style() returning Variant<Color, PaintStyle> but I think it's a bit cleaner (as opposed to stubbing out style() for almost every ColorSpace) and performance wise is they should be exactly the same since the branch predictor would quite easily predict what each ColorSpace returns?

[nico]

This is great!

lgtm as-is; some pontificating below (but feel free to ignore; up to you).

[nico]

Also, I don't remember if Serenity's PDF viewer supports page zoom (MacPDF doesn't yet). Might be worth thinking about if the pattern rasterization applies zoom at the right layer, so that zooming in doesn't make the pattern pixelated.

[X-yl]

Also, I don't remember if Serenity's PDF viewer supports page zoom (MacPDF doesn't yet). Might be worth thinking about if the pattern rasterization applies zoom at the right layer, so that zooming in doesn't make the pattern pixelated.

So the way I decided on the size for the bitmap for rasterization was to take the pattern bounding box and transform it to device space with the CTM (ETA: after first mapping it to user space with the pattern matrix). This seems to handle scaling nicely, and intuitively I think it's right, but frankly I did a lot of throwing random matrices at the wall to see what stuck so I could be missing something.