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.
Now that ports can find our OpenGL headers and shared library, remove
all configuration and patches that was previously needed to make ports
compile with LibGL.
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.
The CMake syntax was a bit too new for our toolchain's CMake. The
following patch was backported:
b2497a8d15
Relevant issue:
https://github.com/curl/curl/issues/12920
As soon as the fix lands in the next curl version, we can remove this
patch again. :^)
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.
QUrl::toString reverses the Unicode->ASCII conversion that already
occurred here. The text of m_location_edit is already in the format we
expect, so let's just convert QString->AK::URL directly, instead of
taking the detour QString->QUrl->AK::URL
