Skip to content

[ENH] xkcd.mplstyle w/ quasi parsing of patheffects.{functions} #26854

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

story645
Copy link
Member

@story645 story645 commented Sep 21, 2023

PR summary

Closes #5992 by parsing patheffects, is an alternative to #14943 and also builds on some of the ideas there and in #26050.

@anntzer pointed out that input needs to be a list b/c the same patheffects function can be called multiple times and yield different results, so in this implementation path.effects can be set to:

  • list of function: [patheffects.Normal(), patheffects.withStroke(linewidth=4)]
  • list of tuples specifying functions: [('Normal', ), ('withStroke', {'linewidth':4})]
  • list of functions + tuples: [patheffects.Normal(), ('withStroke', {'linewidth':4})]
  • string list of tuples ('Normal', ), ('withStroke', {'linewidth':4})

I'm gonna defer writing a what's new and all the rest until there's some discussion/consensus on if this is a feasible approach. This PR introduces an xkcd.mplstyle and shims it into xkcd.plot b/c that was the motivation for this PR, but I can also spin the xkcd stuff out into a separate PR/commit once decisions are more settled.

For the arguments/keywords I went with a very generous "is this an ast_literal parsable dictionary" - advantage is it's a lot cleaner than the patheffects mini parser I started writing, disadvantage is that it's not gonna error out til draw time using the function to do the validation.

Definitely not the most optimal/optimized implementation, but this PR sketches out using a function name : dictionary approach, e.g:

path.effects.withStroke : {'linewidth':4, 'foreground': 'w'}

The advantage of this approach is that we can heavily restrict which patheffects to support and let rc_setup handle that validation, disadvantage is slighlty more typing.

changed some of the path.sketch docs to clarify their format cause misreading them was what caused a lot of the rest of my test failures. spun out #26921 so that may need to go in first

PR checklist

@story645 story645 changed the title xkcd.mplstyle w/ quasi parsing of patheffects.{functions} [ENH] xkcd.mplstyle w/ quasi parsing of patheffects.{functions} Sep 21, 2023
@story645 story645 marked this pull request as draft September 21, 2023 16:18
@story645 story645 marked this pull request as draft September 21, 2023 16:18
@story645 story645 marked this pull request as draft September 21, 2023 16:18
@story645 story645 marked this pull request as ready for review September 22, 2023 04:55
@story645 story645 marked this pull request as draft September 22, 2023 05:10
@story645
Copy link
Member Author

doc build failure mystifies me cause builds locally

@story645
Copy link
Member Author

story645 commented Oct 3, 2023

And it's an important doc build since it's the style example and unicode_minus keyword :/

@story645
Copy link
Member Author

story645 commented Oct 5, 2023

Note to self:

  • add a figures equal test that plt.xkcd and with style(xkcd) produce the same figure.
  • change name to __name__ or patheffect or use list [(name, kwarg dict), (name, kwarg dict)]

@tacaswell
Copy link
Member

A concern with using {'name': 'func_name, **func_kwargs} as the structure there is a collision between keys that the API here controls ('name') and the keys that belong to the function that is going to be selected. While it is true none of the functions currently in patheffects have a keyword named 'name', but it seems unwise to leave that resolvable conflict / special case on the table. Picking another name might reduce the risk of a collision, but using Tuple[str, dict] seems like the safest way to encode this and drops the need for a bunch of text + magic key in the input.

https://www.youtube.com/watch?v=iKzOBWOHGFE has a good section on inband vs out-of-band encoding of information.

@story645
Copy link
Member Author

but using Tuple[str, dict] seems like the safest way to encode this and drops the need for a bunch of text + magic key in the input.

Technically with this format I can do Tuple[str, list, dict] for (name, args, kwargs) but I dunno if that saves anyone work.

@timhoffm
Copy link
Member

Technically with this format I can do Tuple[str, list, dict] for (name, args, kwargs) but I dunno if that saves anyone work.

If you want Tuple[str, list, dict], it should likely be Tuple[str, dict] | Tuple[str, list, dict], because I anticipate that the first case is the fare more common one, and empty args 'withStroke', (), {'linewidth': 4} is somewhat annoying.

But I suggest to keep it simple and only support kwargs. One could always add the other option later.

@story645
Copy link
Member Author

It'd be really helpful if #26989 could get in b/c that would help me debug the unicode minus glyph not working error

@story645 story645 force-pushed the path-parse branch 2 times, most recently from fc92806 to 45896e8 Compare November 3, 2023 04:13
@story645
Copy link
Member Author

story645 commented Nov 3, 2023

builds using https://github.com/dummy-index/xkcd-font/raw/brushup/xkcd-script/font/xkcd-script.ttf so do I need to verify that it's okay to use? liscence is cc and using this file b/c it has an extended character set

@story645
Copy link
Member Author

story645 commented Nov 3, 2023

Also, we may want to ask if we can vendor that file since it's on an unmerged branch of an unmaintained fork if we're gonna use it in doc builds? ETA: or fork that fork or the original project and add that fork?

@story645
Copy link
Member Author

story645 commented Nov 3, 2023

And do we wanna deprecate plt.xkcd if this goes in? shadowed all the existing xkcd tests so continuity is maintained.

@story645 story645 force-pushed the path-parse branch 7 times, most recently from 5e9e8a7 to 931cf4a Compare November 7, 2023 03:32
@tacaswell
Copy link
Member

Can you please put the Humor Sans work in its own PR so we can get that merged and backported ASAP?

@story645
Copy link
Member Author

story645 commented Nov 9, 2023

#27299

@story645
Copy link
Member Author

story645 commented Nov 9, 2023

follow up from call is to make a note in xkcd docs about plt.style as alt

story645 and others added 3 commits December 1, 2023 14:26
adds tests and stricter validation for path.effects parameter

Co-authored-by: Thomas A Caswell <tcaswell@gmail.com>
Co-authored-by: Ben Root <ben.v.root@gmail.com>
Co-authored-by: Antony Lee <anntzer.lee@gmail.com>
Co-authored-by: Antony Lee <anntzer.lee@gmail.com>
# use patheffects object or instantiate patheffects.object(**kwargs)
return [pe if isinstance(pe, path_effects.AbstractPathEffect)
else getattr(path_effects, pe[0])(**pe[1])
for pe in self._get('path.effects')]
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs to support third party patheffects too (e.g. pkgname.modulename.patheffect instead of just withStroke)

@story645
Copy link
Member Author

story645 commented Dec 7, 2023

notes:
fix doc build - is probably xkcd-font missing symbol
support third party using fully qualified name

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.

add xkcd style
5 participants