matplotlib-devel Mailing List for matplotlib

Hi Darren,
On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> I assigned the PS bug to myself. If anyone has some insight, I could=20
> definitely use it.
Sorry, I do not have much time at the moment, but I remember
something: the PostScript driver always got the horizontal text
extents slightly wrong, because PostScript seems to not do kerning by
itself. It is a small effect, but visible. This is especially
visible when comparing strings like "AAAAA" and "AVAVAV". Is this
what you are seeing?
To fix this one should get the kerning information from the font,
and do the kerning manually. Have a look at dvips output to get
inspiration.
All the best,
Jochen
--=20
http://seehuhn.de/

On May 3, 2005, at 6:11 PM, John Hunter wrote:
>>>>>> "Darren" == Darren Dale <dd...@co...> writes:
> Darren> I'm amazed at the amount of effort required to handle
> Darren> fonts properly.
>
> Deranged scientist in Chicago laughs maniacally....
>
It's not much appreciated that handling fonts well is one of the 
hardest aspects of any multiplatform plotting package (at least that's 
what I think).

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> If anyone can offer advice, I am a little desperate. Half
 Darren> of my plots are logscale, so I need to fix this in order
 Darren> to generate figures for my thesis. Is there anywhere I
 Darren> can look to learn the basics of dealing with fonts at this
 Darren> level? Any recommendations on C++ crash courses?
I have an idea -- it may be that the freetype module and postscript
are handling kerning differently. If for some reason freetype is
applying more kerning than the postscript machine you are rendering
with, then the bounding boxes will be smaller than the rendered ps
text. Consider this example -- the only difference between the two
strings is that in the unicode version I lay out the text character by
character and manually do the kerning myself (since postscript doesn't
have unicode I do the layout glyph-by-glyph basis)
 import pylab as p
 p.text(1,2,'AVA', fontsize=80, bbox={'pad':0})
 p.text(1,1,u'AVA', fontsize=80, bbox={'pad':0})
 p.grid()
 p.axis([0,3,0,3])
 p.savefig('test.png')
 p.savefig('test.ps')
 p.show()
The important point is that only in the regular text is the bounding
box wrong, which supports my hunch that there are different levels of
kerning in the default ps text. 
Is the kerning information getting embedded?
Do some research on embedded truetype fonts and postscript kerning and
see if anything turns up.
We might consider using the unicode layout engine for *all* text as a
quick fix. We would pay a performance cost to do this, and it might
break numerical superscripting temporarily....
 Darren> I'm amazed at the amount of effort required to handle
 Darren> fonts properly.
Deranged scientist in Chicago laughs maniacally....
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I have a little more information. When I set ps.useafm
 Darren> =True in .matplotlibrc, eps output looks good, there is no
 Darren> mismatch between the bboxes and the text. I'm guessing
 Darren> the bug may be in either backend_ps.encodeTTFasPS, or
 Darren> somewhere in ft2font.h. Unfortunately, I have zarro
 Darren> experience with C++, so I'm having a hard time
 Darren> interpretting ft2font.
 Darren> If anyone can offer advice, I am a little desperate. Half
 Darren> of my plots are logscale, so I need to fix this in order
 Darren> to generate figures for my thesis. Is there anywhere I
 Darren> can look to learn the basics of dealing with fonts at this
 Darren> level? Any recommendations on C++ crash courses?
I don't think the bug is in ft2font for the simple reason that the
same ft2font code is being used to do the agg layout and the ps
layout (and agg is pretty close to right). It could be that we are
not setting the dpi and fontsize in backend ps, it could be that we
are not setting some scale parameter when we embed the fonts in ps,
I'm not sure. Did you get a chance to send a figure to the printer
yet?
JDH

On Monday 02 May 2005 4:03 pm, Darren Dale wrote:
> It looks like there is a bug in the text bounding boxes. It causes some
> problems in the postscript backend, where I noticed badly formatted
> logscale ticks. It looks like the bug exists in the AGG backend as well,
> although it is less noticeable there. I filed two bugs at the sf website,
> with images of bboxes that dont fit their associated text. You can also run
> the script below, but you will need a recent update of patches.py, John
> fixed a bug there today.
I have a little more information. When I set ps.useafm =True in .matplotlibrc, 
eps output looks good, there is no mismatch between the bboxes and the text. 
I'm guessing the bug may be in either backend_ps.encodeTTFasPS, or somewhere 
in ft2font.h. Unfortunately, I have zarro experience with C++, so I'm having 
a hard time interpretting ft2font.
If anyone can offer advice, I am a little desperate. Half of my plots are 
logscale, so I need to fix this in order to generate figures for my thesis. 
Is there anywhere I can look to learn the basics of dealing with fonts at 
this level? Any recommendations on C++ crash courses?
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...

>>>>> "Zelakiewicz," == Zelakiewicz, Scott (Research) <zel...@cr...> writes:
 Scott> I routinely plot fairly large datasets (~4million
 Scott> points) using imshow but on my machine this takes
 Scott> about 11 secs to complete. I went through the code
 Scott> and made a couple of minor changes where the image
 Scott> data would get clipped by vmax and vmin only if the
 Scott> user supplied a vmax or vmin. The clipping is
 Scott> unnecessary if the user does not supply these values
 Scott> since vmax and vmin default to the max and min in
 Scott> the image. I also replaced two successive
 Scott> where(...) calls with a single clip(...) call and
 Scott> that seems to have helped a tiny bit as well. This
 Scott> change has been tested on 0.80 compiled with
 Scott> Numeric, though I can't envision how this would
 Scott> break anything. The profiler tells me that my plot
 Scott> time has decreased from 11.8 sec to 7.2 sec. Hope
 Scott> this helps.
Thanks Scott -- this simple optimization should help a lot with common
use cases. I've applied it in my local tree (hasn't made CVS yet
because there are other more significant changes I'm working on that I
can't commit yet).
Thanks!
JDH