[Biopython-dev] [Bug 2711] GenomeDiagram.py: write() and write_to_string() are inefficient and don't check inputs

bugzilla-daemon at portal.open-bio.org bugzilla-daemon at portal.open-bio.org
Mon Dec 15 10:51:30 UTC 2008


http://bugzilla.open-bio.org/show_bug.cgi?id=2711





------- Comment #9 from lpritc at scri.sari.ac.uk  2008-12-15 05:51 EST -------
(In reply to comment #3)
>As an aside, I'd like write_to_string() to support a DPI argument like write()
> does.

The way I originally intended write_to_string() to be used - sending graphics
to a browser - the DPI has no influence at all.  DPI is only of any importance
for printing graphics: the DPI translates the pixel size into the final printed
size of the image.  The image you see on screen (assuming no fancy browser
scaling) is pixel-per-pixel.  That's why I left it out.

It may be that people have a sensible reason for writing their image output to
string - rather than binary - encoding, for writing to a file.  I'm not clear
on what that would be, but it's possible.  In that case, I think that an
appropriate merging of the write() and write_to_string() methods could be:

def write(self, filename=None, output=default_output, dpi=default_dpi,
encoding=default_encoding):

encoding could then be either 'binary' (default), or 'string' - which would
emulate write_to_string()'s function.

Where handle is not None, the resulting output would be sent to the passed
handle - which could potentially include sys.stdout.  Where handle is None, the
method could return the encoded image directly, as write_to_string() does, now.

Other than the obvious problem with ReportLab's drawToFile requiring a
filename, rather than a handle - does this seem like a reasonable plan to
others?


-- 
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the Biopython-dev mailing list