Setting the marker's content width here is causing the text that follows
the marker to be indented a bit too much. This is noticeable when a line
with a disclosure marker is followed by a line with any other marker. It
previously would look something like:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
Now the disclosure marker line matches other marker types:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
There were two issues:
1) the C+=R and C-=R operators expected arithmetic types to have .real()
2) the R+C, R-C, R*C and R/C operators applied the operation in wrong
order (did C+R, C-R, C*R and C/R instead). This wouldn't matter for
+ and * which are commutative, but is incorrect for - and /.
We currently do not wait for iframes to finish loading before triggering
the document's load event, which creates a race condition for any ref
tests that include iframes. Until that gets fixed, let's skip the one
affected test.
See issue #22012.
Ideally we would not create a layout node at all for these elements so
that every layout node would always have a paintable associated with it.
But for now, to fix the crash, just leave a FIXME and special case this
element.
Also leave a VERIFY to make it easier to debug this type of crash in the
future.
Fixes a crash seen on codecov.io for my 'patch' project.
It's perfectly possible for JavaScript to call unobserve() on an element
that hasn't been observed. Let's stop asserting if that happens. :^)
Fixes#22020
Manually added an Outlines dict with three items, one each for
every text string encoding in its title.
(Preview.app apparently can't handle UTF-8 in outlines either.)
For now, this uses UTF-16BE and UTF-8 marked strings in page body text.
These markings should be ignored in body text.
Hand-written, with `set fenc=latin1` and `set binary` in vim, and
xref etc fixed up by running
mutool clean Tests/LibPDF/encoding.pdf Tests/LibPDF/encoding.pdf
as usual.
A manual test, but better than nothing.
I hand-wrote the file, and used mutool to fix up xref and stream
lengths:
mutool clean Tests/LibPDF/type3.pdf Tests/LibPDF/type3.pdf
The file contains one `d1` character which per spec shouldn't
contain color statements, and if it does it should be ignored,
and one `d0` character which can contain color.
The text then sets a color before rendering the text.
Per spec, the text color should affect the `d1` character but
not the `d0` one. We get this wrong, but so does Preview.app.
(PDFium gets it right.)
But independent of the colors, just rendering the glyphs at all
at the right position is already good :^)
This is an adaptation of the "misc/backgrounds.html" file in the
Serenity image. It tests a lot of background-related properties that we
otherwise have no tests for.
When a box does not have a top, left, bottom, or right, there is no
need to adjust the offset for positioning relative to the padding edge,
because the box remains in the normal flow.
By using available_inner_space_or_constraints_from(available_space), we
ensure that the available space used to calculate the min/max content
height is constrained by the width specified for the box itself
(I know that at least GFC always expects available width to be
constrained by specified width if there is any).
This change improves layout in "Recent news" block on
https://telegram.org/
The elements this hack was being used for were grouping elements, and
can be properly sized: https://svgwg.org/svg2-draft/struct.html#Groups.
Note: Other than one test change the elements here are already covered
by layout tests.
Hand-written, based on the text example in Appendix G.2 in
the PDF 1.7 spec, with the xref table fixed up by `mutool clean`:
mutool clean -dggg Tests/LibPDF/text.pdf Tests/LibPDF/text.pdf
I didn't find example code for this and the AI assistant did very
poorly on this as well. So I had to write it all by myself!
It can be much more efficient I think, but I think the overall
shape is maybe roughly fine.
* SampledFunction now keeps the StreamObject it gets data from alive
(doesn't matter too much in practice, but does matter in the test,
where nothing else keeps the stream alive).
* If a sample is an integer, we would previously sample that value
twice and then divide by zero when interpolating. Make sure to
sample 1 unit apart.
