Re: [matplotlib-devel] should set_xlim turn off x autoscaling?
Seems like a reasonable request to me. When I use xlim to specify the axes in a plot session, I tend to use it multiple times. Therefore this default behaviour would seem reasonable. On Sun, Jun 27, 2010 at 4:40 PM, Eric Firing wrote: > The present behavior of set_xlim and set_ylim can be surprising because > making the values stick for subsequent plotting in the same axes > requires manually calling set_autoscalex_on(False) etc. It would seem > more logical if set_xlim itself included the call to turn autoscalex > off--isn't that what a user would almost always want and expect? > > Rectifying this would constitute a significant change affecting some > existing user code. > > What are people's thoughts on this? Should the change made? If so, do > it abruptly, right now, as part of version 1.0? Or phase it in with a > temporary kwarg and/or rcparam? It would be nice to avoid all that > complexity, but may be we can't, except by leaving everything as it is now. > > Eric > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about ft2font.get_charmap
On 11/5/06, Nicolas Grilly <[EMAIL PROTECTED]> wrote: > In module ft2font, the method FT2Font.get_charmap returns a dict that > maps glyph indices to char codes. > > I don't understand the purpose of this mapping, and why the method > doesn't return the reverse mapping, i.e. char codes mapped to glyph > indices. The ft2font module provides a Python interface to the FT2Font C API. get_charmap is one of the methods in this API as is set_charmap. A font can have multiple character maps. get_charmap() returns the default one. Others can be specified by providing an argument to get_charmap(). To add a new charmap to the font, you must first find out what charmaps it contains, so get_charmap is needed for this. In addition, changing this method to return the reverse mapping would violate the rule of least surprise. Note that creating the reverse dict is easy in Python. -- Paul > For example, in backend_ps.py, line 754, the charmap is immediately > reversed, just after being loaded: > > cmap = font.get_charmap() > glyphd = reverse_dict(cmap) > > Thanks, > > Nicolas Grilly > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ 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, 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
Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend
That's fine with me. -- Paul On 2/16/07, Edin Salkovic <[EMAIL PROTECTED]> wrote: > On 2/14/07, Paul Barrett <[EMAIL PROTECTED]> wrote: > > 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. > > > > (...) > > > 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 > > > > I used the wayback machine to search the FreeType docs. See: > http://web.archive.org/web/19990302062419/www.freetype.org/docs/user.txt > > In 1999 (FreeType 1) you had to use the same approach as today - > convert character code to glyph index, not vice versa. From the above > file: > === > (...) > g. Load the glyph: > > The glyph loader is easily queried through TT_Load_Glyph(). > This API function takes several arguments: > > o An instance handle to specify at which point size and > resolution the loaded glyph should be scaled and grid-fitted. > > o A glyph container, used to hold the glyph's data in memory. > Note that the instance and the glyph must relate to the _same_ > font file. An error would be produced immediately otherwise. > > o A glyph index, used to reference the glyph within the font > file. This index is not a platform specific character code, > and a character's glyph index may vary from one font to > another. To compute glyph indexes from character codes, use > the TT_CharMap handle created in section (f.) with > TT_Char_Index(). > > We strongly recommend using the Unicode charmap whenever > possible. > (...) > === > > From the FAQ (same year): > === > 25. Does FreeType support "foreign languages"? > > Short Answer: YES, it does! > > From a TrueType font file point of view, there are several parts > to the file, one of them being the 'glyphs', i.e. picture > representation of the symbols. > > Another part is the mapping table, also called "charMap". > > For example, glyph #1 could be letter "A", and glyph #2 could be > letter "Z". Glyphs can be stored in any order in a font file. > > The mapping tables contains at least one char-map entry. For > example, you could have an ASCII-map that maps 0x41 to glyph #1, > and 0x5A to glyph #2, etc. FreeType provides a "charMap" object > class to access and use this information easily. > > There are several character encodings recognized and defined by > the TrueType specification, like Latin-1, Unicode, Apple Scripts, > WGL, etc., but a font file might only contain one or two of them. > > When using a more 'exotic' character encoding, like EBCDIC (this > is IBM mainframe stuff!), you would need to translate it to one of > the available formats (or to add a charmap table to the font). > Cf. section 8. > === > > From the above it's clear that FreeType *never* explicitly supported > the glyph->char mapping, but exactly the opposite. > > In conclusion, I agree with Nicolas' proposition to change get_charmap > to do what it *should* do, map chars to glyph indexes. > > If others agree, I could try to make the changes to SVN this weekend. > > > Best, > Edin > - 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
