refigure2: PDF generation

[Richard Thomas]

I'm just returning to using Reinteract after a break of a year or two - now using Reinteract 0.5.10 on Windows XP SP3 (installed using the provided installer, complete with the associated local versions of matplotlib etc), partly spurred on by the ability to generate PDFs so I can share my results with non-Reinteract users. Printing works very well with the "replot". However, previously I have happily used refigure and I've found that refigure2 (v 0.4.0) does not generate properly with PDF generation or printing. with printing the plot gets massively zoomed off the page so I just see a tiny corner of a supersized plot. Export to PDF generates text fine, but no plot at all, though as the export dialog does not go away and the PDF file remains locked until Reinteract is quit it suggests that it is going belly up whilst trying to do the refigure2 plots.

Is this a known problem?

Solvable by getting a newer version of Reinteract from GIT? (a route I was hoping to avoid as I had quite a bit of hassle getting this working well last year)

Richard

[Robert Schroll]

On 08/29/2012 08:24 AM, Richard Thomas wrote:
> I've found that refigure2 (v 0.4.0) does not generate properly with PDF
> generation or printing. with printing the plot gets massively zoomed off
> the page so I just see a tiny corner of a supersized plot. Export to PDF
> generates text fine, but no plot at all, though as the export
> dialog does not go away and the PDF file remains locked until Reinteract
> is quit it suggests that it is going belly up whilst trying to do the
> refigure2 plots.

I might know what's going on. In print_result, try changing
cdpi = context.get_dpi_x()
(line 210 in 0.4) to
cdpi = float(context.get_dpi_x())

On my system, context.get_dpi_x() returns a float when printing but an
int on exporting to PDF. This leads to integer division and I think a
zero where I expect a non-zero number. I could reproduce the freeze on
export, and this solved it.

I'm not seeing the humongous figure issue. It could be that this fix
solves that as well. But it might not. Let me know one way or the other.

Thanks for the report,
Robert

[Owen Taylor]

I fixed a humongous figures on Windows issue in replot last year:

commit e3644466099ce4c6278a73a99f745a31c32f5f40
Author: Owen W. Taylor <ota...@fishsoup.net>
Date: Thu Sep 22 23:17:32 2011 -0400

replot.py: don't pass the printer's resolution to matplotlib

matplotlib's Figure.set_dpi() expects a scale factor between
drawing units and inches. This is always 72 for us when printing,
without regard to what the printer reports as its dots-per-inch
which might be, for example, 600. (Fixes mis-sized plots on
Windows.)

Most likely refigure needs the same fix.

- Owen

[Richard Thomas]

On 29/08/2012 18:38, Robert Schroll wrote:

On 08/29/2012 08:24 AM, Richard Thomas wrote:

I've found that refigure2 (v 0.4.0) does not generate properly with PDF
generation or printing. with printing the plot gets massively zoomed off
the page so I just see a tiny corner of a supersized plot. Export to PDF
generates text fine, but no plot at all, though as the export
dialog does not go away and the PDF file remains locked until Reinteract
is quit it suggests that it is going belly up whilst trying to do the
refigure2 plots.

I might know what's going on.  In print_result, try changing
    cdpi = context.get_dpi_x()
(line 210 in 0.4) to
    cdpi = float(context.get_dpi_x())

On my system, context.get_dpi_x() returns a float when printing but an int on exporting to PDF.  This leads to integer division and I think a zero where I expect a non-zero number.  I could reproduce the freeze on export, and this solved it.

This fixes the PDF problem completely - thanks.

I'm not seeing the humongous figure issue.  It could be that this fix solves that as well.  But it might not.  Let me know one way or the other.

Still get the oversized figure problem when printing, so the issue Owen highlighted might be the culprit.

There is also a problem that when printing any "printer preferences" selected from the print dialog box get ignored - it sends it straight to the printer with default settings. This seems to be unchanged from when I reported the problem last year, though it seemed to be OK on Windows 7 for Owen (I'm using Windows XP SP3):

On 23/09/2011 04:27, Owen Taylor wrote:

Printing problems
~~~~~~~~~~~~~~
If I use "Print", then select "Preferences" (and mark my preferences -
specifically to include print preview), it just ignores them.
Hmm, testing on Windows 7 with the included "Microsoft XPS Document
Writer" it seems to work correctly for preference handling. Not sure
what is going on for you.

Richard 

[Robert Schroll]

On 08/30/2012 04:22 AM, Richard Thomas wrote:
> Still get the oversized figure problem when printing, so the issue Owen
> highlighted might be the culprit.

Probably. Try changing that same line to
cdpi = 72.0
Let me know if it works, so I know what needs to be changed.

Thanks
Robert

[Richard Thomas]

Yes - that works and the sizing of the graph looks sensible.

Richard

[Robert Schroll]

Thanks for testing. I'll make this change in refigure2.

BTW, if you want something else to worry about, here's something:
refigure2 has three printing mechanisms - printing directly through
cairo, printing with a PDF intermediary, and printing via a bitmap. I
suspect you're using the last. For printing, this is fine. But if
you're making PDFs for sharing, it might produce rather large files.

If this worries you (and I'm not saying it should), the two easiest
solutions would be to

1) Use the Cairo mechanism, which will happen automatically if you're
using the GTKCairo backend to matplotlib. (Just make the change to your
matplotlibrc file.)

2) Change the printing resolution for the bitmap mechanism. You can do
this by creating a file named refigurerc in the same directory as your
matplotlibrc file, and adding to it the line
refigure.printdpi: 150
You can play with the number until you reach the sweet spot of size vs.
quality.

But as I said, this isn't something to worry about too much if it isn't
bothering you.

Robert

P.S. I did see your other question, but I haven't had time to think
about it yet.