Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Text antialiasing for mathtext #26094

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

Closed

Conversation

stevezhang1999
Copy link
Contributor

@stevezhang1999 stevezhang1999 commented Jun 8, 2023

PR summary

Accidentally closed by force pushing, the new PR for review is #26376 and this old thread has all the history information

As mentioned in the previous PR, antialiasing will use rcParams["text.antialiased"] and the parameter antialiased for text() will have no effect.

Currently I'm solving this by passing the antialiasing state through MathTextParser. Want to know about your ideas about this.
From my perspective,

pros:

  • minimum modification to existing code and tests

cons:

  • in mathtext.py, the antialiased parameter in parse(self, s, dpi=72, prop=None, antialiased=None) should never be None and should be set to True or False by the caller. I make it a default argument because doing so will keep the existing code working - and it's less likely to make users confused because this is an internal API.

Side Note: I have completed only AGG backend. For Cairo backends, I didn't see an elegant way to do this - the mathtext is parsed through RendererCairo._text2path.mathtext_parser.parse(), and mathtext_parser is initialized as a vector(path) parser (because it's an attribute of _text2path) , which don't have the option to render with or without antialiasing. I'm not quite sure about Cairo backend should be used for rasterization, vector, either of them, or both, so want to know your ideas about whether we need to support math text antialiasing for Cairo.

PR checklist

@ksunden
Copy link
Member

ksunden commented Jun 8, 2023

I don't see a problem with default (None) meaning "still use the 'text.antialiased' rcParam", as it stands the default will I think disable it regardless of the rcParam, which is a change in behavior.

(And it may just fail handing None to a C function that expects a bool...)

The change to backend_agg may escape the cases where most users would have passed None by resolving to a bool there, but non-agg backends may still be affected, and could just resolve to a bool from the rcparam...

@stevezhang1999
Copy link
Contributor Author

I don't see a problem with default (None) meaning "still use the 'text.antialiased' rcParam", as it stands the default will I think disable it regardless of the rcParam, which is a change in behavior.

(And it may just fail handing None to a C function that expects a bool...)

The change to backend_agg may escape the cases where most users would have passed None by resolving to a bool there, but non-agg backends may still be affected, and could just resolve to a bool from the rcparam...

Thanks for the very insightful suggestions! Thinking from whether the behavior will change is really helpful. I will make None resolve rcparams based on the suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants