I implemented CFF charset format 2 in 6f783929dd with the note
"I haven't seen this being used in the wild". Now that I have
seen it (0000658.pdf), I can say that this has never worked,
despite me claiming "it's easy to implement".
But now it works!
We now reject fonts where the active cmap subtable is in a format
we can't read yet, instead of silently drawing squares for all glyphs.
This doesn't fire at all for my 1000-file PDF test set, but seems
like a good thing to check.
(Instead of duplicating the switch, I first tried making a
glyph_id_for_code_point_or_else() that returns ErrorOr<u32> and then
make both glyph_id_for_code_point() and validate_format_can_be_read()
call that, but I liked less how that worked out -- felt too clever.)
This would've saved me some debugging on #23103.
We now return an error instead of a font that draws squares for all
characters. That seems preferable since it makes these cases easy to
find. This fires for three files in my 1000-file PDF test set, so it's
not exceedingly common (...but I wasn't aware that three files were
rendering boxes for this reason, and now I am and can just make them
work in the future).
Before this change, `set_needs_to_resolve_paint_only_properties()` was
only called after style invalidation. However, since relayout can be
triggered independently from style invalidation, we need to ensure that
paint-only properties are updated in that case too.
Automarks are similar to bookmarks placed by the terminal, allowing the
user to selectively remove a single command and its output from the
terminal scrollback.
This commit implements a single way to add marks: automatically placing
them when the shell becomes interactive.
To make sure the shell behaves correctly after its expected prompt
position changes, the terminal layer forces a resize event to be passed
to the shell on such (possibly) partial clears; this also has the nice
side effect of fixing the disappearing prompt on the preexisting "clear
including history" action: Fixes#4192.
This is a bit tangled in that updating these functions involves a slew
of other spec changes.
However those spec updates fix a bunch of rounding issues, fixing 32
test cases.
Diff Tests:
+32 ✅ -32 ❌
This has the guts of the old temporal AO BalanceDuration with some
differences such as an extra precision of one unit. This appears to be
important for different rounding modes to act as a tiebreaker.
It also does not have any logic regarding a zoned date time 'relative
to' - the spec seems to have this factored in a way where callers are
expected to perform this logic if neccessary.
`x.size()` is 3 or 4 in practice and at most 15 in theory
(cf `number_of_components_in_color_space()` in Profile.cpp),
so using a VLA for these should be fine from a stack size PoV.
It's only accessed through a span, so there's no additional
security risk.
Takes
Build/lagom/bin/image --no-output \
--assign-color-profile \
Build/lagom/Root/res/icc/Adobe/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
cmyk.jpg
from 2.74s to 2.66s on my machine, almost 3% faster.
(Don't do this in LibPDF's SampledFunction::evaluate() since there's
no bound on the dimension of the input function. Realistically,
size of the table puts a pretty low bound on that dimension though,
so we should probably enforce some bound in SampledFunction::create()
and do this there too.)
`x.size()` is 3 or 4 in practice and at most 15 in theory
(cf `number_of_components_in_color_space()` in Profile.cpp),
so using a VLA for these should be fine from a stack size PoV.
They're accessed from two local loops iterating from 0 to
`x.size()`, so it's hopefully not too risky from a security
PoV either.
Takes
Build/lagom/bin/image --no-output \
--assign-color-profile \
Build/lagom/Root/res/icc/Adobe/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
cmyk.jpg
from 2.81s to 2.74s on my machine, about 2.5% faster.
Implements following rule from CSS Overflow Module Level 3:
"The visible/clip values of overflow compute to auto/hidden
(respectively) if one of overflow-x or overflow-y is neither visible
nor clip."
When WebDriver asks to destroy a window, we can hit this case with no
active browsing context. This seems odd, but perhaps is a spec issue as
well. Just log to dbgln for now.
This aligns it better with the current state of the spec.
There's still some functions and data members that need moved into
Navigable or TraversableNavigable, but we can leave those for the next
cleanup PR.
This check has been if (false && stuff) for quite a while, since the
transition to Navigables. No one updates the BrowsingContext's session
history, so the check for it having an about blank document and only an
about blank document is always false.
Previously, if we wanted to to e.g. do linear interpolation in 2-D,
we'd get a sample point like (1.3, 4.4), then get 4 samples around
it at (1, 4), (2, 4), (1, 5), (2, 5), then reduce the 4 samples
to 2 samples by computing the combined samples
`0.3 * f(1, 4) + 0.7 * f(2, 4)` and `0.3 * f(1, 5) + 0.8 * f(2, 5)`,
and then 1-D linearly blending between these two samples with the
factor 0.4. In the end we'd multiply the first value by 0.3 * 0.4,
the second by 0.7 * 0.4, the third by 0.3 * 0.6, and the third by
0.7 * 0.6, and then sum them all up.
This requires computing and storing 2**N samples, followed by
another 2**N iterations to combine the 2**N sampls to a single value.
(N is in practice either 4 or 3, so 2**N isn't super huge.)
Instead, for every sample we can directly compute the product of
weights and sum them up directly. This lets us omit the second loop
and storing 2**N values, in exchange for doing an additional O(n)
work to compute the product.
Takes
Build/lagom/bin/image --no-output --invert-cmyk \
--assign-color-profile \
Build/lagom/Root/res/icc/Adobe/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
cmyk.jpg
form 3.42s to 3.08s on my machine, almost 10% faster (and less code).
Here cmyk.jpg is a 2253x3080 cmyk jpeg, and USWebCoatedSWOP.icc is an
mft2 profile with input tables with 256 samples and a 9x9x9x9 CLUT.
The LibPDF change is covered by TEST_CASE(sampled) in LibPDF.cpp,
and the LibGfx change is basically the same change as the one in
LibPDF (where the test results don't change) and the output
subjectively looks identical. So hopefully this causes indeed no
behavior change :^)
The IPC layer between chromes and LibWeb now understands that multiple
top level traversables can live in each WebContent process.
This largely mechanical change adds a billion page_id/page_index
arguments to make sure that pages that end up opening new WebViews
through mechanisms like window.open() still work properly with those
extra windows.
