Repository navigation
Improve font spec for SVG font referencing. - #19253
Merged
jklymak merged 1 commit intoMay 22, 2021
Merged
jklymak merged 1 commit into
jklymak merged 1 commit into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Copy link
Copy Markdown
Member
But shouldn't they? The CSS goes in a <element style="..."> and thus a double quote must be escaped. |
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
Author
|
But the double quote would get escaped by XMLWriter.start when the XML is actually emitted; the point is that previously we were escaping it twice, both in generate_css and in XMLWriter.start. |
Sorry, something went wrong.
QuLogic
approved these changes
Jan 14, 2021
Copy link
Copy Markdown
Member
|
Yes, I didn't realize that start was in XMLWriter. |
Sorry, something went wrong.
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).
jklymak
approved these changes
May 22, 2021
QuLogic
added a commit
to QuLogic/matplotlib
that referenced
this pull request
Mar 28, 2024
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
QuLogic
added a commit
to QuLogic/matplotlib
that referenced
this pull request
Mar 28, 2024
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
QuLogic
added a commit
to QuLogic/matplotlib
that referenced
this pull request
Mar 28, 2024
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
QuLogic
added a commit
to QuLogic/matplotlib
that referenced
this pull request
Mar 29, 2024
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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