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

Skip to content

textpath tries the adobe standard encoding as a default for fonts #112

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

Merged
merged 1 commit into from
Jul 7, 2011

Conversation

leejjoon
Copy link
Contributor

I found that the textpath module was not able to handle glyphs like "fi", "fl" and etc for TeX text.
For example,

rcParams["text.usetex"]=True
t = text(0.5, 0.5, "field", size=50)
from matplotlib.patheffects import withStroke
t.set_path_effects([withStroke(foreground="red", linewidth=5)])

and "fi" is not displayed.

The patch tries to convert the glyph id reported by the dviread module to the proper glyph id for the font to be used using the encoding information.

By the way, I'm hardly an expert on this subject and I hope some one more knowledgeable than me review the patch and see if I get this right.

-JJ

@mdboom
Copy link
Member

mdboom commented May 11, 2011

I think @jkseppan is probably the best person to review this.

@jkseppan
Copy link
Member

jkseppan commented Jul 5, 2011

Sorry for the slow reaction. The patch looks fine to me, although I am no expert in Freetype. Since it seems that a lot of the font-related code must be written by trial and error in the absence of good documentation, I would like there to be test cases for each successive improvement. How difficult would it be to write a test case from the "field" example? I think we already ship some TeX fonts, so we could use one of them and get pretty repeatable output.

But I'm fine with merging this as-is.

efiring added a commit that referenced this pull request Jul 7, 2011
textpath tries the adobe standard encoding as a default for fonts
@efiring efiring merged commit 11d2c52 into matplotlib:master Jul 7, 2011
@efiring
Copy link
Member

efiring commented Jul 7, 2011

The test idea is good, but I think it is best not to let it hold up the merge of the present change. If anyone is inspired to add a test, it can be done at any time.

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

Successfully merging this pull request may close these issues.

4 participants