Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font configuration and size #279

Open
1 of 6 tasks
dhardy opened this issue Feb 6, 2022 · 1 comment
Open
1 of 6 tasks

Font configuration and size #279

dhardy opened this issue Feb 6, 2022 · 1 comment
Labels
discussion Requires analysis/discussion

Comments

@dhardy
Copy link
Collaborator

dhardy commented Feb 6, 2022

Font configuration and APIs

The current design is quite powerful, but quite a few things are not configured in the right places. This issue discusses API and configuration.

Font size

Status quo:

  1. kas-text uses dpp (pixels per Point) and pt_size (Points per Em) as inputs
  2. FormattableText impls are given both dpp and pt_size input and output dpem
  3. KAS calculates dpp = scale_factor * 96 / 72
  4. KAS lets the theme choose a default pt_size, then lets applications override this, then lets user-configuration override this

Notes:

  1. Only the product dpem = dpp * pt_size is needed, excepting the values supplied to FormattableText.
  2. Arguably we could just pass pt_size into FormattableText impls and multiply the output by dpp (which should always scale text), or even let impls output a relative scale and multiply by dpp * pt_size. The CSS font-size property supports pt (Points per Em), percentage, and em (Em per Em, i.e. relative).
  3. This is correct for Linux & Windows (72 Points = 1 inch, 96 dots-per-inch is "standard definiton"). For MacOS this is not "correct" (72 dots-per-inch is the standard used for font sizes), but we wish to keep things consistent to make apps portable (probably config files should use "standard font units" but UIs may scale this value on MacOS). Note also: a word processor app would want to override dpp to draw the document.
  4. Currently, user-configuration replaces the scale set for apps like the stopwatch, which is a problem unless configuration is app-specific. We may instead want to let apps specify a scale factor (which multiplies the screen's scale factor). Instead of setting this globally, we may want to set it for all contents of some widget.

Standard fonts

CSS provides five standard font families: Serif, Sans-serif, Monospace, Cursive and Fantasy (the latter two are useless to us).
KDE provides six standard fonts: General, Fixed-width, Small, Toolbar, Menu, Window title (mostly these are the same font and size, but allowing individual configuration).
KAS currently has six text classes (controlling also wrapping and alignment): Label, LabelScroll, Button, Edit, EditMulti, MenuLabel.

Which defaults do we want? Should Label not wrap?

Currently, KAS lets the theme configure fonts, but this should likely not be the case.

Selecting from standard fonts

Currently, widgets using the high-level text API will select a TextClass. The theme, when sizing, will adjust the text's environment (dpp, pt_size, font_id, wrap/alignment options). This "theme code" is not really theme-related.

Currently, using the low-level text API, widgets must adjust the text environment directly, including dpp.

Goals

Scale factor (dpp or otherwise) should be a factor set by the window or overridden by an (ancestor) widget. It should not be stored in the "environment" within a text object.

Selected font (font_id) and size (pt_size) should probably remain part of the text object.

The "high level text API" should be simple, pre-configuring everything based on a configuration set (TextClass), so probably there are no changes here (except modifying the list of text classes). Text objects may include formatting affecting the font (bold, italic, size).

The lower-level text API should (a) allow adjusting pt_size, (b) allow control of alignment and wrap behaviour, (c) allow selection of font from a family name. Probably bold and italic will only available through "formatted font objects" (same as high-level API).

Or we could try merging these into a single API: allow optional configuration of most things, perhaps through a formatted text object or a closure.

Configuration files

Currently a bunch of font size and family configuration is part of the theme configuration. It should not be. Add a new font configuration section to the main config file?


To define:

  • Standard text classes
  • How standard fonts are configured and selected — e.g. move from theme to kas-core
  • What influence the theme may have on font selection (none?)
  • How widgets may override scale (dpp) for children
  • What font size control FormattableText implementations have (only relative, or a function of default pt_size?)
  • Font drawing & layout APIs
@dhardy dhardy added the discussion Requires analysis/discussion label Feb 6, 2022
@dhardy dhardy mentioned this issue Feb 6, 2022
@dhardy
Copy link
Collaborator Author

dhardy commented Jul 16, 2022

dpp and pt_size are now replaced with dpem (essentially, the line height in physical pixels): kas-gui/kas-text#68

Implication: FormattableText impls can no longer specify font size in Points, but only in relative terms or via absolute pixel size (unscaled). This may need to be revisited eventually but so far is fine (there are other ways of accessing the scale factor anyway).

Currently, user-configuration replaces the scale set for apps like the stopwatch, which is a problem unless configuration is app-specific.

The example actually only sets font size, which user configuration may override. Probably we should prioritize the value set directly by the app in this case.

  • Replace all font units with dpem (line height in pixels)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Requires analysis/discussion
Projects
None yet
Development

No branches or pull requests

1 participant