polybar-dwm/include/cairo
patrick96 5be532c51b refactor(font): More robust font size calculation
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
2019-06-03 00:49:48 +02:00
..
context.hpp fix(build): Uninitialized local variable (#1759) 2019-05-05 22:09:03 +02:00
font.hpp refactor(font): More robust font size calculation 2019-06-03 00:49:48 +02:00
fwd.hpp wip(refactor): Cairo drawing 2017-01-24 07:11:14 +01:00
surface.hpp doc: Convert @ to \ doxygen commands 2018-11-04 19:28:27 -08:00
types.hpp feat(conf): Properties for top/bottom radius #445 2017-03-21 14:49:33 +01:00
utils.hpp doc: Convert @ to \ doxygen commands 2018-11-04 19:28:27 -08:00