matplotlib-devel Mailing List for matplotlib

May I ask again for hints ???

> However, there is problem with the asterisk symbols I'm not sure how to
> solve, and I ask for your advice!!! As you can see in the attached
> example output, custom_symbol2a.png, the length of the arms of the
> asterisk-symbol appear different even so have numerically all the same
> length. An asterisk-symbol is drawn by connecting the origin (0,0) with
> one end of an arm, e.g. (1,0) and again back to the origin (0,0), then
> to the next end of an arm and so on.
> - Is there a better way to do this?
> - And is there a way to avoid output artefacts like those in the example
> attached ?
> 
> The artefact seems to be present for a pixel-devices only (like .png)
> but not for a vector-drawing-device like eps :-( So it seems that it is
> an issue of rounding to int ???

The basic question is: is there a way to ensure that a line is drawn
with a fixed length irrespective of location and direction of the line.

I really would like to add more features (line-style symbols for
scatter), but the actual problem makes the patch embryonic ...

Manuel

Hi Paul,

On 11/6/06, Paul Barrett <peb...@gm...> wrote:
> 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.

Ok.

> 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.

I disagree. Method FT2Font::get_charmap doesn't return the list of
available character maps; it returns a dictionary mapping glyph
indices to character codes in the *current character map*.

You wrote "other character maps can be specified by providing an
argument to get_charmap", but method FT2Font::get_charmap doesn't
accept any parameter (I looked at line 1208 of file ft2font.cpp).

> In addition, changing this method to return the reverse mapping would
> violate the rule of least surprise.

Yes, but in my opinion, this is the current solution that violates
"the rule of least surprise".

Method FT2Font::get_charmap calls two important methods of FreeType:
FT_Get_First_Char and FT_Get_Next_Char. These two methods are used to
parse all character codes from first to last in the current character
map, and returning corresponding glyphs.

You can read those methods description and an example at this URL:
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Get_First_Char

Reading this example, it seems apparent the "least surprising
solution" is a mapping from character codes to glyph indices, doesn't
it?

> Note that creating the reverse dict is easy in Python.

Yep, it's why we love programming in Python!