Re: [matplotlib-devel] Patch for enhancement of PDF backend
"Nicolas Grilly" <[EMAIL PROTECTED]> writes: > Here is a patch I promised some time ago, to improve the PDF backend. Thanks; on first look this seems really nice! So far I have one request to you and one to John: Nicolas: would it be easy for you to strip the ^M (carriage-return) characters from your files and then re-run diff? I see in your patch several parts where the only change seems to be an addition of ^M at the end of each line, but there could be significant changes hidden within these parts. (Perhaps just give the -b option to diff? Though that might backfire if some other whitespace changes are significant, e.g. if you have changed the indentation of some code blocks.) John: Is Adobe's licensing of the AFM files compatible with matplotlib's license? I think it is, but I'm no license expert. The readme file distributed with the files contains the following text: Font Metrics for the 14 PDF Core Fonts == This directory contains font metrics for the 14 PDF Core Fonts (files with .afm extension), downloaded from http://partners.adobe.com/public/developer/font/index.html. This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification, provided that all copyright notices are retained; that the AFM files are not distributed without this file; that all modifications to this file or any of the AFM files are prominently noted in the modified file(s); and that this paragraph is not modified. Adobe Systems has no responsibility or obligation to support the use of the AFM files. -- Jouni K. Seppänen http://www.iki.fi/jks - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
Hi,
currently, PS backend does not work well with some fonts. For
instance, it displays a dotted square instead of whitespace with
Arial, and some strange dots instead of whitespace with Times New
Roman. This patch fixes it by omitting glyphs named ".notdef" from PS
output.
diff -urN matplotlib-0.90.0-orig/lib/matplotlib/backends/backend_ps.py matplotlib-0.90.0/lib/matplotlib/backends/backend_ps.py
--- matplotlib-0.90.0-orig/lib/matplotlib/backends/backend_ps.py 2006-12-20 08:39:20.0 +0300
+++ matplotlib-0.90.0/lib/matplotlib/backends/backend_ps.py 2007-02-14 16:32:06.0 +0300
@@ -776,7 +776,8 @@
lastgind = gind
thisx += kern/64.0
-lines.append('%f %f m /%s glyphshow'%(thisx, thisy, name))
+if name != '.notdef':
+lines.append('%f %f m /%s glyphshow'%(thisx, thisy, name))
thisx += glyph.linearHoriAdvance/65536.0
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for enhancement of PDF backend
On 2/14/07, Nicolas Grilly <[EMAIL PROTECTED]> wrote: > I hope there is no license issue with the AFM files. I'm pretty sure > I've seen them integrated in some TeX distributions. Apparently all we have to do is include the README along with the licensing terms. You probably should do that in the the same directory the fonts live to ensure that they are always distributed together. We also have a licenses directory. JDH - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for enhancement of PDF backend
On 2/14/07, John Hunter <[EMAIL PROTECTED]> wrote: > Apparently all we have to do is include the README along with the > licensing terms. You probably should do that in the the same > directory the fonts live to ensure that they are always distributed > together. We also have a licenses directory. In this purpose, I've provided a readme.txt file, located in the same directory as the AFM files, and containing this text: """ Font Metrics for the 14 PDF Core Fonts == This directory contains font metrics for the 14 PDF Core Fonts (files with .afm extension), downloaded from http://partners.adobe.com/public/developer/font/index.html. This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification, provided that all copyright notices are retained; that the AFM files are not distributed without this file; that all modifications to this file or any of the AFM files are prominently noted in the modified file(s); and that this paragraph is not modified. Adobe Systems has no responsibility or obligation to support the use of the AFM files. """ The original file from Adobe just contained the last paragraph; I added the first one to make clear the files origin. NG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
Sorry, I was too hasty. The patch is wrong, here is the real reason: FT2Font.get_charmap() returns a mapping from glyph index to character code. This looks like a very bad design decision to me, because several character codes can correspond to one glyph. For example, in Times New Roman, both 0x32 (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one gets lost in get_charmap(). I think, get_charmap should be fixed to return mapping from character codes to glyph indices. Alternatively, get_charmap() could be left as it is, and get_rcharmap() added. I'm willing to implement either one. Which do you prefer ? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
On 2/14/07, Evgeniy Stepanov <[EMAIL PROTECTED]> wrote: > FT2Font.get_charmap() returns a mapping from glyph index to character code. > This looks like a very bad design decision to me, because several character > codes can correspond to one glyph. For example, in Times New Roman, both 0x32 > (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one > gets lost in get_charmap(). > > I think, get_charmap should be fixed to return mapping from character codes to > glyph indices. Alternatively, get_charmap() could be left as it is, and > get_rcharmap() added. I agree with you. I've already posted something about this issue some time ago: http://sourceforge.net/mailarchive/message.php?msg_id=37418828 > I'm willing to implement either one. Which do you prefer ? I think we should prefer the first alternative: I've made a quick grep through matplotlib's code and I've observed that each time get_charmap is called, the returned dict is never used as is, but immediately reversed. -- Nicolas Grilly - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
On Wednesday 14 February 2007 21:53, Nicolas Grilly wrote:
> On 2/14/07, Evgeniy Stepanov <[EMAIL PROTECTED]> wrote:
> > FT2Font.get_charmap() returns a mapping from glyph index to character
> > code. This looks like a very bad design decision to me, because several
> > character codes can correspond to one glyph. For example, in Times New
> > Roman, both 0x32 (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of
> > course, the first one gets lost in get_charmap().
> >
> > I think, get_charmap should be fixed to return mapping from character
> > codes to glyph indices. Alternatively, get_charmap() could be left as it
> > is, and get_rcharmap() added.
>
> I agree with you. I've already posted something about this issue some
> time ago: http://sourceforge.net/mailarchive/message.php?msg_id=37418828
>
> > I'm willing to implement either one. Which do you prefer ?
>
> I think we should prefer the first alternative: I've made a quick grep
> through matplotlib's code and I've observed that each time get_charmap
> is called, the returned dict is never used as is, but immediately
> reversed.
I also prefer the first way. Here is the patch. Please re-check at least the
changes to mathtext.py, I could miss something. mathtext_demo.py still works,
but it obviously does not test all the changes.
diff --git a/examples/font_indexing.py b/examples/font_indexing.py
index 2167745..40dbc09 100644
--- a/examples/font_indexing.py
+++ b/examples/font_indexing.py
@@ -13,8 +13,7 @@ fname = matplotlib.get_data_path() + '/Vera.ttf'
font = FT2Font(fname)
font.set_charmap(0)
-codes = font.get_charmap().items()
-dsu = [(ccode, glyphind) for glyphind, ccode in codes]
+dsu = font.get_charmap().items()
dsu.sort()
#for ccode, glyphind in dsu:
#try: name = font.get_glyph_name(glyphind)
diff --git a/examples/font_table_ttf.py b/examples/font_table_ttf.py
index 14a2be3..bbf977f 100644
--- a/examples/font_table_ttf.py
+++ b/examples/font_table_ttf.py
@@ -20,15 +20,15 @@ labelr = ['00', '10', '20', '30', '40', '50', '60', '70', '80', '90',
fontname = sys.argv[1]
font = FT2Font(fontname)
-codes = font.get_charmap().items()
-codes.sort()
+indices = font.get_charmap().items()
+indices.sort()
# a 16,16 array of character strings
chars = [ ['' for c in range(16)] for r in range(16)]
colors = [ [0.95 for c in range(16)] for r in range(16)]
figure(figsize=(8,4),dpi=120)
-for glyphind, ccode in codes:
+for ccode, glyphind in indices:
if ccode>=256: continue
r,c = divmod(ccode,16)
s = chr(ccode)
diff --git a/lib/matplotlib/_mathtext_data.py b/lib/matplotlib/_mathtext_data.py
index 114d74e..5ea9790 100644
--- a/lib/matplotlib/_mathtext_data.py
+++ b/lib/matplotlib/_mathtext_data.py
@@ -8,10 +8,7 @@ font data tables for truetype and afm computer modern fonts
"""
from matplotlib.ft2font import FT2Font
font = FT2Font('/usr/local/share/matplotlib/cmr10.ttf')
-codes = font.get_charmap().items()
-rd = dict([(charcode, glyphind) for glyphind,charcode in codes])
-items = rd.items()
-items.sort()
+items = font.get_charmap().items().sort()
for charcode, glyphind in items:
print charcode, glyphind
diff --git a/lib/matplotlib/backends/backend_ps.py b/lib/matplotlib/backends/backend_ps.py
index 8cdb104..8a4391f 100644
--- a/lib/matplotlib/backends/backend_ps.py
+++ b/lib/matplotlib/backends/backend_ps.py
@@ -753,14 +753,13 @@ grestore
self.set_font(font.get_sfnt()[(1,0,0,6)], prop.get_size_in_points())
cmap = font.get_charmap()
-glyphd = reverse_dict(cmap)
lastgind = None
#print 'text', s
lines = []
thisx, thisy = 0,0
for c in s:
ccode = ord(c)
-gind = glyphd.get(ccode)
+gind = cmap.get(ccode)
if gind is None:
ccode = ord('?')
name = '.notdef'
diff --git a/lib/matplotlib/mathtext.py b/lib/matplotlib/mathtext.py
index 00cffe1..297e378 100644
--- a/lib/matplotlib/mathtext.py
+++ b/lib/matplotlib/mathtext.py
@@ -404,7 +404,7 @@ Returns the name of the glyph directly from the font object.
"""
font = self.fonts[facename]
-glyphindex = self.glyphmaps[facename][uniindex]
+glyphindex = self.charmaps[facename][uniindex]
return font.get_glyph_name(glyphindex)
def _get_info(self, facename, symbol, fontsize, dpi):
@@ -425,7 +425,7 @@ Returns the name of the glyph directly from the font object.
fontface.set_size(fontsize, dpi)
head = fontface.get_sfnt_table('head')
uniindex = self._get_unicode_index(symbol)
-glyphindex = self.glyphmaps[facename][uniindex]
+glyphindex = self.charmaps[facename][uniindex]
glyph = fontface.load_char(uniindex)
xmin, ymin, xmax, ymax = [val/64.0 for val in glyph.bbox]
# This is black magic to me (Edin)
@@ -498,7 +498,7 @@ Because BaKoma fonts don't support Unicode, 'uniindex' is misleading
"""
font = self.fon
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
On 2/14/07, Evgeniy Stepanov <[EMAIL PROTECTED]> wrote: > I also prefer the first way. Here is the patch. Please re-check at least the > changes to mathtext.py, I could miss something. mathtext_demo.py still works, > but it obviously does not test all the changes. Thanks for looking into this -- last time Nicolas brought this up back in November, Paul argued that reversing the dictionary "violated the principle of least surprise" but clearly you two disagree. If Paul is still monitoring this, he can weig in again if he still objects to the reversal. You should try tunning examples/backend_driver and looking at as many of the PS and PNG outputs as you can to make sure the text looks right, and then send on a final patch if any revisions are needed and one of us can see to it that it gets incorporated. JDH - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
John, I still feel this way, but maybe I should change my tune and let the changes go in. -- Paul On 2/14/07, John Hunter <[EMAIL PROTECTED]> wrote: > On 2/14/07, Evgeniy Stepanov <[EMAIL PROTECTED]> wrote: > > > I also prefer the first way. Here is the patch. Please re-check at least the > > changes to mathtext.py, I could miss something. mathtext_demo.py still > > works, > > but it obviously does not test all the changes. > > Thanks for looking into this -- last time Nicolas brought this up back > in November, Paul argued that reversing the dictionary "violated the > principle of least surprise" but clearly you two disagree. If Paul is > still monitoring this, he can weig in again if he still objects to the > reversal. You should try tunning examples/backend_driver and looking > at as many of the PS and PNG outputs as you can to make sure the text > looks right, and then send on a final patch if any revisions are > needed and one of us can see to it that it gets incorporated. > > JDH > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
On 2/14/07, Paul Barrett <[EMAIL PROTECTED]> wrote: > I still feel this way, but maybe I should change my tune and let the > changes go in. What do you think about the comments made earlier in this thread: > FT2Font.get_charmap() returns a mapping from glyph index to character code. > This looks like a very bad design decision to me, because several character > codes can correspond to one glyph. For example, in Times New Roman, both 0x32 > (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one > gets lost in get_charmap(). I don't remember why we did it this way originally, or if was you or I who did it, but if it is correct that the mapping is sometimes many codes point to one one glyph index, but there each glyph index must point to a single character code (the latter must be correct, right?) then reversing it seems to be the right course. But it's been a long time since I delved into freetype internals ... JDH - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib Cocoaagg backend
On 2/14/07, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote: > Dear Charles, > > I was trying to use your cocoa-agg backend for matplotlib, but it seems > to have a problem to read Matplotlib.nib. Opening this nib with > Interface Builder also gives an error. It appears that the problem is > caused by the file keyedobjects.nib in the Matplotlib.nib folder. If I > run plutil on keyedobjects.nib, it crashes. The other two files in > Matplotlib.nib look fine. So I was wondering if it is possible that the > keyedobjects.nib file included in matplotlib is damaged. If so, do you > have a valid copy of this file? > > Many thanks in advance, > > --Michiel de Hoon. We recently moved the data files, and I think the nib files got interpreted as text instead of binary files. I grabbed an old copy from a previous source release and committed them as binary. They should work now. - Charlie - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
On 2/14/07, John Hunter <[EMAIL PROTECTED]> wrote: > On 2/14/07, Paul Barrett <[EMAIL PROTECTED]> wrote: > > > I still feel this way, but maybe I should change my tune and let the > > changes go in. > > What do you think about the comments made earlier in this thread: My first reply: I suggest that this patch not be applied, since this was the intended behavior when the font manager was implemented. The standard behavior for indicating a missing character is to print a square. In addition, if a space is printed, how will you know when the formatting is correct or not. The unanticipated space could mean font is missing that character, or the layout manager has a bug? and second reply: If my memory ser ves me correctly - or if the implementation has changed over the past few years - get_charmap() is a wrapper on the FreeType method. FreeType had no reverse mapping and creating one may have caused problems later. I prefer the second alternative. If FreeType now has a reverse mapping, then by all means create a wrapper for it. If not, then you will need to take some care that get_rcharmap is reasonably future proof, so that it does cause maintenance problem later on. > > FT2Font.get_charmap() returns a mapping from glyph index to character code. > > This looks like a very bad design decision to me, because several character > > codes can correspond to one glyph. For example, in Times New Roman, both > > 0x32 > > (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first > > one > > gets lost in get_charmap(). > > I don't remember why we did it this way originally, or if was you or I > who did it, but if it is correct that the mapping is sometimes many > codes point to one one glyph index, but there each glyph index must > point to a single character code (the latter must be correct, right?) > then reversing it seems to be the right course. But it's been a long > time since I delved into freetype internals ... I think I did it. At the time the reverse mapping seemed the best approach, since this ultimately is what the code demanded. (I guess my memory has failed me!) We also did not have any examples of the many to one mapping. As you state, this has now changed and the latter must be correct. This now explains the FreeType implementation. -- Paul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
