Le lundi 17 juillet 2017 à 10:55 +0200, Patrick Georgi a écrit :
2017-07-16 11:32 GMT+02:00 Paul Kocialkowski contact@paulk.fr:
So I am wondering what the best way to solve this would be. I see a few options:
- Having larger fonts for hi-dpi displays
I'd go with that. Plus, maybe, a function to select the right font given a few constraints (display resolution, desired terminal grid size)
There are a bunch of font options with higher resolutions in the Linux sources (lib/fonts) that could be lifted into libpayload.
Sounds reasonable enough!
- Scaling the font to reach a particular DPI (e.g. based on the
physical screen size reported from the EDID)
This could be a reasonable fallback (eg in case payloads are storage constrained and can't ship x fonts, or if even the largest font is intolerably small). Going for integer multiples (and statically generating the fonts in the internal format, registering it just like any shipped font) should be good enough. No need for any fancy scaling algo either, just duplicate the pixels in all directions.
Yeah, that would totally do.
- Reducing the resolution, by optionally providing a preferred one
from the config
Besides the potential dependency on resolution in later stages that you mentioned, the panel may or may not work well with a lower resolution, or might just show the same tiny pixels - just fewer of them with a nice, shiny, black border.
Hehe, that is a very good point. This approach is too device-dependent anyways.
I'll wait for more feedback before starting the work on this (I have a lot on my plate anyway so this probably won't be a priority for some time).
If anyone else feels like starting an implementation, I'd be overly grateful though!
Cheers,
I agree with most of what Patrick said, I think dynamic scaling to integer multiples may be best. Scaling the font up at compile-time seems like unnecessary bloat to the binary (although I'm not sure, how big are these fonts?). If you do want to include them at compile time, you may as well include a real larger font rather than just a scaled one.
-
Julius Werner -
Paul Kocialkowski