Mailman 3 June 2019 - Matplotlib-devel

What is draw_path's transform's destination?
by Rob McDonald Sept. 24, 2019

Sept. 24, 2019

I'm implementing a custom path effect by inheriting from AbstractPathEffect and implementing draw_path as instructed here <https://matplotlib.org/api/patheffects_api.html#matplotlib.patheffects.Abst…>. That link references RenderBase.draw_path <https://matplotlib.org/api/backend_bases_api.html#matplotlib.backend_bases.…> to define the required interface. Unfortunately, I can't find anywhere in the associated documentation that tells me what the transform argument really entails. I've also read the transforms tutorial <https://matplotlib.org/tutorials/advanced/transforms_tutorial.html>, and while that explains the pipeline and all the intermediate transformations, it doesn't really settle what I have available to me in draw_path. It is clear that I can use it to transform coordinates from data to something -- but I don't know what to. For the big picture -- I am implementing a path effect to allow drawing hatched lines similar to this <https://www.mathworks.com/matlabcentral/fileexchange/29121-hatched-lines-an…>, which I did years ago in Matlab. Years before that, I've also done this in Java Graphics2D by implementing a custom stroke. (The Java approach is more applicable to the path effect approach, but I can't point to that code online anywhere.) Anyway, I have things mostly working -- and I am using the transform to go from data coordinates to something that looks orthogonal and reasonable on-screen. So, for minimum functionality, it works. However, I want to give the user the ability to control the length and spacing of the hatches -- which is in a coordinate system after the transformation is applied. So, in order to document this thing, I need to know what it is. Or, if there is a way to get intermediate stages of the transformation pipeline, that would work too. As for the user interface -- it seems to make the most sense to specify the hatch length and spacing in terms of something similar to a line width (typically points) or a marker size. I'm new to Python and matplotlib -- what is the Pythonic unit a user would expect to specify this in (and how do I achieve that with what is available in draw_path)? Thanks, Rob

2 5

Using towncrier to generate changelogs
by David Stansby July 15, 2019

July 15, 2019

Dear all, I am proposing to change up how Matplotlib's API changes/what's new pages are generated, in particular moving to using towncrier <https://github.com/hawkowl/towncrier> to add more automation to the process. This is motivated by the crazy amount of time it took me to combine all the API change and what's new fragments into a coherent page for the 3.1.0 release. The PR to change this process is here: https://github.com/matplotlib/matplotlib/pull/14589 The new process would be - When a new feature or api change or code removal is implemented, add a changelog file to the *changelog/* folder - The changelog file should be named <PR number>.<type>.rst, and should contain a single sentence or paragraph describing the change. <type> is the type of change, ie. api_change, new_feature or removal - towncrier can then automatically collate these fragments into a single .rst page, which can be manually edited if needed before releasing I think this will significnatly reduce the burden of producing what's new pages each release, without adding any extra burden on those writing the what's new entries. Please take a look at the PR and leave comments/questions/suggestions! In particular, feedback on what "types" of changelog entry to include would be very welcome. All the best, David

2 2

Welcome to Martin Renou
by Thomas Caswell June 30, 2019

June 30, 2019

Folks, Please welcome Martin Renou (@martinRenou on github) to the team! He is working on ipympl (aka %matplotlib widget). Tom -- Thomas Caswell tcaswell(a)gmail.com

1 0

Pull requests for table.py
by swfiua＠gmail.com June 13, 2019

June 13, 2019

Hi, I just wanted to provide some background on the recent flurry of fixes to table.py and the history behind the code. See attached pdf. There are 3 main themes to the changes: * better automatic setting of the font size * change how horizontal padding around cell text is calculated * add ability to specify cell edge colours John

3 4

image_comparison tests
by swfiua＠gmail.com June 13, 2019

June 13, 2019

Hi, It was drawn to my attention that the baseline_images with the expected images can gobble up a lot of repository space, so it is best to squash commits to avoid submitting multiple changes to the baseline_images. Looking at all the tests that use image_comparison, almost all of them go with the default value of "tol = 0", in other words anything but an exact match generates an error. If we only cared about spotting changes then for these tests we could just store some sort of checksum on the image data and use that to spot when the image has changed. Updating a checkum only adds a few bytes to the repository. The down side of this approach (and it is a big downside) is that when an image changes you would no longer have the expected image and the diff available to look at. The only solution I can think to that is to store the expected images somewhere else, with the ability to retrieve an image given the checksum, thus keeping them out of the main repository. John

1 0

Matplotlib 2.2.x caretaker
by Thomas Caswell June 4, 2019

June 4, 2019

Folks, We discovered today that the 2.2.x branch has bit-rotted again and does not pass CI anymore (due to testing dependencies moving under us). Looking for a volunteer to take the lead on making sure that 2.2.x stays healthy, managing any 2.2.x release we want to do before 2020, and keeping track of what things from master need to be pulled all the way back. I suspect that this will take an hour per week average and is time-boxed to end on Jan 1, 2020. Tom -- Thomas Caswell tcaswell(a)gmail.com

2 1

Looking for OSX and Jupyter notebook experts for integrating a new renderer into Matplotlib
by Antony Lee June 3, 2019

June 3, 2019

Hi all, Some of you may already have heard about mplcairo ( https://github.com/matplotlib/mplcairo), a new backend for Matplotlib I have been developing for the past two years. Briefly, it relies on the cairo library (https://www.cairographics.org/) to generate higher quality images than Matplotlib's current backends, both in raster format (for which Matplotlib currently uses Agg, a library that whose development has stalled) and in vector (PDF, PS, SVG) formats (for which Matplotlib currently uses hand-written backends). (A list of mplcairo's features and differences from Matplotlib's default backends is listed in its README, at https://github.com/matplotlib/mplcairo.) Given mplcairo's features, there is interest in the Matplotlib core developer team to move it into Matplotlib itself, with the ultimate goal to (possibly) make it the default backend. Obviously, there are many steps before this can happen, but, in particular, there are two for which I am looking for help: - Improve the macOS build: Currently, I provide wheels for Linux and Windows, but am unable to provide wheels for macOS. Briefly, this is because mplcairo depends on a C++17-compliant C++ standard library, which is not available on OSX<10.14. On Linux, this is handled by statically linking a recent enough libstdc++ into the wheel, but I have not been able to do so on maxOS (I do not work on that platform...). If anyone knows how to make this work on macOS, their help would be greatly appreciated. - Improve integration with the Jupyter notebook: Currently, Jupyter notebook's Matplotlib integration hard-codes the renderer to use to Agg. At some point, I had tried to make the notebook use mplcairo instead by forcefully overwriting the contents of the Agg backend with the mplcairo backend (ugh), which worked for a while, but things have changed enough on the notebook side (I believe) that this is not working anymore. Probably a more correct solution would be to make the backend actually properly configurable on the notebook's side. Given that I personally hardly ever use the notebook as well, here again help from a notebook expert would be most welcome. Matplotlib brownie points for any helping hands :-) Thanks in advance, Antony Lee

1 0

Matplotlib 2.2.2 - unclear license conditions for _png.cpp
by Arnold, Johann June 2, 2019

June 2, 2019

Dear Matplotlib developers, For one of our products we want to use Matplotlib 2.2.2. In order to distribute our product in a license compliant way we check the licenses of all OSS source code we are using. We do this on an file by file basis. For the file _png.cpp we have not been able to determine license situation. In file header we found the following text: // this code is heavily adapted from the paint license, which is in 4. // the file paint.license (BSD compatible) included in this 5. // distribution. TODO, add license file to MANIFEST.in and CVS 6. 7. /* For linux, png.h must be imported before Python.h because 8. png.h needs to be the one to define setjmp. 9. Undefining _POSIX_C_SOURCE and _XOPEN_SOURCE stops a couple 10. of harmless warnings. We could not find the file "paint.license", i.e. we do not know the correct license for _png.cpp. Can you please help us in order to get the correct license for _png.cpp Thanks a lot in advance and kind regards Johann Arnold Siemens AG Digital Industries Process Automation Software House Nbg DI PA CI R&D 3 Gleiwitzer Str. 555 90475 Nürnberg, Deutschland Tel.: +49 911 895-3162 Fax: +49 911 895-4010 mailto:johann.arnold@siemens.com www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> [www.siemens.com/ingenuityforlife] Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

2 2