The values aren't 100% self-consistent, but it probably doesn't make
a difference for u8 color data. Good enough for now. See all the links
on #17714 for some more background.
This creates folding regions for blocks defined by the following:
- if/elseif/else/endif
- foreach/endforeach
- while/endwhile
- macro/endmacro
- function/endfunction
Since there is no guarantee that each keyword will have a matching
partner, we do our best by looking for the most recent possible start
token matching the current end token. If we find one, we link to it and
drop all the other start-tokens that happened in between. For example,
we would define a folding region for this invalid file like so:
[-] if(TRUE)
│ while()
└─ endif()
Calling it was harmless as add_ac iterates over the spectral selection,
hence it won't do anything if not needed. However, this patch remains
useful as it prevents dereferencing the iterator returned by find, in
case the AC table isn't defined yet. This case happens with SOF2 images
and is (pretty harmless as read only but still) undefined behavior.
This patch brings support for SOF2 JPEGs that only use spectral
selection :^)
We still don't have achieved full support for SOF2 images, but as an
example, we decode progressive JPEG from Cloudinary.
This might be useful for converting data from arbitrary profiles to
sRGB.
For now, this only encodes the transfer function and puts in zero values
for chromaticities, whitepoint, and chromatic adaptation matrix.
This makes the profile unusable for now. But I've spent a very long time
reading things and need to check in some code, and it's some progress.
The encoded transfer function exactly matches the one in GIMP's built-in
sRGB ICC profile (but not the Compact-ICC-Profiles v4 one or the
RawTherapee v4 one -- I'll add a comment about why later.)
This returns the font's size (distance between ascender and descender)
in pixels, rounded up to the nearest integer.
This is the number we want to use in a lot of UI code, so let's have
a friendly API for it instead of ceil'ing the pixel_size() in a million
random places.
For vector fonts in particular, we need to take care to compute offsets
using floating point math. For example, with Berkeley Mono at font size
16, with syntax highlighting enabled, we are currently truncating these
offsets to integers. This results in a leftward-drift when we paint the
text.
This changes the rect in which we paint syntax-highlighted text spans to
a float rect. As we traverse the spans, we now no longer truncate any of
the text offsets, and we draw the text in the correct positions.
This is likely not a complete solution. TextEditor blindly casts ints to
floats all over, and we will want to make all of these (hundred+) float-
aware. But this should be a step in the right direction and makes vector
fonts immediately more comfortable to use.
This adds the regions generated from embedded CSS and JS, and also for
HTML block comments.
The glaring omission is that we don't add them for start/end tags. HTML
allows start and end tags to not always match up, and I believe that's
going to require some variation on the adoption-agency algorithm to
make it work correctly.
