No worries. I meant no offense by the word "hack": sometimes the
simplest approach is the best, and obviously it worked just fine for a
long time. It seems newer versions of pdflatex are starting to care
about the dpi metadata...
Mike
Gary Ruben wrote:
> Just saw this thread and thought I sh
Just saw this thread and thought I should explain that this was indeed a
hack by me which was aimed to do exactly what Michael said. I never
thought there'd be any side effects from doing this - it's interesting
that pdfLaTeX balks because it has never done so for me. Anyway, thanks
Michael for
Ok, I have a better fix in SVN r8300. imsave now accepts a "dpi" kwarg
(default of 100) to set the DPI metadata in the file.
Mike
Michael Droettboom wrote:
> You're right. Thanks for the sanity check.
>
> What's happening is that when using imsave is used, it generates a
> figure image with a
You're right. Thanks for the sanity check.
What's happening is that when using imsave is used, it generates a
figure image with a dpi of 1 (to force 1 output pixel per input pixel),
but this is sort of a hack. Let me see if I can find a way around this
hack.
Mike
Ryan May wrote:
> On Thu, M
On Thu, May 6, 2010 at 1:40 PM, Michael Droettboom wrote:
> It looks like the conversion from dots-per-inch (matplotlib's internal
> representation) to dots-per-meter (the unit defined in the PNG standard)
> was bogus. This should be fixed in SVN r8298.
Are you sure that's right? This doesn't lo
It looks like the conversion from dots-per-inch (matplotlib's internal
representation) to dots-per-meter (the unit defined in the PNG standard)
was bogus. This should be fixed in SVN r8298.
Mike
Nico Schlömer wrote:
> Hi,
>
> today I bumped into a weird issue when including a PNG generated by
