You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
kas-text uses dpp (pixels per Point) and pt_size (Points per Em) as inputs
FormattableText impls are given both dpp and pt_size input and output dpem
KAS calculates dpp = scale_factor * 96 / 72
KAS lets the theme choose a default pt_size, then lets applications override this, then lets user-configuration override this
Notes:
Only the product dpem = dpp * pt_size is needed, excepting the values supplied to FormattableText.
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).
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.
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 Labelnot 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
The text was updated successfully, but these errors were encountered:
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)?
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:
dpp
(pixels per Point) andpt_size
(Points per Em) as inputsFormattableText
impls are given bothdpp
andpt_size
input and outputdpem
dpp = scale_factor * 96 / 72
pt_size
, then lets applications override this, then lets user-configuration override thisNotes:
dpem = dpp * pt_size
is needed, excepting the values supplied toFormattableText
.pt_size
intoFormattableText
impls and multiply the output bydpp
(which should always scale text), or even let impls output a relative scale and multiply bydpp * pt_size
. The CSSfont-size
property supportspt
(Points per Em), percentage, andem
(Em per Em, i.e. relative).dpp
to draw the document.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:
dpp
) for childrenFormattableText
implementations have (only relative, or a function of defaultpt_size
?)The text was updated successfully, but these errors were encountered: