Skip to content
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

kwarg fontscale to scale Font Size (convenient when using figscale) #38

Closed
leopoldsw opened this issue Feb 23, 2020 · 6 comments
Closed
Labels
enhancement New feature or request released code merged into repo AND released to Pypi

Comments

@leopoldsw
Copy link

leopoldsw commented Feb 23, 2020

Is there a way to easily adjust font size for the charts? Thanks.

(When I increase figscale, font size does not increase proportionally. So labels are really small for larger charts.)

@leopoldsw leopoldsw added the question Further information is requested label Feb 23, 2020
@DanielGoldfarb
Copy link
Collaborator

At present there is no direct way to do this. You can try using a custom style and setting an appropriate rcParam, for example:

s  = mpf.make_mpf_style(base_mpf_style='yahoo', rc={'font.size':20})
mpf.plot(data,figscale=2.0,style=s)

Let me know if that helps.

@DanielGoldfarb
Copy link
Collaborator

I'm wondering if the figscale= kwarg should also scale fonts along with the figure size. Let me know what you think.

(Although when I made a very large figure, although the fonts did not scale accordingly, I did not find in my use-case, and in my environment, that they were really small for the larger charts.)

@leopoldsw
Copy link
Author

@DanielGoldfarb The custom style method you suggested worked very well. Thank you!

And I think it would be very convenient if the font size could scale automatically.

@cammclean182
Copy link

Hi @DanielGoldfarb

Firstly thanks for your work on mplfinance - i've only just discovered it and am loving its approach so far vs other libraries i've used.

I wanted to ask about your solution above using rcParams. Are all original matplotlib rcParams available to be used here?

I found a list on https://matplotlib.org/3.1.1/tutorials/introductory/customizing.html that i used to experiment and am not sure whether they are not supported by mplfinance or whether i am calling them incorrectly.

For example i tried unsuccessful to alter your solution above to instead change the number format on the x-axis:

s = mpf.make_mpf_style(base_mpf_style='yahoo', rc={'date.autoformatter.day':'%d-%m-%Y'})
mpf.plot(data,figscale=2.0,style=s)

Lastly i would be keen to contribute to this package where my limited knowledge is able to. I have created a notebook of examples i have created so far whilst experimenting that i could add to your examples if interested. Otherwise please reach out in the future if there's anything simple you can delegate.

Kind regards
Cam

@DanielGoldfarb
Copy link
Collaborator

DanielGoldfarb commented Mar 4, 2020

@cammclean182
Cam,
Thanks so much for expressing your appreciation and for getting involved. Regarding rcParams, yes all are available, but there are two caveats to keep in mind:

  1. mpf.plot() uses matplotlib's rcParams context manager, effectively creating it's own internal rcParams from the existing global rcParams). Therefore (as you did) you should pass rcParams changes into the API via the style kwarg. Then, because of the context manager, you will not see those changes in the global rcParams, but they will affect mpf.plot().
    • The use of the context manager for rcParams inside of mpf.plot() was removed 2020-MAY-13 due to popular demand. Thus mpf.plot() does use the global rcParams, although it re-initializes rcParams by calling plt.style.use('default') before any mpf style is applied.
    • Users can externally apply matplotlib's rcParams context manager if desired. It is also possible to circumvent mplfinance's reinitialization of rcParams, by making a copy of rcParams and passing it into make_mpfstyle() using the rc= kwarg, for example: mpf.make_mpfstyle(...,rc=my_rcParamsCopy,...)
    • Note: the reason for the re-initialization of rcParams is to ensure that a given mpf style will appear the same for all users. Using the above circumvention method ensures that it is obvious that the user is creating their own custom style and thus there is no question of a particular style appearing different for different users.
  2. Throughout matplotlib, rcParams is used for default values. Whenever a value is passed explicitly into matplotlib's APIs, the explicit value is used instead of rcParams.

Your question has highlighted the fact that I need to do a better job of documenting which parameters are explicitly controlled by mplfinance. Some are documented in the table near the bottom of the customization examples notebook where it states "Note that the following kwargs also modify rcParams: facecolor, figcolor, gridcolor, gridstyle, gridaxis; If any of them are specified, and the same rcParam is also specified, then the kwarg takes precedence."

I realize now that I need to document other "overrides" that mplfinance is routinely doing, for example formatting the DateTime axis labels. The ability to not display non-trading days requires that mplfinance explicitly control the DateTime formatting (and not rely on rcParams).

The solution is this: we need to create a datetime_format kwarg, and tie it's value into mplfinance's explicit control of the formatting. I think this should be relatively easy. The code where mplfinance determines the format is here. If you are comfortable with it, you could add the kwarg to the valid kwargs table with a default value of None, and then use it (if it is not None) in place of the existing logic.

I would definitely be interested in seeing your examples. You can place them in a repository or gist, and either make it public or give me permission to collaborate so I can see them, or if you prefer email me at dgoldfarb.github@gmail.com Alternatively you can fork mplfinance, and stick your examples in the examples directory, or perhaps the examples/scratch_pad directory, where I can review them in your fork and let you know if we want to add them to this repository. (I also may ask you if I can use them in a talk at a Python conference. I have submitted a proposal to speak on mplfinance at three different Python conferences this year, and I would love to be able to show examples from other mplfinance users; not just my own).

@DanielGoldfarb DanielGoldfarb changed the title Adjust Font Size? kwarg figscale scale Font Size as well. Mar 5, 2020
@DanielGoldfarb DanielGoldfarb added the enhancement New feature or request label Mar 5, 2020
@DanielGoldfarb
Copy link
Collaborator

Although it can make sense to scale the Font size when scaling the Figure, two factors may be an issue:

  1. Some users of figscale may be OK with font sizes as they are now, and if we start changing the font size unexpectedly for those users, they may find it undesirable.
  2. It is very possible that at least some users will find that, while scaling the Font sizes may be desirable, scaling them by the exact same amount as the Figure may not give the best appearance that they want.

Therefore I have decided to implement this as a new kwarg, fontscale. Users who want fonts scaled by the same amount as the figure can set figscale= and fontscale= to the same value. Others can find the mix that they prefer, and/or leave fontscale untouched.

@DanielGoldfarb DanielGoldfarb added merged / awaiting release to pypi code merged into repo, but not yet released to Pypi and removed question Further information is requested labels Mar 2, 2021
@DanielGoldfarb DanielGoldfarb changed the title kwarg figscale scale Font Size as well. kwarg fontscale to scale Font Size (convenient when using figscale) Mar 2, 2021
@DanielGoldfarb DanielGoldfarb added released code merged into repo AND released to Pypi and removed merged / awaiting release to pypi code merged into repo, but not yet released to Pypi labels Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request released code merged into repo AND released to Pypi
Projects
None yet
Development

No branches or pull requests

3 participants