If any rendered text uses a non-integer number of pixels (often emojis),
rendering of subsequent text blocks will start between pixels which
results in small gaps in the background and over/underline colors caused
by cairo only rendering at fractional-intensity in the beginning and end
pixel.
Simply rounding up text width can solve this.
Fixes#2785
* eventloop: Use eventloop namespace in cpp files
* changelog: Add missing deprecated hook message
* Make eventloop and ipc classes non-copyable and non-movable
* Remove functional.hpp
* eventloop: Don't close handles in error cases
Client should be responsible for closing handles.
* eventloop: Address invalidation of handle references
Originally the size function returned the scaled `size` property for
scalable fonts and the non-scaled `pixelsize` property for non-scalable
fonts. This caused lots of issues when that property was 0 (empty bars,
characters not drawn without warning, see references at the bottom).
This behavior was mostly observed on debian where `size` is set to 0 if
`pixelsize` is set.
We now try to use both properties for both types, but prefering `size`
for scalable fonts and `pixelsize` for non-scalable ones.
This behavior doesn't break existing correct behavior but now never
returns 0. It will always try to fall back to the other property or to
some fallback value if both properties are 0.
I originally thought this could also make font patterns more expressive
by being able to specify the size of scalable fonts directly in pixels
like so:
Unifont:size=0:pixelsize=20
or to scale non-scalable fonts by forcing polybar to fall back to the
`size` property (which is always scaled):
Wuncon Siji:pixelsize=0:size=20
But how these two patterns are matched by `fc-match` depends both on the
font and on the distro/fontconfig setup.
Ref #706
Ref #1450
Ref #1257
If FcNameParse returns NULL FcDefaultSubstitute segfaults
We log and throw an error here because the signal emitter swallows all
exceptions so if that exception was thrown, the bar would stop rendering
without any indication as to why.
Fixes#1435
In the previous implementation, std::find() returned fns.end() several times,
which caused an "Address boundary error" in std::sort if the preferred
font-index was set to m_fonts.size() + 1.
This commit reimplements the font prioritization with a simple swap.
Reproduction steps:
- Start polybar with the following config:
[bar/top]
font-0 = NotoSans-Regular:size=8;0
font-1 = MaterialIcons:size=10;0
modules-left = date
[module/date]
type = internal/date
date = %Y-%m-%d
label-font = 3 ; invalid index
This tries to mimic the old renderer's behavior as closely as possible.
In the absence of any information, DPI is assumed to be 96x96. DPI can
be configured on a per-bar basis using the configuration key "dpi".
To use the DPI configuration from Xresources (if built with support),
one can specify the following in the bar config:
dpi = ${xrdb:Xft.dpi:96}
