[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