Deprecate passing Type1Font effects as dict #15896
Conversation
77a6dee to
75ed591
Compare
75ed591 to
572e4eb
Compare
There was a problem hiding this comment.
Actually I think the old API makes sense, effects is really just a lightweight object/namedtuple. If you track the callers you will see that ultimately effects comes from reading pdftex.map, which contain entries speficying font slant and extend, which always come as a single pair, not as separate things.
|
Then the usage example at https://matplotlib.org/api/type1font.html#module-matplotlib.type1font is misleading because it's not actual a use case? It explicitly creates single-item tuples and passes them to the function. |
|
Sorry, I guess my comment was slightly misleading. The entries in pdftex.map don't necessarily specify both sland and extend, the idea is more that the two of them (or only one of them, if only one of them exists) are carried together as a dict through multiple functions and it doesn't make sense to split them at the last minute. |
|
Will decide later if I want to follow up on this. |
|
at least the (independent) docstring cleanups are fine by themselves. |
|
(I guess one could introduce a namedtuple to represent the slant/extend pair, but that feels a bit overengineered to me -- there's some level at which dicts are just fine...) |
|
Not going to fight over this. |
PR Summary
https://matplotlib.org/devdocs/api/type1font.html#matplotlib.type1font.Type1Font.transform has a peculiar API of passing two optional parameters as dict.
This PR deprecates that behavior and instead introduces two regular keyword arguments with default values.
PR Checklist