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

[David Ascher]

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.

> 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 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.

> 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 =).

> 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).  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. =)

Cheers,

--david
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: svgcore2d.py
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20021129/795c5b3e/attachment.ksh>