[Scipy-chaco] RE: [SciPy-user] FW: anti-grain

[eric jones]

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of David Ascher
> Sent: Friday, November 29, 2002 2:17 PM
> To: scipy-chaco at scipy.org
> Cc: scipy-user at scipy.net
> Subject: Re: [Scipy-chaco] RE: [SciPy-user] FW: anti-grain
> 
> eric jones wrote:
> 
> > Yeah.  Getting font sizes is an absolute must to layout graphs that
look
> > any good.  Otherwise axis labels and other text will be running over
> > graph lines, etc.
> 
> Axis labels aren't the issue, though -- you can delegate the
positioning
> of a
> text element to the back-end.  But title boxes etc. are an issue.

???  I don't quite get this.  We have to know the sizes of the axis
labels (both titles and numbers) to trim off enough real estate around a
plot so that the numbers don't overlap onto the graph (y labels) or onto
each other (x labels).  I'm not sure how you would do this without
precalculating the actual screen size of the text.

> 
> > So this same fontdata code will be usable across all the
PS/EPS/SVG/PDF
> > backends?  Will SVG need different data than the others?
> 
> Correct.  Although since I spoke, I cheated and simply imported the
> reportlab
> module and delegated the computation to it.  Repackaging the code is
still
> something we should do, but now it's just a packaging requirement,
which
> motivates me much less than getting good-looking graphs =).  It also
has
> maintenance implications -- some of that code deals with font encoding
> issues which I know little about.
> 
> [Aside: reportlab is way overkill for a PDF backend for Kiva -- if
that's
> an issue, know that you could probably do a PDF backend in 200 lines +
the
> font sizing code & data].

It would be better not to have the reportlab dependency if we don't
loose any capabilities, so if the backend is trivial (nearly identical
to the PS one I guess?), I'm for removing the dependency.

> 
> > It amazes me that, with all the advanced capabilities Kiva will have
> > (anti-aliased rendering, transparency, etc.), rendering text and
dealing
> > with fonts is the part that most worries me.  FreeType is only half
the
> > battle on bitmap systems -- finding/handling fonts across platforms
is
> > the other.  On vector systems, it sounds like the problems are worse
--
> > not better.  Hopefully the repackaged reportlab "standard font size
> > calculator" will solve 80-90% of the problem.
> 
> Don't get me started about fonts.  Both with PIL and with FreeType,
> chaco/kiva/scipy will need to define a font registry.  Reportlab has
> something like that, which apparently deals with Type 1 fonts, and BDF

> fonts. That's probably overkill for this project at this point.
> 
> > My sense is that HW accelerated OpenGL is amazingly fast for 3D with
> > less attention paid to the 2D stuff (which Doom doesn't care about I
> > guess).
> 
> Back when I looked at this, the major thing that OpenGL did amazingly
well
> in
> the 2-d space was anti-aliasing, transparency and zooming. Those are
very
> expensive to do in software, and cheap to do in hardware.  I've used
> PyOpenGL to do interactive 2-d applications that used all three of
those, > and the results were impressive.  I didn't have anti-grain to
compare 
> with, though.

I'm betting OpenGL will win -- or if it doesn't now, it will in the
future.  Unless there is a compelling reason to get rid of it at some
point, keeping an OpenGL backend seems like a good idea.  There are only
a few features that will be problematic with it (and probably won't be
supported).  These include "join mitering" and "line end caps."  The
other thing I'm a little worried about is thick lines.  I think some
OpenGL implementations don't support lines thicker than 10 points.
Beyond that, you have to draw a polygon.  This will lead to silly
if/then code.  There are probably other things, but Dave Morrill, has
gotten it all 90% there.

> 
> > If you left click and move the mouse around, the image is
> > scaled/rotated.  It looks plenty fast.
> 
> Cool.
> 
> > To a point.  It does create a maintenance headache.  Most Python GUI
> > APIs are, ahhemm, under documented (man is that the pot calling the
> > kettle black coming from a SciPy developer...).
> 
> Having spent some days looking in chaco/kiva, I'd have to agree =).

I promise that this will be remedied, but I won't promise when. :-)

> 
> > Dave Morrill has the same allergy.  What's with you guys??  Someone
must
> > have a shot for that.  I'll ask Dave Abrahams... way to many Dave's
> > around here.
> 
> In my case, it's got to do with the fact that I was exposed to C++
when it
> was too young for public consumption (IMO).  I never got to know 
> "grown-up" C++.
> 
> Current svgcore2d.py attached -- it works well with simple plots (try
> "python svgcore2d.py output.svg" and then look at the resulting SVG
file).  

Wait a second... Something must be wrong with the email transmission
here.  I'm missing the file where you defined all the javascript code to
support interaction with the plot.:-)

> I still have a problem with layout of composite plots, which probably
has 
> to do with the coordinate transforms that I have to apply.  I'll send
you 
> and Dave an example output and you can tell me what line I need to 
> change. =)

ok.

See ya,
Eric