8000 Fixed Issue #8068 - SVG encoding by sughandj · Pull Request #8415 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Fixed Issue #8068 - SVG encoding #8415

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
wants to merge 7 commits into from

Conversation

sughandj
Copy link
@sughandj sughandj commented Apr 1, 2017

SVG backend now supports special characters like won symbol with usetex.
#8068

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Apr 2, 2017
@tacaswell
Copy link
Member

Does #8286 also fix the same problem?

@sughandj
Copy link
Author

@tacaswell Hi, sorry for the late reply.
I checked out #8286 and tried to reproduce #8068, the warning is not there however, the Won character doesn't show up.
Looks like #8286 doesn't solve #8068.

for i, c in enumerate(enc0.encoding)}

# Make a list of each glyph by splitting the encoding
enc0_list = []
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the same as enc0_list = [e.split('/') for e in enc0.encoding] ?

Why do this splitting?

Copy link
Author
@sughandj sughandj Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that'll make a 2D list, but we need 1D.

The encoding that is generated looks like this ['Grave/Acute/Circumflex/Tilde/Dieresis/Hungarumlaut/Ring.....']
Thus splitting at "/" gives us individual character names.
Not only that, each index actually corresponds to its character code
(eg: enc0_list[142] = 'uni20A9' which is the Won character)
Therefore, line 363-364, enumerates the list with i = character code and c = character name and creates a dictionary character code => font index
Later, in the code the glyph is retrieved using this dictionary

if enc:
    charcode = enc.get(glyph, None)

Hope this makes sense :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how has this ever worked if that is the case?

enc0_list += e.split("/")

# Encoding provided by the font file mapping names to index
enc = {i: font.get_name_index(c) or None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in a block for when charmap_name == "ADOBE_STANDARD", why change to not use the standard encoding?

I think the fix should probably be fixed above to select a better character map for the file?

Copy link
Author
@sughandj sughandj Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the block where if charmap_name == "ADOBE_STANDARD" and font_bunch.encoding:
Since font_bunch already has Unicode values in them, we don't need to specially use the adobe standard file.
Thus, it was removed completely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then the conditional should be changed, not just silently internally ignored.

@@ -382,7 +383,10 @@ def get_glyphs_tex(self, prop, s, glyph_map=None,
charcode = glyph

if charcode is not None:
glyph0 = font.load_char(charcode, flags=ft2font_flag)
if use_glyph:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be merged up into the conditionals above to simplify the logic?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The charcode is set right before we reach this condition if charcode is not None:
Therefore, it seems like the right spot to decide which font method to use to load the charcode.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

your right, I missed that there was a path to get a non-empty enc that did not set use_glyph to True.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this is very problematic, the code path above where you set use_glyph is a caching mechanism so the second time around this may have the wrong value of use_glyph?

@tacaswell
Copy link
Member

Can you explain this changes a bit better? Assume I know nothing about how font encoding works :)

Could you include the changes from #8286 in this PR (or explain why they are wrong!)?

@sughandj
Copy link
Author

@tacaswell I hope the replies to your comments give you more insight of the changes :)
Let me know if you have any other questions.

@tacaswell
Copy link
Member

The test failures look real.

I am still extremely uncomfortable with this change because I do not understand it yet.

This seems to be drastically changing how this code works (by consuming the encoding from the font rather than forcing it to use the adobe character map) but is still leaving a bunch of the old machinery around leaving the code in a very confused state.

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Aug 29, 2017
# Make a list of each glyph by splitting the encoding
enc0_list = []
for e in enc0.encoding:
enc0_list += e.split("/")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: one needs to do e.decode("ascii").split("/") to test this PR on Py3.

@anntzer anntzer mentioned this pull request Dec 3, 2018
6 tasks
@anntzer
Copy link
Contributor
anntzer commented Jul 5, 2019

I think this has been superseded by #12928 (which owes much to this PR, thanks :)).

@anntzer anntzer closed this Jul 5, 2019
@story645 story645 removed this from the future releases milestone Oct 6, 2022
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
0