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

Different line styles between PNG and PDF exports. #6588

Closed
afvincent opened this issue Jun 15, 2016 · 5 comments
Closed

Different line styles between PNG and PDF exports. #6588

afvincent opened this issue Jun 15, 2016 · 5 comments
Assignees
Milestone

Comments

@afvincent
Copy link
Contributor

afvincent commented Jun 15, 2016

Is the line style supposed to depend on the export backend?

MPL 1.5.1 is from Anaconda and MPL 2.x is from Github, both on Linux (CentOS 7)

With MPL 1.5.1, I get the same line styles between both PDF and PNG exports:

  • PNG @ 100 DPI:

mpl_ver_1 5 1_100dpi

while with master version, they are different between PDF and PNG exports:

  • PNG @ 100 DPI:

mpl_ver_2 0 0b1 post1628 g1aba7c3_100dpi

NB: the problem seems to be independent from the DPI value: I get similar line styles between both PNG exports with 100 DPI and 300 DPI.

  • PNG @ 300 DPI:

mpl_ver_2 0 0b1 post1628 g1aba7c3_300

The example snippet is

import matplotlib
import matplotlib.pyplot as plt
import numpy as np

test_case = matplotlib.__version__

fig, ax = plt.subplots(num=test_case, figsize=(4.8, 3.2))
ax.set_title("MPL version: {0:s}".format(test_case))

xx = np.array([0.0, 1.0])

ax.plot(xx, 1 * xx, ls='dashed', label='default lw')
ax.plot(xx, 2 * xx, ls='dashed', lw=2, label='lw=2')
ax.plot(xx, 3 * xx, ls='dashed', lw=3, label='lw=3')

ax.legend(loc='upper left')

plt.show()

for ext, dpi in (('pdf', None), ('png', 100), ('png', 300)):
    fig.savefig("MPL_ver_{v:s}_{d}.{e:s}".format(v=test_case, d=dpi, e=ext),
                dpi=dpi)

My guess would that I may be somehow related to the new behavior introduced in #5926, but I didn't have time to have a look yet.

@tacaswell
Copy link
Member

That is also my guess, it looks like the scaling is not being passed through to the pdf backend correctly.

attn @jkseppan

@tacaswell tacaswell added this to the 2.0 (style change major release) milestone Jun 15, 2016
@afvincent
Copy link
Contributor Author

I tested the same example with exports in EPS and SVG, and they look fine (i.e. like the PNG ones) even with MPL from the 2.x master branch. So it seems that the problem is indeed with the PDF backend.

@jkseppan
Copy link
Member

It seems #5926 changed the interface of GraphicsContext toward subclasses in a way that's a bit unfortunate for how the pdf backend used it

jkseppan added a commit to jkseppan/matplotlib that referenced this issue Jun 15, 2016
Factor the dash pattern scaling into a separate function so
GraphicsContextPdf.delta can call it. Combine the linewidth
and dash comparisons because now linewidth affects dashing.

Fixes matplotlib#6588
@efiring
Copy link
Member

efiring commented Jun 15, 2016

This problem also shows up in interpolation_none_vs_nearest.py in the gallery, with #6584 applied (and presumably without it). The automatic selection of the number of ticks works for the agg output but not for the pdf.

@efiring
Copy link
Member

efiring commented Jun 15, 2016

I will make a separate issue for the tick number problem.

tacaswell added a commit to tacaswell/matplotlib that referenced this issue Jul 12, 2016
When scaling the dash pattern by the linewidth do the scaling at artist
creation / value set time rather than at draw time.

closes matplotlib#6592
closes matplotlib#6588
closes matplotlib#6590
Closes matplotlib#6693
closes matplotlib#5430
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

No branches or pull requests

5 participants