-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Improve font spec for SVG font referencing. #19253
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
Conversation
But shouldn't they? The CSS goes in a |
But the double quote would get escaped by |
Yes, I didn't realize that |
The 'font: ...' shorthand is much more concise than setting each property separately: This replaces e.g. `"font-family:DejaVu Sans;font-size:12px;font-style:book;font-weight:book;"` by `"font: 400 12px 'DejaVu Sans'"`. Note that the previous font weight was plain wrong... Also this revealed a bug in generate_css (we shouldn't run it through escape_attrib, as quotes (e.g. around the font family name) get mangled); and we don't need to load the font at all (we should just report whatever font the user actually requested).
We currently special-case the SVG converter depending on if it used fonttype='none', and use one that has our base fonts available. However, this is not based on the rcParam setting (because we don't have that at conversion time), but on whether the SVG text contains the font styling [1]. This check for styling uses the _current_ version, which was changed way back in matplotlib#19253. These files were never re-generated though, and used the old version of the style, meaning the expected images never triggered the special converter. The result images are written with the current style, and _do_ trigger the special conveter. Evidentally, this never was a problem for most developers, because everyone had DejaVu Sans installed globally, so the expected images matched. However, on the clean macOS CI, it's not installed globally, so the expected images get converted with the wrong font, and the test fails. [1] https://github.com/matplotlib/matplotlib/blob/de1102668dbc0694e98653bd17641e9d99394e57/lib/matplotlib/testing/compare.py#L303
We currently special-case the SVG converter depending on if it used fonttype='none', and use one that has our base fonts available. However, this is not based on the rcParam setting (because we don't have that at conversion time), but on whether the SVG text contains the font styling [1]. This check for styling uses the _current_ version, which was changed way back in matplotlib#19253. These files were never re-generated though, and used the old version of the style, meaning the expected images never triggered the special converter. The result images are written with the current style, and _do_ trigger the special conveter. Evidentally, this never was a problem for most developers, because everyone had DejaVu Sans installed globally, so the expected images matched. However, on the clean macOS CI, it's not installed globally, so the expected images get converted with the wrong font, and the test fails. [1] https://github.com/matplotlib/matplotlib/blob/de1102668dbc0694e98653bd17641e9d99394e57/lib/matplotlib/testing/compare.py#L303
We currently special-case the SVG converter depending on if it used fonttype='none', and use one that has our base fonts available. However, this is not based on the rcParam setting (because we don't have that at conversion time), but on whether the SVG text contains the font styling [1]. This check for styling uses the _current_ version, which was changed way back in matplotlib#19253. These files were never re-generated though, and used the old version of the style, meaning the expected images never triggered the special converter. The result images are written with the current style, and _do_ trigger the special conveter. Evidentally, this never was a problem for most developers, because everyone had DejaVu Sans installed globally, so the expected images matched. However, on the clean macOS CI, it's not installed globally, so the expected images get converted with the wrong font, and the test fails. [1] https://github.com/matplotlib/matplotlib/blob/de1102668dbc0694e98653bd17641e9d99394e57/lib/matplotlib/testing/compare.py#L303
We currently special-case the SVG converter depending on if it used fonttype='none', and use one that has our base fonts available. However, this is not based on the rcParam setting (because we don't have that at conversion time), but on whether the SVG text contains the font styling [1]. This check for styling uses the _current_ version, which was changed way back in matplotlib#19253. These files were never re-generated though, and used the old version of the style, meaning the expected images never triggered the special converter. The result images are written with the current style, and _do_ trigger the special conveter. Evidentally, this never was a problem for most developers, because everyone had DejaVu Sans installed globally, so the expected images matched. However, on the clean macOS CI, it's not installed globally, so the expected images get converted with the wrong font, and the test fails. [1] https://github.com/matplotlib/matplotlib/blob/de1102668dbc0694e98653bd17641e9d99394e57/lib/matplotlib/testing/compare.py#L303
The 'font: ...' shorthand is much more concise than setting each
property separately: This replaces e.g.
"font-family:DejaVu Sans;font-size:12px;font-style:book;font-weight:book;"
by
"font: 400 12px 'DejaVu Sans'"
.Note that the previous font weight was plain wrong...
Also this revealed a bug in generate_css (we shouldn't run it through
escape_attrib, as quotes (e.g. around the font family name) get
mangled); and we don't need to load the font at all (we should just
report whatever font the user actually requested).
Split out of #19201, but also including the non-mathtext case.
PR Summary
PR Checklist
pytest
passes).flake8
on changed files to check).flake8-docstrings
and runflake8 --docstring-convention=all
).doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).