This adds functionality for choosing different normalization metrics for
each fallback font. It's not exposed as a config option, but could be in
the future, which would probably go a long way towards addressing
concerns like #7929.
The currently available reference metrics are, in priority order:
`ic_width, ex_height, cap_height, line_height, em_size`. The default
value is `ic_width`.
By priority order, I mean that if the chosen metric is not defined in
the fallback font, we move to the next metric in the list---we don't
normalize by an estimated metric from the fallback font (however, we're
happy to use an estimated metric from the primary font, that's how
`ic_width` normalization between CJK and Latin fonts work). This extends
the pattern that was used between `ic_width` and `ex_height` in the
existing hardcoded rule. `line_height` is always defined, so the buck
stops there.
What motivated me to implement this was the fact that, with the existing
hardcoded rule, the embedded symbols-only Nerd Font was always scaled up
by a factor of 1.2, which turned out to be an important reason why it's
been difficult to make icon scaling work to everyone's satisfaction.
Accordingly, the symbols-only font is the first to take advantage of the
new functionality. If this PR is merged, #7917 is no longer needed. (To
limit the scope of this PR, it only includes the minimal changes to let
icon scaling take advantage of this functionality. I may submit a
follow-up PR with some further icon scaling improvement enabled by
this.)
I changed my mind, this is a pretty small change and relevant to the
intent of the PR. This brings the appearance of the embedded symbols
much closer to patched fonts.
With this, the sizes of most symbols are nearly identical to a patched
font, the only big difference is positioning (and TBH I think we do a
better job positioning than the patcher does, since we have knowledge
about the cell size).
Move size adjustment logic out of `Entry`, I understand the impulse to
put it there but it results in passing a lot of stuff around which isn't
great.
Rework `add(...)` in to `add(...)` and `addDeferred(...)`, faces are
passed directly now instead of passing an entry, and an options struct
is used instead of positional arguments for things like style, fallback,
and size adjustment.
Change size adjustment test back to a half pixel tolerance instead of 5%
because the previous commit (allowing fractional pixel sizes) fixed the
root cause of large differences.
This makes the `new_window` action properly inherit properties from the
parent surface that initiated the action. Today, that is only the pwd
and font size.
A variety of naming, commenting, and formatting improvements + a few
explicit error sets. This commit has no functional changes, though it
does remove a couple functions that didn't really need to exist.
The old math didn't allow fractional pixels on the left and bottom, and
stretched glyphs vertically since the height was always rounded up. At
very small font sizes this looked good, but at medium and even large
sizes this just made things inconsistent and janky.
These new calculations are practically pixel-identical to whatever
CoreText is doing in 99% of cases, and the remaining cases seem to be
some sort of auto-hinting since it's internal features of the glyph
getting repositioned.
Over all, I still prefer this to CoreText's quantize option, but if this
causes further issues we should probably just revert the whole thing and
go ahead and add an extra pixel of padding to the bottom and left...
The old math didn't allow fractional pixels on the left and bottom, and
stretched glyphs vertically since the height was always rounded up. At
very small font sizes this looked good, but at medium and even large
sizes this just made things inconsistent and janky.
These new calculations are practically pixel-identical to whatever
CoreText is doing in 99% of cases, and the remaining cases seem to be
some sort of auto-hinting since it's internal features of the glyph
getting repositioned.
Over all, I still prefer this to CoreText's quantize option, but if this
causes further issues we should probably just revert the whole thing and
go ahead and add an extra pixel of padding to the bottom and left...
We do this by characterizing the shared bounding boxes in a static copy
of the symbols only nerd font when we're doing the codegen. This allows
us to get results of our scaling that are just as good as in a patched
font, since related glyphs can now be sized and positioned relative to
each other.
This stops things like folder icons from becoming over-wide. The patcher
typically makes these glyphs always 1 cell wide, but since we know how
it will be displayed we have the benefit of being able to make it more
than 1 cell when there's room. This makes our dynamic scaling *better*
than a static patched font :D
Using the "subpixel quantization" option for rendering our glyph was
creating bad edge cases where we'd lose the bottom or left row / column
of pixels in a glyph sometimes. I investigated the exact effect of this
option and it seems like beyond quantizing the position and scale it's
also doing some rudimentary auto-hinting. That said, the auto-hinting
doesn't do that much for us, and the fact that it horizontally snaps
coordinates to thirds of a pixel instead of whole pixels makes things
worse in terms of legibility at small pixel sizes, so ultimately it's
better with our own handling anyway.
I extensively compared the result of Apple's option with our own manual
quantization here and I'm pretty sure this will always match the whole
pixel sizes, and where it differs (other than things like crossbars) it
seems to make glyphs generally more legible not less.
Nerd font icons were ***WAY*** too big depending on your font setup,
this is because we were always using the full cell height when the nerd
font patcher instead uses an "icon height" for most things. The patcher
calculates the icon height as two thirds of the font's cap height and
one third of the line height, but I've chosen to instead use 1.2 times
the cap height for more consistent results across fonts-- if the user
wants their icons bigger, they can use the `adjust-icon-height` metric
modifier (and they can also use it to make them smaller if they want
that for some reason).
I also adjusted the attributes to user horizontal cover + vertical fit
for `^` stretch modes (proportional scaling but scale up), which makes
it so that it never exceeds the cell size, since first it covers
horizontally and then scales down to fit vertically if necessary;
previously, if there were a particularly wide glyph that was scaled with
cover/cover it would exceed the available width and overflow in to
neighboring cells which wasn't good.
Icons were often WAY too big before because they were filling the whole
cell in height, which isn't great lol. This commit adds an `icon_height`
metric which is used to constrain glyphs that shouldn't be the size of
the entire cell.
This was subtly wrong in a way that was most obvious when text switched
from regular to bold, where it would seem to wiggle since the bearings
of each letter would shift by a pixel in either direction. This affected
applications like fzf which uses bold to dynamically highlight the line
you have selected.
This PR changes `font.Collection` to automagically adjust the sizes of
added fonts so that their metrics (specifically their ex height, or
their ideograph character width if they have one) match the primary
font. This is like
[`font-size-adjust`](https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust)
from CSS.
This is a big win for users who use mixed writing systems and rely
heavily on fallback fonts. For example, in #7774 it's pointed out that
CJK characters are not very well harmonized with existing Latin glyphs,
well:
|Before (`main`)|After (this PR)|
|-|-|
|<img width="326" alt="image"
src="https://github.com/user-attachments/assets/c11d372d-ec69-426d-b008-1f56a7430f23"
/>|<img width="326" alt="image"
src="https://github.com/user-attachments/assets/efcb56ea-0572-481a-b632-a0b5cd170fa9"
/>|
This also improves our handling of the horizontal alignment of fallback
glyphs. It's not an ideal solution; it only works for glyphs narrower
than the cell width because it messes with ligatures if we include
glyphs wider than the cell width; and most things would look better if
the center were proportionally remapped based on the ratio from the
glyph advance to the cell width, but that messes with glyphs designed to
align vertically so it can't be done, instead the original advance width
is centered in the cell width.
Previously produced very wrong values when calling Collection.setSize,
since it was assuming that the provided face had the same point size as
the primary face, which isn't true during resize-- so instead we just
have faces keep track of their set size, this is generally useful.
The nerd font patcher uses `ypadding` as a single subtraction from the
cell height, which means that half of it should go to the top padding
and the other half to the bottom, this was making the heavy brackets way
too small lol (0.4 of the cell height instead of 0.7)
This better harmonizes fallback fonts with the primary font by matching
the heights of lowercase letters. This should be a big improvement for
users who use mixed scripts and so rely heavily on fallback fonts.
This generally adjusts the bearings of any glyph whose original advance
was narrower than the cell, which helps a lot with proportional fallback
glyphs so they aren't just left-aligned. This only applies to situations
where the glyph was originally narrower than the cell, so that we don't
mess up ligatures, and this centers the old advance width in the new one
rather than adjusting proportionally, because otherwise we can mess up
glyphs that are meant to align with others when placed vertically.
We can reintroduce `advance` if we ever want to do proportional string
drawing, but we don't use it anywhere right now. And we also don't need
`sprite` anymore since that was just there to disable constraints for
sprites back when we did them on the GPU.
This mostly applies to powerline glyphs, but is also relevant for heavy
bracket characters, which need to always be 1 wide otherwise they look
silly because they misalign depending on if there's a space after them
or not.
Previously `ypadding` was effectively ignored, since it's mutually
exclusive with `overlap`. This had a noticeable effect on the heavy
bracket characters U+276C...U+2771, which were much taller than they
should have been.
I also fixed the vertical overlap limit, since negative `overlap` values
are used in the nerd font attributes to create padding on all sides of
the cell, so we don't want to limit the magnitude of the overlap for
vertical padding, we only want to limit it if the value is positive.
That change fixed the vertical padding for a handful of ranges, which
should give more consistent results.
This reverts commit 2fca0477bc.
The idea of using stdin and stdout was the integrate it in to the build
script, but since we don't want to do that because it contains an eval,
it just makes it more annoying to use.
Follow-up to #7809, a handful of small fixes/improvements, explained
individually in each commit message.
> [!NOTE]
> Similar to the inverted "monochrome" ft flag fix from #7809, it was
pointed out that "force-autohint" was also inverted, so I did invert
that too, this has the same result of no impact on users who haven't
explicitly set it, but a breaking behavior change for users who have set
it. *These changes definitely need to be pointed out in the 1.2 release
notes!*
We no longer need a margin in the atlas because we always sample with
nearest neighbor and our glyphs are always pixel perfect, no worry about
interpolation between adjacent glyphs anymore!
The behavior of this flag was the opposite of its description in the
docs- luckily, at the same time, the default (true) was the opposite
from what the default actually is in freetype, so users who haven't
explicitly set this flag won't see a behavior difference from this.
Previously, many glyphs were having their top and right row/column of
pixels clipped off due to not accounting for the slight bearing in the
width and height calculation here.
This is in preparation to move constraint off the GPU to simplify our
shaders, instead we only need to constrain once at raster time and never
again.
This also significantly reworks the freetype renderGlyph function to be
generally much cleaner and more straightforward.
This commit doesn't actually apply the constraints to anything yet, that
will be in following commits.
Rather than using binaries statically in our source tree; this makes
them easier to update. This also makes it so that they are separated
from each other rather than using a patched JB mono as our fallback.
