-
Notifications
You must be signed in to change notification settings - Fork 55
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
Toolkit-independent Font class #609
Conversation
Codecov Report
@@ Coverage Diff @@
## master #609 +/- ##
==========================================
+ Coverage 38.97% 39.28% +0.31%
==========================================
Files 487 490 +3
Lines 26798 27002 +204
Branches 4066 4110 +44
==========================================
+ Hits 10445 10609 +164
- Misses 15897 15921 +24
- Partials 456 472 +16
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Most of my comments are around documentation and a few questions.
# Note: we don't support 'medium' as an alias for weight 500 because it | ||
# conflicts with the usage of 'medium' as an alias for a 12pt font in the CSS | ||
# specification for font attributes. | ||
WEIGHTS.update({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a resource which points out how/why this map is defined the way it is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this and other maps which define similar associations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These come from the CSS spec, Qt and Wx constant names, true/open type font conventions, and in some cases (originally) from "traditional" values from the typesetting world (eg. the font weights date back to the fonts used in phototypesetting systems).
The CSS spec is probably the simplest comprehensive reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we have some extra weights here compared to the CSS spec: https://www.w3.org/TR/css-fonts-3/#propdef-font-weight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More specifically, these are the values from CSS: normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900
Where do the other values come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, this wasn't just from the CSS spec - in particular it should at least include the mappings that Enable has here https://github.com/enthought/enable/blob/db84efa4d031fd641ebe097301a56764634ce21d/kiva/fonttools/_constants.py#L90-L105
as well as the names that Qt uses for weight constants: https://doc.qt.io/qt-5/qfont.html#Weight-enum
and the names wx uses: https://wxpython.org/Phoenix/docs/html/wx.FontWeight.enumeration.html
and the OpenType font weights: https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass
More info can be found here: https://bigelowandholmes.typepad.com/bigelow-holmes/2015/07/on-font-weight.html
This is all very fuzzy because the names predate computerized fonts and most font families don't supply all weights.
This comment has been minimized.
This comment has been minimized.
I'd rather not - the round-tripping test was going for "cheap-and-cheerful", but if it's not generic then it's not particularly useful. Better in that case is to have toolkit-specific tests that allow more fine-grained tests for what works in each permutation of back-ends. |
There seem to be a few review comments from #520 for the changes made in this PR which don't seem to be addressed -
|
'extraexpanded': 150, | ||
'ultra-expanded': 200, | ||
'ultraexpanded': 200, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, CSS has these values: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded
I don't think we need the extra ones here given we document the fact that these values follow CSS convention.
QFont.ExtraLight: 'extra-light', | ||
QFont.Light: 'light', | ||
QFont.Normal: 'normal', | ||
QFont.Medium: 'medium', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this "medium"
not allowed in the weight
trait?
In fact, could we map all of these to "100"
, "200"
and so on? Then QFont.Medium
will be mapped to "500"
, which is allowed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting back to this after a year, since this is just the descriptions with no attempt at font-name parsing, 'medium'
should be allowed both here and in the weight trait as there is no conflict with other uses of medium
at this level.
Looking through these, I have checked off the ones that have been addressed. Of the others:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a couple of minor comments
Co-authored-by: Poruri Sai Rahul <[email protected]>
This is the
colorfont class from #520 pulled out into a separate PR.This does not include any of the string parsing, trait type, or dialog classes.