The old implementation of PassMode has only been tested with a single
image, and let's say that it didn't survive long in the wild. A few
cases were not considered:
- We only supported VerticalMode right after PassMode.
- It can happen that token need to be used but not consumed from the
reference line.
With that fix, we are able to decode every single PDF file from the
1000-file zip "0000" (except 0000871.pdf, which uses byte alignment).
This is massive progress compared to the hundred of errors that we were
previously receiving.
This works very similarly to MarkedVector<T>, but instead of expecting
T to be Value or a GC-allocated pointer type, T can be anything.
Every pointer-sized value in the vector's storage will be checked during
conservative root scanning.
In other words, this allows you to put something like this in a
ConservativeVector<Foo> and it will be protected from GC:
struct Foo {
i64 number;
Value some_value;
GCPtr<Object> some_object;
};
Transforms are applied to both clip rectangle and position, so we need
to remove the transform from clip rectangle before checking if position
falls within the clip rectangle.
In this change, the removal of transform is moved into
`Paintable::clip_rect()` that is shared between hit-testing and
painting.
This change fixes hit-testing in Discord's multifactor authentication
form.
If the layout has been recalculated and the sizes of scrollable
overflow rectangles could have changed, we need to ensure that scroll
offsets remain within the valid range.
By moving scroll offset clamp from `PaintableBox::scroll_by()` to
`PaintableBox::set_scroll_offset()`, we ensure that updates from
`Element::set_scroll_top()` and `Element::set_scroll_left()` are
constrained to a valid range.
Both type 1 and type 2 spec tell us to do this.
I haven't observed a difference from this, but I noticed it in the
spec while I was touching this code. Probably good to do what the
spec tells us to do.
With this, a character can be defined that uses two existing glyphs.
This is useful for umlauts and the like, which then just need to
reference e.g. the glyphs named "a" and "dieresis" and provide a
translation.
Makes umlauts appear on some PDFs using CFF type2 data in Type 1
fonts.
This allows ports to access the OpenGL headers using `#include
<GL/gl.h>` and find the shared library at `/usr/lib/libGL.so` or
`/usr/lib/libGL.so.1`, removing the need for explicit include paths or
changed library names.
Before, TEST_MAIN used to return the return value of TestSuite::main()
function (which returns the number of test cases that did not pass, so
it can be >=256) directly.
The run-tests utility determines the success / failure of a test suite
binary by examining its (or i.e. TEST_MAIN's) exit status.
But as exit status values are supposed to be between 0 and 255, values
>=256 will get wrapped around (modulo 256), converting a return value of
256 to 0.
So, in a rare case where exactly 256 test cases are failing in your test
suite, run-tests utility will display that the test suite passed without
any failures.
Now, TEST_MAIN just returns 0 if all of the test cases pass and returns
1 otherwise.
Ceiling width or height of a chrome viewport (this function is only used
when a chrome notifies LibWeb about a new viewport size) is never
correct. If we do that, PageClient::page_did_layout will set content
size to be 1 larger than an actual physical width or height respectively
(it always ceils) and thus a spurious scrollbar will appear.
This prevents occasional scrollbar flickering in Ladybird/Qt on Wayland
with fractional scaling enabled on compositors supporting
wp-fractional-scale-v1.
This removes the two boolean hack in favor of using the existing
mechanism to remove queued tasks. It also exposes the element
invalidation behavior for call sites that don't necessarily want to
update the finished state, but still need to invalidate the associated
target.
It turns out that hmtx and OS/2 table values _are_ used when
rendering OpenType for PDFs: hmtx is used for the left-side bearing
value (which is read in `Painter::draw_glyph()`), and OS/2 is used
for the ascender, which Type0's CIDFontType2::draw_glyph()
and TrueTypeFont::draw_glyph() read.
So instead of not trying to read these tables, instead try to read
them but tolerate them failing to read and ignore them then.
Follow-up to #23276.
(I've seen weird glyph positioning from not reading the hmtx table.
I haven't seen any problems caused by not reading the OS/2 table yet,
but since the PDF code does use the ascender value, let's read that
too.)
The former automatically adapts the prefix to binary and octal
output, and is what we already use in the majority of cases.
Patch generated by:
rg -l '0x\{' | xargs sed -i '' -e 's/0x{:/{:#/'
I ran it 4 times (until it stopped changing things) since each
invocation only converted one instance per line.
No behavior change.
Height definiteness is now preserved as intended by CSS-SIZING-3
(assuming I've understood it correctly) and not implicitly granted by
layout algorithms when they assign height.
For the specific special/magical cases where some sizes become definite
during layout, the preceding commits have made them explicit in code.
This fixes a number of flex layout issues where we were previously
resolving percentage values against post-layout flex container heights,
but other browsers don't.
Fixing this function will be quite an undertaking since a *lot* of code
relies on set_content_width() implicitly flipping the definiteness of
the width. It is wrong though, so we do need to fix it eventually.
In particular, these two interesting cases:
- The containing block of an abspos box is always definite from the
perspective of the abspos box.
- When resolving abspos box sizes from two opposing fixed insets,
we now mark those sizes as definite (since no layout was required
to resolve them).
The whole way we lay out SVG content is ad-hoc, so this doesn't follow
any particular spec. However, our viewport transform logic depends on
having definite sizes, so let's just mark them as such for now.
This will be required for percentages to resolve against it correctly
after we make set_content_height() not automatically mark heights as
definite sizes.
The CSS-FLEXBOX-1 spec has a bunch of special cases where sizes are
considered definite after reaching a specific point of the layout
algorithm.
Before this change, we were relying on set_content_width/height also
implicitly marking those content sizes as definite.
To prepare for that implicit behavior going away, this patch makes
the special cases explicit.
Before this change, we were always assigning the calculated height to
each block container after laying it out in BFC.
This should really only happen during intrinsic sizing, since that is
how measurements are communicated to the client there.
We should still add an informational message about when this happens
before we even get here - but we still shouldn't be able to locate a
place to apply a hunk as it ends up producing unexpected results where
the patch is prepended to the existing file.
