text bbox, postscript formatting problem

Development matplotlib-devel
1

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 assigned the PS bug to myself. If anyone has some insight, I could
definitely use it.

Darren

http://sourceforge.net/tracker/index.php?func=detail&aid=1177396&group_id=80706&atid=560720

from pylab import *

def addtext(props):
    text(0.5, 0.5, 'xx-small', props, fontsize='xx-small')
    text(1.5, 0.5, 'x-small', props, fontsize='x-small')
    text(2.5, 0.5, 'small', props, fontsize='small')
    text(3.5, 0.5, 'medium', props, fontsize='medium')
    text(4.5, 0.5, 'large', props, fontsize='large')
    yticks([0,.5,1])

# the text bounding box
bbox = {'fc':0.8, 'pad':0}

figure(1,figsize=(5,2))
axes()
addtext({'ha':'center', 'va':'center', 'bbox':bbox})
xlim(0,5)
savefig('/home/darren/temp/bbox.eps')
savefig('/home/darren/temp/bbox.png')
show()

2

Hi Darren,

I assigned the PS bug to myself. If anyone has some insight, I could
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

···

On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
--

3

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?

···

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.

--
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd55@...143...

4

Hi Jochen,

Thanks for responding. I'll continue looking into this tomorrow. For now, I
posted a new eps file in the sourceforge bugreport, which renders the
suggested strings. You are right, the effect is especially visible when
rendering 'AVAVAV'.

By the way, did you know MoonBuggy is in the gentoo package management tree?

···

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:

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

--
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd55@...143...

5

Hi Darren,

> I assigned the PS bug to myself. If anyone has some insight, I could
> 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.

I just finished reading Adobe's Technical Note #5012: The Type 42 Font Format
Specification. The only mention of kerning is on page 12, indicating that
performance can be improved by including only those type 42 tables that are
actually used by the TrueType rasterizer. It implies that kerning tables are
not used.

I also had a look at the dvips output, and get the general idea of how it
handles layout. So let me ask, why does mathtext break with afm fonts? Is it
inherent, or could mathtext.py (or backend_ps.py) be changed to cooperate
with afm? From looking at the dvips output, a naive individual like myself
might think it is pretty straight forward to render something like
r'My test string A=A\_0e^\(i\\theta\)'.
(I'm not saying it would be easy to implement.)

Dvips embeds four fonts to render my example string: CMMI7, CMR7, CMMI10,
CMR10. Here is the output, I clipped the start of the file up to the end of
the font defs:

%%EndFont
TeXDict begin 40258431 52099146 1000 600 600 (temp.dvi)
@start /Fa 150[23 86[32 18[{}2 58.1154 /CMMI7 rf /Fb
207[33 48[{}1 58.1154 /CMR7 rf /Fc 154[39 35[62 65[{}2
83.022 /CMMI10 rf /Fd 134[44 4[32 33 33 3[46 4[23 1[42
1[37 23[76 15[65 11[42 49[{}11 83.022 /CMR10 rf end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 600dpi
TeXDict begin
end
%%EndSetup
%%Page: 1 1

I'm not sure what that first block is doing (yet), but here is the important
part:

TeXDict begin 1 0 bop 639 523 a Fd(My)28 b(test)g(string)f
Fc(A)c Fd(=)g Fc(A)1420 535 y Fb(0)1457 523 y Fc(e)1496
493 y Fa(i\022)1926 5255 y Fd(1)p eop end

Its essentially a group of moveto statements and font changes. It looks like
the kerning support is sort of a hybrid, where you dont have to layout each
glyph independently, but layout is done manually between groups of glyphs.

I guess I havent considered rendering in AGG.

Darren

···

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:

On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote: