Previous implementation would draw dashes to the edge of the character
cell, which would result in double-wide dashes at the point where they
tiled. This fixes that, and also generally implements it in a cleaner
way than before.
This adds Powerline rendering for the trapezoid characters (E0D2 and
E0D4).
This is the last of the Powerline additions for now. These are the
shapes that 1) render the most egregiously with stock fonts (off-center,
bleeding background, visible gaps), and 2) are simple enough to be
rendered without resorting to more complex measures like embedding SVG.
Some box codepoints (the cursor) want to use the original font metrics
height but others (corners) want to use the full grid height. I can't
see a better way to do this than manually maintaining a switch here. We
can add codepoints as needed.
Further to the additional comments in #1055, this adds some references
to the comments in the ellipse algorithm (including the original
reference for the circle algorithm).
This changes the half-circle drawing algorithm for glyphs E0B4 and E0B6
to an ellipse algorithm.
This fixes a shortcoming in the circle approach - how do you handle
drawing for a box that is not a typical 2:1 H*W? We were trying to
anticipate this by taking the smaller of the two axes and using that for
the radius. This works when there's some error in the zoom and the x
radius somehow becomes larger than the y radius (in observation, this
happens occasionally in some zoom steps, but only slightly).
However, turns out a more realistic anticipation is for fonts that have
a much *larger* height-to-width ratio. Iosevka, for example, has an
approx. 2.6:1 ratio (observed in the inspector). In this instance, this
approach does nothing except lock the circle to an extremely small
radius. For this instance, we need an ellipse, which will handle all
cases in an expected fashion.
Fixes#1050.
This adds in-terminal rendering for the powerline glyphs E0B4 and E0B6,
similar to how we are rendering the triangle shapes currently.
The circle glyphs use a much more complex rendering due to the nuances
of drawing them: we use a midpoint algorithm for drawing on a 4x
supersampled matrix, fill, and then downsample. We use the same
downsampling approach as is done in the arc box drawing code.
The midpoint variant we're using here is described by Dennis Yurichev:
https://yurichev.com/news/20220322_circle/, although there are similar
variants elsewhere (some cited at the bottom of his article).
This adds the Powerline face to our set of built-in faces, which
represents glyphs that are used to draw Powerline-style shell prompts
and status lines.
Since these are used similar to box-drawing characters, alignment is
important, and this gives us the most control in preventing related
artifacts.
This initial commit is scaffolding and support for the various solid
triangles - additional glyphs will come in other commits.
Fixes#675.
Fixes#757
The x/y is unsigned (as it should be, since top-left is 0,0). In the
case of a very small grid size and certain thickness settings, its
possible to overflow. In this scenario, the only reasonable thing to do
is just clamp to 0 because some sprites are going to look weird with
small enough grids anyways.
Fixes#143
There were multiple issues with the previous calculation. First, we
expected dash width COULD be negative and protected against it, but our
dash width calculation type was unsigned! With the proper font metrics,
this led to an underflow safey panic.
Second, as part of the dash width calculation, we are tryign to downstep
the size of the gaps so we can try to fit dashes within a cell. But we
were not using those adjusted gap sizes. With the proper font metrics,
this could lead to an assertion failure seen in #143.
This fixes the calculations. They produce the same numbers, but do so in
a more Zig-idiomatic way while fixing the above two issues.
