matplotlib-devel Mailing List for matplotlib

I've got an issue with the font specification for the SVG backend. I'm
not 100% sure it's a bug so I'm posting it for comment. Looking at the
SVG backend code, it should be simple to fix (once the correct answer is
known!). 
I'm using Bitstream Vera Sans as my default font. This gets encoded in
the SVG file as
<text style="font-size: 10.000000; font-family: BitstreamVeraSans-Roman;
stroke-width: 0.5; stroke: #000000; fill: #000000;" x="445.650013"
y="63.225600" >
 My Text Item
</text>
The font-family "Bitstream Vera Sans" is combined with the font-style
"Roman". This doesn't conform to the SVG spec: see
http://www.w3.org/TR/SVG/fonts.html#SVGFonts
it should read something like "... font-family: BitstreamVeraSans; font-
style: roman ..."
When the file is rendered (using either rsvg or inkscape), the actual
font used appears to be "Sans" (similar, but not quite identical to
BitstreamVeraSans).
My second issue is the use of white space & <CR> around the text
characters. When Inkscape renders this, the white space is included and
the carriage return results in a nasty white box character at the end of
each text item. However, rsvg doesn't render this box so things look
OK. 
I can't find anything in the svg spec to indicate that whitespace should
be ignored so I think the <CR>/<LF> and spaces should be removed.
Comments?
Bryan

John Hunter wrote:
>>>>>>"Bryan" == Bryan Cole <bry...@te...> writes:
> 
> 
> Bryan> The SVG backend, as called from the GUI frame on (GTKAgg),
> Bryan> doesn't properly close it's file object after writing the
> Bryan> data.
> 
> Bryan> I've been wondering why only half my svg-figures are saved
> Bryan> ... the write-cache wasn't being flushed until the python
> Bryan> process died.
> 
> It was my understanding that file handles close when they go out of
> scope.
No, this is NOT guaranteed behavior of Python, is implementation dependent (I 
think Jython behaves differently), and I've seen stern warnings from some core 
developers against relying on it. Matplotlib should explicitly close ALL open 
filehandles, everywhere.
> Is it enough
> to do 
> 
> svgwriter.close()
Yes, but this should be applied across all file handling operations in the 
codebase. Otherwise, it's a timebomb waiting to go off (and it will).
Best,
f

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> Anyone going to pycon? I'll be giving a talk on matplotlib
 John> on Wednesday --
 John> http://www.python.org/pycon/2005/schedule.html -- and would
 John> enjoy attaching faces to all these posts....
OK, we're official. We have a wiki!
 http://www.python.org/moin/MatplotlibSprint
Add your name to the list of participants if you want to come! Even
if you don't think you're ready to contribute code, stop by and say
hello.
JDH

Anyone going to pycon? I'll be giving a talk on matplotlib on
Wednesday -- http://www.python.org/pycon/2005/schedule.html -- and
would enjoy attaching faces to all these posts....
A sprint might be fun. It turns out that Monday is the only day I can
do a sprint. We could do something general purpose like picking goals
off the http://matplotlib.sf.net/goals.html page, or highly focused.
A few ideas, but please throw out more ideas
 * contribute to the user's guide
 * support arbitrary clipping paths
 * gradient fills for polygons
 * provide mathtext fonts that don't have the licensing restrictions
 of bakoma, eg the umbellek fonts
 * unicode support / internationalization
 
 * expose latex/tex when available for mathtext rendering
 * expose agg drawing primitives (paths, etc) directly. 
JDH

>>>>> "Bryan" == Bryan Cole <bry...@te...> writes:
 Bryan> The SVG backend, as called from the GUI frame on (GTKAgg),
 Bryan> doesn't properly close it's file object after writing the
 Bryan> data.
 Bryan> I've been wondering why only half my svg-figures are saved
 Bryan> ... the write-cache wasn't being flushed until the python
 Bryan> process died.
It was my understanding that file handles close when they go out of
scope. Did you apply a patch that fixed your problem? Is it enough
to do 
 svgwriter.close()
Is there any chance you are running this app from a threaded shell, eg
ipython in the -pylab mode or -gthread mode?
JDH

The SVG backend, as called from the GUI frame on (GTKAgg), doesn't
properly close it's file object after writing the data.
I've been wondering why only half my svg-figures are saved ... the
write-cache wasn't being flushed until the python process died.
Bryan