Currently we're not applying Patterns for text, but only for graphics.
This patch is unfortunately not a complete solution, but rather a step on the way, since there are still some PDF files where the Patterns look more like a solid colour, rather than the intended gradient.
I've been unable to fix these issues completely, and I've not managed to determine if the remaining issues are caused either by the pattern code, the canvas code, or perhaps both.
However, given that even this simple patch improves the current situation quite a bit, I figured that it couldn't hurt to submit it as-is.
- Fixes 5804.
- Fixes 6130.
- Improves 3988 a lot, since the text is now visible. However, it looks like the text is *one* solid colour, instead of the correct gradient.
- Improves 5432, since the text is no longer gray. (This file also suffers from the same problem as the previous one.)
We should never actually try to execute `paintXObject` in canvas.js, but in some cases where we fail to parse the PDF file correctly it can happen. Currently this will potentially cause an entire page to fail to render, which seems suboptimal.
With this patch, we will instead continue rendering with a warning that things might not work correctly.
According to the PDF spec 5.3.2, a positive value means in horizontal,
that the next glyph is further to the left (so narrower), and in
vertical that it is further down (so wider).
This change fixes the way PDF.js has interpreted the value.
Currently non-embedded ArialBlack fonts are not rendered bold enough, compared to e.g. Adobe Reader.
The issue is that we set the font weight to `bolder`, but since that is actually relative to the font weight of the parent, the result is that there's no practical difference from just using `bold`.
This patch attempts to address that, by explicitly setting the font weight to the maximum value instead (see https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight).
*Note:* I expect one test "failure" in `issue5801`, which in this case is an improvement, since that PDF file uses ArialBlack.
Set transformation matrix in (polyfilled) mozPrintCallback when a scale
is applied. Removed _scaleX and _scaleY in favor of _transformMatrix to
emphasize that the caller MUST ensure that the state of the matrix is
correct before `addContextCurrentTransform` is called.
maskData comes out of maskCtx.getImageData, so is 0..255 clamped, and
the used multiplications will not create fractions needing rounding,
neither would addition.
