Stan West wrote:
>> Stan West wrote:
>>
>>> While labeling axes with both standard and Unicode strings, I noticed some
>>> alignment problems in EPS output, as in the attached examples. I traced it
>>> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
>>> latter was
> Stan West wrote:
> > While labeling axes with both standard and Unicode strings, I noticed some
> > alignment problems in EPS output, as in the attached examples. I traced it
> > to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
> > latter was not accounting for any de
Michael Droettboom wrote:
> Stan West wrote:
>
>> While labeling axes with both standard and Unicode strings, I noticed some
>> alignment problems in EPS output, as in the attached examples. I traced it
>> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
>> latter wa
Stan West wrote:
> While labeling axes with both standard and Unicode strings, I noticed some
> alignment problems in EPS output, as in the attached examples. I traced it
> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
> latter was not accounting for any descenders i
Stan West wrote:
> Thank you, Mike, for your reply. My understanding of the intent of the code
> is that if the weight is not found in the font dict, setWeights is called to
> supplement the dict with the missing weights, and the weight is sought again
> in the supplemented dict. That would seem
Thank you, Mike, for your reply. My understanding of the intent of the code
is that if the weight is not found in the font dict, setWeights is called to
supplement the dict with the missing weights, and the weight is sought again
in the supplemented dict. That would seem to effect the desired app
This is a longstanding known issue -- the font finding algorithm is way
too precise, and should instead do a nearest-neighbor search similar to
fontconfig. It's a non-trivial bit of code that no one has yet found
time for.
If you're running matplotlib 0.98.x and are on a non-Windows platform,
Greetings. It seems that a "not" operator got dropped in rev. 6143 to
font_manager.py. I've attached a patch.
The missing "not" tripped up findfont when trying to match font weights: the
code
fm = matplotlib.font_manager.FontManager()
fm.findfont('New Century Schoolbook', fontext='afm')
Thanks Eric.
You know that this has been on my wish list for a long time.
Let me know if I can test anything or help in any other way,
Mark
On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED]> wrote:
> Mark Bakker wrote:
>
>> Hello list (especially Erik, who can fix this I hope) -
Mark Bakker wrote:
> Hello list (especially Erik, who can fix this I hope) -
>
> I have had problems with shared axes, especially when one of the axis
> has an aspect ratio that is set 'equal'. It has been discussed on the
> list before (mostly with Erik Firing), but it hasn't been fixed yet.
>
10 matches
Mail list logo
