From: ben.v.r...@gmail.com [mailto:ben.v.r...@gmail.com] On Behalf Of Benjamin
Root
Sent: Tuesday, August 31, 2010 23:20
I can confirm that evince also has a problem with the second image, but not
the first or the third images. This is using the latest matplotlib from svn.
Thank you for the confirmation, Ben.
Here's what I've found so far. I examined the Liberation sources (the SFD
files) in FontForge and as text, and I gather that some of them use a
non-standard encoding. Liberation Sans, for example, does not define a space
glyph with the name "space"; instead it defines a glyph for the non-breaking
space at code point U+00A0 with the name "uni00A0" and gives U+0020 (the plain
space) as an alternate encoding. (In the file LiberationSans-Regular.sfd,
these definitions start at line 2929.) However, matplotlib assumes that the
font uses Postscript's StandardEncoding. I suppose that when Postscript
processes "(some text) show", it looks for the space glyph under the standard
name "space" but finds nothing. Here is an excerpt of
matplotlib/ttconv/pprdrv_tt.cpp from SVN starting at line 415:
/*-------------------------------------------------------------
** Define the encoding array for this font.
** Since we don't really want to deal with converting all of
** the possible font encodings in the wild to a standard PS
** one, we just explicitly create one for each font.
-------------------------------------------------------------*/
void ttfont_encoding(TTStreamWriter& stream, struct TTFONT *font,
std::vector<int>& glyph_ids, font_type_enum target_type)
{
stream.putline("/Encoding StandardEncoding def");
// if (target_type == PS_TYPE_3) {
// stream.printf("/Encoding [ ");
// for (std::vector<int>::const_iterator i = glyph_ids.begin();
// i != glyph_ids.end(); ++i) {
// const char* name = ttfont_CharStrings_getname(font, *i);
// stream.printf("/%s ", name);
// }
// stream.printf("] def\n");
// } else {
// stream.putline("/Encoding StandardEncoding def");
// }
} /* end of ttfont_encoding() */
I saw in the SVN logs that the commented code for non-standard encodings had a
brief life of about a month earlier this year before being declared more
trouble than it was worth.
Getting back to the fonts, I found that not all of the Liberation fonts use
this non-standard encoding. The Liberation Sans Narrow fonts in the current
release define "space" at U+0020 with U+00A0 as an alternate encoding, and
they work fine in matplotlib EPS files. I also checked a few of the fonts in
one older release, 1.0
<https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-1.0.t
ar.gz> , and they also work correctly.
One work-around I found is to use Unicode strings for text containing spaces,
which in the EPS file causes spaces to be looked up under the glyph name
"uni00A0". If embedding Type 3 fonts, another work-around (which I only
spot-checked) is to effectively standardize the encoding by editing the EPS
file, changing "/uni00A0" to "/space" in the font definition and in glyphshow
operations that call for "/uni00A0".
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
