Before this change, there was some confusion possible where an IO would
try to find its way back to the document where we registered it.
This led to an assertion failure in the test I'm adding in the next
commit, so let's fix this first.
IOs now (weakly) remember the document where they are registered, and
only unregister from there.
Per 1.7 spec 3.8.1, there are multiple logical text string types:
* text strings
* ASCII strings
* byte strings
Text strings can be in UTF-16BE, PDFDocEncoding, or (since PDF 2.0)
UTF-8.
But byte strings shouldn't be converted but treated as binary
data.
This makes us no longer convert strings used for drawing page text.
TABLE 5.6 "Text-showing operators" lists the operands for text-showing
operators as just "string", not "text string" (even though these strings
confusingly are called "text strings" in the body text), so not doing
this there is correct (and matches other viewers).
We also no longer incorrectly convert strings used for cypto data
(such as passwords), if they start with an UTF-16BE or UTF-8 marker.
No behavior change for outlines and info dict entries.
https://pdfa.org/understanding-utf-8-in-pdf-2-0/ has a good overview of
this.
(ASCII strings only contain ASCII characters and behave the same
anyways.)
Implemented by adding the extra 3-value syntax as its own case and only
running it when parsing background-position. I'm sure it could be
implemented in a smarter way but this is still a bunch less code than
before. :^)
This means `object-position` will no longer incorrectly accept the
3-value background-position syntax.
Remove the now-ambiguous and unused `position` enum while we're at it.
(This enum only existed as a hack.)
And dealing with the fallout of doing so. I am not 100% sure that it is
safe for us to be treating Strings in the value sanitization algorithm
in all cases as if they are ASCII, but this commit does not change any
existing behaviour there.
Currently, in CPU painter, border painting is implemented by building
a Gfx::Path that is filled by Gfx::AntiAliasingPainter. In the GPU
painter, we will likely want to do something different, and with a
special command, it becomes possible.
Also, by making this change, the CPU executor also benefits because now
we can skip building paths for borders that are out of the viewport.
By consistently accepting only device pixel values instead of a mix of
CSSPixels and DevicePixels values, we can simplify the implementation
of paint_border() and paint_all_borders().
This greatly reduces the number of compilations necessary when functions
declaring local functions are re-executed.
For example Octane/typescript.js goes from 58080 bytecode executables
to 960.
