Re: [matplotlib-devel] dpi-related positioning errors in Agg savefig
John Hunter wrote: > On Sun, Apr 27, 2008 at 3:14 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > > >> 1) The hline generated by frac is too long with dpi=50. >> > > The problem with the hline appears to be that the width of the line in > the frac has a component that depends on the thickness > > thickness = state.font_output.get_underline_thickness( > state.font, state.fontsize, state.dpi) > width = max(num.width, den.width) + thickness * 10. > > and get_underline_thickness here is defaulting to 1.0 because of this > max call in get_underline_thickness > > return max(1.0, cached_font.font.underline_thickness / 64.0 / > fontsize * 10.0) > I believe that this is where the dpi needs to be factored in. Ft2font (well, freetype, really) seems to scale metrics for individual glyphs by dpi, but not the font-global metrics. I had wrongly assumed they were all scaled by dpi. So this is a subtler instance of the recent x-height bug that caused sub/superscripts to be incorrect at different dpi's. > Michael -- what is the role of these 10.0 scale factors, which is > showing up in both the frac call and the get_underline_thickness? Is > this something from Knuth, or is it a fudge factor that gets it mostly > right? I suspect we will need something like > > width = max(num.width, den.width) + thickness * 10. * state.dpi/72. > This 10.0 is from Knuth. It is the amount of overhang of the fraction beam, and is meant to be relative to the thickness of the beam itself. The other 10.0 (in get_underline_thickness) is my own experimental fudge to deal with the peculiarities of how underline thickness is stored in Truetype fonts. (Remember "pure" TeX uses a completely different font metric standard, so some mapping from TrueType/freetype etc. had to be fudged on.) What's causing the fraction bar to be too wide at lower dpi is the minimum underline thickness of 1.0 enforced in get_underline_thickness. I think that was a mistake -- enforcing 1.0 pixel lines should happen closer to the backend level -- so I've removed the max(1.0, ...) there. > but with this change the frac bar looks a little too wide -- which is > why I'm wondering if there is something magic about 10. or if another > number might serve better. > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] fonts pixelated in rotated text
John Hunter wrote: > On Fri, Apr 25, 2008 at 2:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > >> I'm stumped. It looks like the code (and even the inputs to >> draw_text_image) are virtually identical, modulo the differences between Agg >> 2.3 and 2.4. Maybe the change is in Agg, and 2.4 is theoretically more >> correct? We can always experiment with different kernels and parameters >> until finding one that looks right. >> > > I'll poke around with this then -- I was hoping the report would > trigger some memory about a font change you made. I don't recall any font changes -- if you diff ft2font.cpp in 0.91.2 and trunk you'll see they're virtually identical. And the unrotated text looks identical to me. > The differences in > the 2.3 and 2.4 agg incantations were all I could see too -- I wonder > if some default template parameter that is different in 2. is creeping > in. > Perhaps. I was going to check the Agg examples to see if the spline filters look different there, too, but I can't get 2.3 to compile anymore for some reason, so I gave up for now. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] superscript and font size
Paul Kienzle wrote: > On Thu, Apr 24, 2008 at 08:38:02AM -0400, Michael Droettboom wrote: > >> Paul Kienzle wrote: >> >>> Hi, >>> >>> The superscripts in mpl don't seem to be placed at the correct height for >>> small fonts. The y-tics on the attached plot shows this. The effect is >>> similar in svg and pdf backends. >>> >>> >> Thanks. When looking up the x-height, the code was not taking the font >> size into account. This has been fixed on the branch and trunk. >> > > Thanks. It looks much better in png, but pdf has the subscript raised much > higher, That was a DPI-related bug, that is hopefully now fixed in SVN. > and svg isn't rendering fonts at all (see attached). > Thanks. The SVG was broken in SVN March 26 trying to workaround an Inkscape copy/paste bug. I think it is fixed now so it works in Mozilla and Inkscape simultaneously. But please let me know if you see anything fishy -- there seems to be a great deal of variability between SVG viewers. Are you seeing this bug with 0.91.2 release, or just the 0.91.2 SVN branch? I'd be surprised by the former (and I can't reproduce it there). Cheers, and thanks for your patience, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] superscript and font size
On Mon, Apr 28, 2008 at 09:51:54AM -0400, Michael Droettboom wrote: > Paul Kienzle wrote: > > > > Thanks. It looks much better in png, but pdf has the subscript raised much > > higher, > That was a DPI-related bug, that is hopefully now fixed in SVN. > > and svg isn't rendering fonts at all (see attached). Yes. > Thanks. The SVG was broken in SVN March 26 trying to workaround an > Inkscape copy/paste bug. I think it is fixed now so it works in Mozilla > and Inkscape simultaneously. But please let me know if you see anything > fishy -- there seems to be a great deal of variability between SVG viewers. Works in Safari 3.1.1, Inkscape 0.45 and FF 2.0.0.14 > Are you seeing this bug with 0.91.2 release, or just the 0.91.2 SVN > branch? I'd be surprised by the former (and I can't reproduce it there). 0.91.2 SVG does indeed work (with the old superscript position of course). - Paul - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] imshow() gives nearly inscrutable error message on complex arrays
Hi all,
I just discovered that attempting to plot a complex array using imshow()
results in a not-very-helpful traceback (attached). Would it be worth
catching this on the actual call to imshow() and raising a more
transparent error? (The test script, slightly modified from Gaël
Varoquaux's pyreport examples is attached and makes a beautiful plot and
is also attached.)
-Andrew
Traceback (most recent call last):
File "mpl-test.py", line 27, in
savefig('x.png')
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/pyplot.py",
line 271, in savefig
return fig.savefig(*args, **kwargs)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/figure.py",
line 947, in savefig
self.canvas.print_figure(*args, **kwargs)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 1085, in print_figure
**kwargs)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py",
line 103, in print_png
return agg.print_png(filename, *args, **kwargs)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 300, in print_png
FigureCanvasAgg.draw(self)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 256, in draw
self.figure.draw(self.renderer)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/figure.py",
line 791, in draw
for a in self.axes: a.draw(renderer)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/axes.py",
line 1368, in draw
im.draw(renderer)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/image.py",
line 226, in draw
im = self.make_image(renderer.get_image_magnification())
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/image.py",
line 176, in make_image
x = self.to_rgba(self._A, self._alpha)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/cm.py",
line 76, in to_rgba
x = self.cmap(x, alpha=alpha, bytes=bytes)
File
"/home/astraw/py2.5-linux-x86_64/lib/python2.5/site-packages/matplotlib/colors.py",
line 460, in __call__
lut.take(xa, axis=0, mode='clip', out=rgba)
TypeError: array cannot be safely cast to required type
from numpy import *
from pylab import *
#from pylab import imshow
#!
#! Some graphical explorations of the Julia sets with python and pyreport
#!#
#$
#$ We start by defining a function J:
#$ \[ J_c : z \rightarrow z^2 + c \]
#$
def J(c):
return lambda z : z**2 + c
[x,y] = ogrid[ -1:1:0.002, -1:1:0.002 ]
z = x + y *1j
#! If we study the divergence of function J under repeated iteration
#! depending on its inital conditions we get a very pretty graph
threshTime = zeros_like(z)
for i in range(40):
z = J(0.285)(z)
threshTime += z*conj(z) > 4
figure(0)
axes([0,0,1,1])
axis('off')
imshow(threshTime)
bone()
savefig('x.png')
show()
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow() gives nearly inscrutable error message on complex arrays
Andrew Straw wrote: > Hi all, > > I just discovered that attempting to plot a complex array using imshow() > results in a not-very-helpful traceback (attached). Would it be worth > catching this on the actual call to imshow() and raising a more > transparent error? (The test script, slightly modified from Gaël > Varoquaux's pyreport examples is attached and makes a beautiful plot and > is also attached.) The problem is most likely quite general, so the solution should be similarly general. I suspect there is no place in mpl where a complex input makes sense. Eric - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
