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 in the glyphs. I've attached a
suggested patch which I believe brings the draw_unicode behavior into line
with the draw_text behavior for both AFM and TrueType fonts. The patch also
removes extraneous indents in multi-line PostScript strings that were
appearing in the EPS files.
I also noticed a related issue in backend_pdf: For both standard and Unicode
strings, the descender correction is computed, but the text is shifted
vertically in the canvas coordinate system rather than in the glyph
coordinate system. Therefore, y axis labels are bumped up rather than left
on the canvas. I'm not able to work on a patch at this time.
backend_ps.patch (2.03 KB)
alignunicode.py (217 Bytes)
alignunicode-afm-unpatched.eps (17.7 KB)
alignunicode-ttf-unpatched.eps (28.4 KB)
alignunicode-afm-patched.eps (17.6 KB)
alignunicode-ttf-patched.eps (27.6 KB)
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 in the glyphs. I've attached a
suggested patch which I believe brings the draw_unicode behavior into line
with the draw_text behavior for both AFM and TrueType fonts. The patch also
removes extraneous indents in multi-line PostScript strings that were
appearing in the EPS files.
Thanks for the patch. I'm sure that was just overlooked when Unicode support was added to the Ps backend.
This has been committed to SVN r6295.
I also noticed a related issue in backend_pdf: For both standard and Unicode
strings, the descender correction is computed, but the text is shifted
vertically in the canvas coordinate system rather than in the glyph
coordinate system. Therefore, y axis labels are bumped up rather than left
on the canvas. I'm not able to work on a patch at this time.
I'll have a look at this. Thanks for pointing it out.
Cheers,
Mike
···
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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 was not accounting for any descenders in the glyphs. I've attached a
suggested patch which I believe brings the draw_unicode behavior into line
with the draw_text behavior for both AFM and TrueType fonts. The patch also
removes extraneous indents in multi-line PostScript strings that were
appearing in the EPS files.
Thanks for the patch. I'm sure that was just overlooked when Unicode support was added to the Ps backend.
This has been committed to SVN r6295.
I also noticed a related issue in backend_pdf: For both standard and Unicode
strings, the descender correction is computed, but the text is shifted
vertically in the canvas coordinate system rather than in the glyph
coordinate system. Therefore, y axis labels are bumped up rather than left
on the canvas. I'm not able to work on a patch at this time.
I'll have a look at this. Thanks for pointing it out.
Fixed in SVN r6296.
Mike
···
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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 in the glyphs. I've attached a
> suggested patch which I believe brings the draw_unicode behavior into line
> with the draw_text behavior for both AFM and TrueType fonts. The patch also
> removes extraneous indents in multi-line PostScript strings that were
> appearing in the EPS files.
>
Thanks for the patch. I'm sure that was just overlooked when Unicode
support was added to the Ps backend.
This has been committed to SVN r6295.
You're welcome. For my edification, are there stylistic or other reasons to
leave the spaces in the PostScript at lines 580, 636, and 704?
···
> I also noticed a related issue in backend_pdf: For both standard and Unicode
> strings, the descender correction is computed, but the text is shifted
> vertically in the canvas coordinate system rather than in the glyph
> coordinate system. Therefore, y axis labels are bumped up rather than left
> on the canvas. I'm not able to work on a patch at this time.
I'll have a look at this. Thanks for pointing it out.
Cheers,
Mike
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 not accounting for any descenders in the glyphs. I've attached a
suggested patch which I believe brings the draw_unicode behavior into line
with the draw_text behavior for both AFM and TrueType fonts. The patch also
removes extraneous indents in multi-line PostScript strings that were
appearing in the EPS files.
Thanks for the patch. I'm sure that was just overlooked when Unicode support was added to the Ps backend.
This has been committed to SVN r6295.
You're welcome. For my edification, are there stylistic or other reasons to leave the spaces in the PostScript at lines 580, 636, and 704?
No. Just used to ignoring whitespace in diffs, since editors often do that kind of thing behind one's back. Certainly saves a few bytes in output to remove them. I'll do that.
Mike
···
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA