Age | Commit message (Collapse) | Author |
|
The spec wants that to happen.
|
|
With this, we can write all tag types we can currently read :^)
|
|
Keycap emoji, for example, begin with ASCII digits. Instead, check the
first code point for the Emoji Unicode property.
On a profile of scrolling around on the welcome page in the Browser,
this raises the runtime percentage of Font::glyph_or_emoji_width from
about 0.8% to 1.3%.
|
|
On a profile of scrolling around on the welcome page in the Browser,
this drops the runtime percentage of Font::glyph_or_emoji_width from
about 70% to 0.8%.
|
|
For example, consider the Pirate Flag emoji, which is the code point
sequence U+1F3F4 U+200D U+2620 U+FE0F. Our current emoji resolution does
not consider U+200D (Zero Width Joiner) as part of an emoji sequence.
Therefore fonts like Katica, which have a glyph for U+1F3F4, will draw
that glyph without checking if we have an emoji bitmap.
This removes some hard-coded code points and consults the UCD's code
point properties for emoji sequence components and variation selectors.
This recognizes the ZWJ code point as part of an emoji sequence.
|
|
Currently, we compute the width of text one code point at a time. This
ignores grapheme clusters (emoji in particular). One effect of this is
when highlighting a multi-code point emoji. We will errantly increase
the highlight rect to the sum of all code point widths, rather than
just the width of the resolved emoji bitmap.
|
|
This allows consideration of multi-code point glyphs.
|
|
|
|
|
|
In other words: only consider coefficient of the current scan when
adding coefficients to a macroblock. Information about which
coefficients are present in the stream are passed through the spectral
information in the context.
|
|
These variables are useless for baseline JPEG, but they will become
useful for other encodings.
|
|
|
|
|
|
|
|
With it, we can also add a spec reference. And it will remind to anyone
who wants to add support for a new coding to not forget to update it.
|
|
In progressive mode, this functions will need to be called multiple time
on the same macroblocks, so it shouldn't create the vector every
time it's called.
|
|
This means that we should read markers in a loop instead of quiting on
the first scan. This is useless for now as `SOF0` frames only have one
scan, but this is a step forward `SOF2` support.
|
|
As a JPEG file can contain multiples scans, we should return from
`scan_huffman_stream` on all new markers (except restart markers) and
not only `JPEG_EOI`.
|
|
Miscellaneous and tables segments can also be placed between scans,
placing this code in a function will allow us to avoid duplication when
we get there.
|
|
As it, in fact, does not skip a marker but a segment :^).
|
|
|
|
|
|
|
|
The new function return a new bitmap instead of mutating the current
one in place.
|
|
While returning the same image is a cute optimization, it violates the
expectation that the returned Bitmap is a new bitmap, not shared with
anyone else.
|
|
|
|
The from_bytes() methods error out on invalid table sizes,
but let's make sure other potential future callers get it right too.
|
|
This used to check the empty, moved-from parameter instead of
the member variable (οΌβΈα)
|
|
|
|
NamedColor2TagData::from_bytes() errors out if that isn't the case,
but let's make sure other potential future callers get it right too.
|
|
|
|
|
|
|
|
Similar to 13b18a1 or d0f3f3d.
|
|
|
|
Rename "reset_marker" to "restart_marker" as described by the spec. It
also concerns disambiguate the situation as the DRI was also called a
reset marker.
|
|
|
|
|
|
|
|
|
|
It's what project leadership wants.
|
|
Found by reencoding Tests/LibGfx/test-inputs/icc-v2.png, the 'dscm' tag.
|
|
|
|
It only implements serialization of the 7-bit ASCII string, not yet
serialization of the UCS-2 and Macintosh ScriptCode strings.
With this, matrix-based v2 profiles can be reencoded :^)
|
|
TextDescriptionTagData::from_bytes() errors out if that isn't the case,
but let's make sure other potential future callers get it right too.
|
|
This moves TextDescriptionTagData below SignatureTagData.
It just moves code around and doesn't change anything.
|
|
|
|
The initial signs were wrong for the deltas of f(x), the ellipse
equation. This seemed to be fine for larger circles/ellipses but
broke things at a small scale, this was previously fixed with a
horrible "error = error / 4" hack. With this change, all ellipses
look a little better :^)
This also fixed a signed integer overflow Andreas found with UBSAN,
which happened for circles with a 1px radius.
|
|
|
|
|