With dpi-aware=auto (the default), scale fonts using DPI *only*
if *all* available monitors have a scaling factor of one.
The idea is this: if a user, with multiple monitors, have enabled
scaling on *at least* one monitor, he/she has most likely done so to
match the size of his/hers other monitors.
For example, if the user has one monitor with a scaling factor of one,
and another one with a scaling factor of two, he/she expects things to
be twice as large on the second monitor.
If we (foot) scale using DPI on the first monitor, and using the
scaling factor on the second monitor, foot will *not* look twice as
big on the second monitor (this was the old behavior of
dpi-aware=auto).
Part of #714
Too large dots make them harder to distinguish, when the spacing
between them is small.
Prefer increasing the spacing, instead of increasing the dot
size. This looks better at small font sizes in particular.
Render braille ourselves, instead of using font glyphs. Decoding a
braille character is easy enough; there are 256 codepoints,
represented by an 8-bit integer (i.e. subtract the Unicode codepoint
offset, 0x2800, and you’re left with an integer in the range 0-255).
Each bit corresponds to a dot. The first 6 bits represent the upper 6
dots, while the two last bits represent the fourth (and last) row of
dots.
The hard part is sizing the dots and the spacing between them.
The aim is to have the spacing between the dots be the same size as
the dots themselves, and to have the margins on each side be half the
size of the dots.
In a perfectly sized cell, this means two braille characters next to
each other will be evenly spaced.
This is however almost never the case. The layout logic currently:
* Set dot size to either the width / 4, or height / 8, depending on
which one is smallest.
* Horizontal spacing is initialized to the width / 4
* Vertical spacing is initialized to the height / 8
* Horizontal margins are initialized to the horizontal spacing / 2
* Vertical margins are initialized to the vertical spacing / 2.
Next, we calculate the number of “remaining” pixels. That is, if we
add the left margin, two dots and the spacing between, how many pixels
are left on the horizontal axis?
These pixels are distributed in the following order (we “stop” as soon
as we run out of pixels):
* If the dot size is 0 (happens for very small font sizes), increase
it to 1.
* If the margins are 0, increase them to 1.
* If we have enough pixels (need at 2 horizontal and 4 vertical),
increase the dot size.
* Increase spacing.
* Increase margins.
Closes#702
Before this patch, pt-or-px values, like letter-spacing, were *always*
scaled using the current DPI value.
This is wrong; if the fonts are scaled using the output’s scaling
factor, then so should all other point values.
This also fixes an issue where e.g. letter-spacing would use one DPI
value at startup, but then when increasing/decreasing or resetting the
font size, would be re-calculated using a different DPI value, leading
to completely different spacing.
This happened when there were multiple monitors, with different DPI
values, and foot guessed the initial DPI value wrong. Normally, foot
would correct itself as soon as the window was mapped, and the
“correct” DPI value known. But if the fonts were scaled using the
scaling factor, it was possible that the font reload never happened.
This patch also updates the thickness calculation (for LIGHT and HEAVY
box drawing characters) to use the scaling factor when appropriate.
Closes#680
../../box-drawing.c: In function 'box_drawing':
../../box-drawing.c:2774:13: error: 'y1' may be used uninitialized in this function [-Werror=maybe-uninitialized]
2774 | int y0, y1;
| ^~
../../box-drawing.c:2774:9: error: 'y0' may be used uninitialized in this function [-Werror=maybe-uninitialized]
2774 | int y0, y1;
| ^~
We’re using floating point math, as a way to ensure that sextant primitives
overlap, rather than leaving empty spaces, or being uneven, when the cell
width/height isn’t divisible with 2 (width) or 3 (height).
This gets rid of all floating point math from the sextant drawing functions.
That is, encode which “pieces” make up each quad in a static array, and use a
single function to draw all quads using the four primitives “upper left/right,
lower left/right”.
We render the inverted wedges by first rendering a non-inverted triangle, and
then inverting it with PIXMAN_OP_OUT.
In cases where truncating and round():ing the triangle points have different
results, the final, inverted wedge ends up being unaligned with the
corresponding sixel(s).
This patch fixes that by handling the pre-inverted triangles
specifically. I.e. we don’t re-use the same triangle coordinates as the
corresponding non-inverted triangle.
When enabled, shades are rendered as solid blocks, using a darker
variant of the current foreground color.
When disabled, shades are instead rendered in a checker box pattern,
using the foreground color unmodified.
Default is enabled.
When drawing on an a8 buffer, apply antialiasing to LIGHT ARCs. This
is done by supersampling; draw to a 4 times bigger buffer, then
downsample, where each downsampled pixel is the average of the
corresponding 4x4 pixel from the supersampled buffer.
We also need to take supersampling into account while adjusting the row
and col when pixel aligning the arcs with the regular
horizontal/vertical lines.
The shape of the ARCs can still be improved. Still, this is a much
needed improvement over the current implementation.
Closes#279
We don’t have a method to draw the arcs using pixman yet. Work around
this by replacing the a8 buffer with an a1 buffer, and render the arcs
using our old, non-antialiased, way.
When rendering to an a8 surface, render shades using “transparent”
pixman rectangles.
When these glyphs are composited with a color, the resulting look is
the color, but darkened.
Use pixman_image_fill_rectangles() to render horizontal and vertical
lines.
Despite the name, this *is* the appropriate function to use, since our
lines *do* have a thickness, and thus *are* rectangles.
If the value is specified without a unit, then the value is assumed to
be in points, subject to DPI scaling.
The value can optionally have a ‘px’ suffix, in which case the value
is treated as a raw pixel count.
