This reverts commit a4b2e5b27b.
This was just plain wrong, I remember it making sense and fixing
something but that was probably due to local changes. It should never
have landed on master, my bad.
According to the Intel Software Developer's Manual Volume 3A section
6.12.1.3, the interrupt gate type means the IF flag is cleared to
prevent nested interruption. The trap gate type does not modify the
IF flag. Thus the gate type argument is important when constructing
an IDTEntry.
On x86_64 and x86, storage_segment (bit 12 counting from 0)
is always 0 according to the Intel Software Developer's Manual,
volume 3A, section 6.11 and section 6.14.1. It has therefore
been removed as a parameter from IDTEntry's constructor and
hardwired to 0.
This allows the user to pass very specific values instead of a u64 value
that is later cast to the underlying type.
The change also adds support for passing v128 values:
- v(i64.const 4) (splat 4)
- v128.const 0x4 (just a few bits specificed, everything else = 0)
This function was called over and over in `manage_extra_channels()`,
even if the result depends only on the metadata. Instead, we now call it
once and store the result.
Of my 1000 test files, 73 have stream Type0 truetype fonts with stream
CIDToGIDMaps. This makes that work.
(With this patch, the number of files in my 1000 test files complaining
"Font is missing Name" increases from 41 to 75, so a bit under half of
the fonts using stream CIDToGIDMaps also have no 'name' table. So that's
next.)
Increases files without issues from 652 to 681.
Previously, during the start of the game BoardView component tried to
get the font from the database passing empty string as a parameter.
It caused a debug message informing user that the lookup failed.
Painting command executors are defined within the "Painting" namespace,
allowing us to remove this prefix from their names.
This commit performs the following renamings:
- Painting::PaintingCommandExecutor to Painting::CommandExecutor
- Painting::PaintingCommandExecutorCPU to Painting::CommandExecutorCPU
- Painting::PaintingCommandExecutorGPU to Painting::CommandExecutorGPU
Separating the recorder list from the painter will allow us to save it
for later execution without carrying along the painter's state. This
will be useful once we have a separate thread for executing painting
commands, to which we will have to transfer commands from the main
thread.
Preparation for https://github.com/SerenityOS/serenity/pull/23108
The setter was missing an implementation for the default and default/on
value attribute modes. This patch adds a method to get the current value
attribute mode, and implements the value setter and getter based on that
mode according to the spec.
Previously, this just checked the tag names. For elements that exist in
different namespaces (like HTMLScriptElement vs SVGScriptElement) this
could lead to invalid casts, as the namespace was not checked.
This switches to using the safer helpers on the DOM::Node.
Previously, the check for `.html` meant that `.svg` tests were excluded.
This led to a few `.svg` with missing or bit-rotted expectations, which
have now been added/updated.
Previously, step 5 of the stacking context hit testing would just call
`hit_test()` on the stacking context's paintable box. Which (at least
for SVGs) is just indirect infinite recursion (it'll end up right back
where it started after going through a few functions).
This now explicitly hit tests the descendants, which seems more correct,
and avoids the crash for SVGs, but nothing really seems to depend on
this step. Another solution (which I've done for a while working on
SVGs) is just to delete step 5 entirely, and nothing seems to break.
Fixes#22305
https://adobe-type-tools.github.io/font-tech-notes/pdfs/5177.Type2.pdf
says "The behavior of undefined operators is unspecified." but
https://learn.microsoft.com/en-us/typography/opentype/spec/cff2
says "When an unrecognized operator is encountered, it is ignored and
the stack is cleared."
Some type 0 CIDFontType0C fonts (i.e. CID-keyed non-OpenType CFF fonts)
depend on the latter, even though they're governed by the former spec.
Fixes rendering of text in 0000521.pdf (e.g. page 10 or 5). The font
there has a bunch of 0 opcodes for some reason.
While all callers of lerp_nd created a Vector with inline_capacity of 4
to ensure no heap allocation will take place for most inputs, lerp_nd
requested a reference to a Vector with 0 inline_capacity, which meant a
new vector was allocated on each call.
VectorN::length() returns the vector length (aka the square root of the
dot product of the vector with itself), not the count of components.
This is seemingly both wrong and slow.
Disclaimers, similar to what's on #23202 (and most of the
prerequisites mentioned there are needed for this too):
* Only supports the `Identity-H` type0 cmap at the moment
* Doesn't support vertical text yet
* Only supports the `Identity` CIDToGIDMap at the moment
(this one is a truetype-only thing)
If this is passed in, we don't use the cmap table from the font,
but use the external lookup object instead.
This conveniently happens to create a place where we can put all the
Cmap configuration logic that was a bit spread out before.
No behavior change yet.
We now cache potentially named elements on the Document when elements
are inserted and removed. This allows us to do lookup of what names are
supported much faster than if we had to iterate the tree every time.
This first cut doesn't implement the rules for 'exposed' object and
embed elements.
Together with the already-merged #23122, #23128, #23135, #23136, #23162,
and #23167, #23179, #23190, #23194 this adds initial support for
rendering some CFF-based Type0 fonts :^)
There's a long list of things that still need improving after this:
* A small number of CFF programs contain the charstring command 0,
which is invalid. Currently, this makes us reject the whole font.
* Type1FontProgram::rasterize_glyph() is name-based. For CID-based
fonts, we want a version that takes CIDs (character IDs) instead.
For now, I'm printing the CID to a string and using that, yuck.
(I looked into doing this nicely. I do want to do that, but I
need to read up on how the `seac` type1 charstring command uses
character names to identify parts of an accented character.
Also, it looks like `seac`'s accented character handling moved
over to `endchar` in type2 charstring commands (i.e. in CFF data),
and it looks like we don't implement that at all. So I need to do
more reading first, and I didn't want to block this on that.)
* The name for the first string in name-based CFF fonts looks wrong;
added a FIXME for that for now.
* This supports the named Identity-H cmap only for now. Identity-H
maps UTF16-BE values to glyph IDs with the idenity function, and
assumes it's horizontal text. Other named cmaps in my test files are
UniJIS-UCS2-H, UniCNS-UCS2-H, Identity-V, UniGB-UCS2-H, UniKS-UCS2-H.
(There are also 2 files using the stream-based cmaps instead of the
name-based ones.)
* In particular, we can't draw vertical text (`-V`) yet
* Passing in the encoding to CFF::create() is awkward (it's nullptr
for CID-keyed fonts), and it's also not necessary since
`Type1Font::draw_glyph()` already does the "take encoding from PDF,
and only from font if the PDF doesn't store one" dance.
* This doesn't cache glyphs but re-rasterizes them each time. Easy
to add, but maybe I want to look at rotation first. And things
don't feel glacial as-is.
* Type0Font::draw_glyph() is pretty similar to second half of
Type1Font::draw_glyph()
Make TopDict's defaultWidthX and nominalWidthX Optional<>s so that
we can check if they're set per fdselect-selected font dict, and
if so use the value from there in CID-keyed fonts. Otherwise, keep
using the value in the top dict.
