The one current caller of this function always defers microtask
checkpoints before calling wait_for_all, ensuring that the promise
accept/reject handlers will always be called later in the Web event loop
processing. We need to store all the state for the closures in a heap
allocated object with HeapFunctions to keep it around while there are
still promises to resolve.
We need to make sure that the given target realm is at the top of the
VM's execution context stack before doing any JS object construction
based on the data in our serialized buffer.
Window and other global objects are not technically legacy platform
objects, and have other ways to override their setters and getters.
However, Window does need to share some code with the legacy platform
object paths, and simply adding another bool check to the mix seems
the shortest putt.
Prior to this change, we iterated through all fragments within each
PaintableWithLines to resolve the relative position offset. This
happened before transferring the fragments to their corresponding
inline paintables.
With this change, we significantly reduce amount of work by attempting
to resolve relative position offsets only for those contained within
inline paintables.
Performance improvement on https://html.spec.whatwg.org/
We still don't apply it to the glyph itself, so they don't show up
scaled or rotated, but they're at the right spot now.
One big thing this here hsa going for it is that the final glyph
position is now calculated with just
`ext_rendering_matrix.map(glyph_position)`.
Also, character_spacing and word_spacing are now used unmodified
in the SimpleFont::draw_string() loop. This also means we no longer
have to undo a scale when updating the position in
`Renderer::show_text()`.
Most of the rest stays pretty yucky though. The root cause of many
problems is that ScaledFont has its rendering sized baked into the
object. We want to render fonts at size font_size times scale from
text matrix times scale from current transformation matrix (but
not size from hotizontal_scaling). So we have to make that the
font_size, but then we have to undo that in a bunch of places to
get the actualy font size.
This will eventually get better when LibPDF moves off ScaledFont.
Fonts should have size font_size times total scaling. We tried to
get that by computing text_rendering_matrix.x_scale() * font_size,
but text_rendering_matrix.x_scale() also includes
horizontal_scaling, which shouldn't be part of font size.
Same for character_spacing and word_spacing.
This is all a big mess that's caused by LibPDF using ScaledFont,
which requires scaling to be aprt of the text type. I have an
in-progress local branch that moves LibPDF to directly use VectorFont,
which will hopefully make this (and other things) nicer. But first,
let's get this right, and then make sure we don't regress it when
things change :^)
While PDFFont::draw_string() already returns a position scaled by
horizontal_scaling, the division by text_rendering_matrix.x_scale()
(which also contains the scaling factor) undid it. Reapply it.
Fixes the horizontal layout of the line
"should be the same on all lines: super" in Tests/LibPDF/text.pdf.
PDF spec 1.7 5.3.3 Text Space Details gives the correct multiplication
order: parameters * textmatrix * ctm.
We used to do text * ctm * parameters
(AffineTransform::multiply() does left-multiplication).
This only matters if `text_state().rise` is non-zero. In practice,
it's almost always zero, in which case the paramter matrix is a
diagonal matrix that commutes.
Fixes the horizontal offset of "super" in Tests/LibPDF/text.pdf.
These set the horizontal scale factor, character spacing, word
spacing, and text rise respectively.
Also add a global scale transform, and set a text transform matrix
with a scale for some of the text.
Type 2 <=> One-dimensional Group3, customized for TIFF
Type 3 <=> Two-dimensional Group3, uses the original 1D internally
Type 4 <=> Two-dimensional Group4
So let's clarify that this is not Group3 1D but the TIFF variant, which
is called `CCITTRLE` in libtiff. So let's stick with this name to avoid
confusion.
This patch removes the explicit compile flag that only works for g++
(`-fdiagnostics-color=always`; clang++ needs `-fcolor-diagnostics`) and
uses CMake's built in variable that can control color output.
Now both compilers should output colored diagnostics.
Images with a display mask ("stencil" as it's called in DPaint) add
an extra bitplane which acts as a mask. For now, at least skip it
properly. Later we should render masked pixels as transparent, but
this requires some refactoring.
The vertical coordinates for truetype fonts are different somehow.
We compensated a bit for that; now we compensate some more.
This is still not 100% perfect, but much better than before.
Since we can't clip against a general path yet, this clips images
against the bounding box of the current clip path as well.
Clips for images are often rectangular, so this works out well.
(We wastefully still decode and color-convert the entire image.
In a follow-up, we could consider only converting the unclipped
part.)
