mirror of
https://github.com/polybar/polybar.git
synced 2024-11-11 13:50:56 -05:00
5be532c51b
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 |
||
|---|---|---|
| .. | ||
| context.hpp | ||
| font.hpp | ||
| fwd.hpp | ||
| surface.hpp | ||
| types.hpp | ||
| utils.hpp | ||