bump crengine: more granular font weights #7616
Conversation
|
Oh, I quite like what you settled on to show what the current font supports ;). |
| precision = "%+.2f", | ||
| value_hold_step = 1, | ||
| }, | ||
| help_text = _([[Set the font weight delta from "regular" to apply to all fonts. |
There was a problem hiding this comment.
That's technically a weight class, but since we're not actually displaying that to the user outside of the help/status, I'm okay with the simplification ;).
frontend/ui/data/creoptions.lua
Outdated
| - 0 will use the "regular (400)" variation of a font. | ||
| - 1 will use the "medium (500)" variation of a font if available | ||
| - 3 will use the "bold (700)" variation of a font if available | ||
| If a font variation is not available, and for fractional deltas, a font will be synthesized from the nearest available weight of the font.]]), |
There was a problem hiding this comment.
as well as for fractional deltas
There was a problem hiding this comment.
Could also possibly keep the variation thing going, since that's going to be a term more and more commonly used with the advent of variable fonts, so, a font variation will be synthesized.
There was a problem hiding this comment.
Maybe just a fractional adjustment?
There was a problem hiding this comment.
as well as for fractional adjustments (plural), right ?
frontend/ui/data/creoptions.lua
Outdated
| help_text_func = function(configurable, document) | ||
| local font_face = document:getFontFace() | ||
| local available_weights = cre.getFontFaceAvailableWeights(font_face) | ||
| return T(_("The default font '%1' is available in these real weights: %2"), font_face, table.concat(available_weights, ", ")) |
There was a problem hiding this comment.
Oh, there I'd possibly use weight classes, though ;).
There was a problem hiding this comment.
Should I keep the "real" in there ? in these real weight classes ?
There was a problem hiding this comment.
I agree that it feels slightly clunky, but I couldn't really think of anything better. Perhaps getting rid of it entirely does the trick, though, the context should make it clear.
There was a problem hiding this comment.
"The default font 'Noto Sans' is available in 400, 700." ? Feels a bit short without "real", one could think +1 and +2 won't work.
There was a problem hiding this comment.
But might be OK, above we state "If a font variation is not available, a font variation will be synthesized...".
There was a problem hiding this comment.
Oh, no, sorry, I meant just omitting "real" ;).
i.e., available in weight classes x, y, z
There was a problem hiding this comment.
Oh :/
Anybody feel free to correct this in his next PR if "available in 400, 700." feels like broken english :)
|
Updated help text with suggestions:
|
|
Does this +3 look odd, in the serie of numbers ?
+2, synthesized from the bold, is often thiner (so, surprising and soon forgotten) than the +1 1/2 synthesized from the regular - and we mention |
|
It does seem odd, but I'm not sure if there's an alternative. |
|
Even if only just because the old setting exposed Bold, and not SemiBold, yeah, I'd keep 3 instead of 2 ;). |
|
|
|
Or just "in 400 700" to avoid having to handle singular or plural "in weights 400." :/ |
Includes: - MathML: a few minor fixes - (Upstream) lvtext: fix possible index out of range - Fonts: RegisterExternalFont() should take a documentId - Fonts: fix: letter-spacing should not be applied on diacritic - (Upstream) Fonts: more granular synthetic weights - Fonts: synthesized weights: tweak some comments - Fonts: keep hinting with synthetic weight - Fonts: fix synthesized weight inconsitencies - Fonts: fix getFontFileNameAndFaceIndex() - Fonts: adds LVFontMan::RegularizeRegisteredFontsWeights() - Fonts: handle synth_weight tweaks in glyph/glyphinfo slots - (Upstream) Fonts: fix some compiler warnings - Fix hyphenation on Armenian and Georgian text Update the bottom menu widget "Font Weight" to allow more granular weights than the previous "regular | bold". Also bump thirdparty/luasec to v1.0.1.
should be fine, #6785 should have fixed any issues. |
Includes:
I decided to not care about the migration from the old boolean
font_emboldento the replacement numberfont_base_weight- this will let people who had bold know that there is this new setting with more granular weights, as they'll probably enjoy 1.5 more than the old "bold"=3.(2 in the screenshots has been corrected to +2, too lazy to remake the screenshot)
I got rid of +3, I wanted to get rid of +2 but the toggle felt a bit naked then :)
Rewording suggestions welcome.
@yparitcher : any idea if we renaming/removing a dispatcher setting/action (font_weight) can cause issues if a user has been using it?
This change is