Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Come to think of it, I think the inheritance of draw and fill attributes
that happen along the path would take advantage of traitlets if you guys
decide to go that route.

On Fri, May 15, 2015 at 11:40 AM, Neil Girdhar 
wrote:

> Okay, I'm going to wait for more feedback.  An hour of design can be worth
> ten hours of implementation :)
>
> On Fri, May 15, 2015 at 11:11 AM, Thomas Caswell 
> wrote:
>
>> I would advocate for calling yours something different.  path.Path is
>> really a container for a Bezier curve and is probably best left as simple
>> as possible.  There is probably an interesting discussion about right is-a
>> and has-a relations between Path,  FancyPath (don't use that name!), and
>> FancyArrow (which I do not have a clear view of yet).
>>
>> Tom
>>
>> On Fri, May 15, 2015 at 11:04 AM Neil Girdhar 
>> wrote:
>>
>>> On Fri, May 15, 2015 at 10:53 AM, Thomas Caswell 
>>> wrote:
>>>
 A few very quick comments (just skimmed the docstrings)

 We already have a mpl.path.Path class, please don't shadow that.

>>>
>>> I read the Path class and based mine on that.  The problem is that I
>>> want to be able to place nodes along the path (like labels) and so I need
>>> to ask it questions.  Maybe we should just extend the existing Path class?
>>> Or else we should call my Path something different?
>>>
>>>
 Is your `Path` going to be an `Artist` that is responsible for drawing
 it's self or does in serve a role like the existing `Path` in that it is
 used by other artists as part of their `draw`?

 This feels very similar to the `FancyArrow` (with classes being passed
 in to control how the arrow is styled), would this make sense as an
 extension to that code?  This does seem more general, maybe it makes sense
 to start from scratch and implement `FancyArrow` in terms of this code.

>>>
>>> Yes!  Didn't know about that.  I think modifying and extending that code
>>> might be a good way forward.
>>>
>>>
>>>

 Tom

 On Fri, May 15, 2015 at 10:40 AM Neil Girdhar 
 wrote:

> I have a draft proposal of the long term goal for what an interface
> could look like for drawing arrows between coordinates or nodes.  I based
> the design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf),
> so it might help to flip through that to get an idea for the basis of this
> design.  I tried to separate the creating of Path objects with the drawing
> of paths since it's often really useful when compositing layouts to be 
> able
> to do math with with the positions of things before drawing anything.  For
> example, when automatically positioning nodes.
>
> I'm not committed to this design; it's just an outline to get feedback.
>
> Best,
>
> Neil
>
> class Axes_(_AxesBase):
> def path(self, path, draw=True, fill=False):
> """
> If draw is not falsy, draws along the path using the draw
> specification.
> If fill is not falsy, fills the closed path using the fill
> specification.
>
> Parameters
> --
> path is a Path object or path commands with which to create
> one.
>
> draw is a draw specification:
> either the value True, which indicates some defaults, or
> else
> False, or else a dictionary with the following keys:
> color
> opacity
> line_width
> line_join
> begin_tip is a Tip object
> tip or end_tip is a Tip object
> dashed is a dash specification
>
> a dash specification
> either dictionary containing:
> dash_pattern
> an iterable of numbers specifying the length of
> the dashes
> and gaps in points.  E.g., [2, 3, 4, 3] means on
> for 2
> points, off for 3, on for 4, off for 3, i.e.,
> dash-dotted.
> dash_phase
> Shifts the start of the dash pattern by dash_phase
> points.
> or a string, one of:
> 'solid'
> 'dotted', 'densely dotted', 'loosely dotted'
> 'dashed', 'densely dashed', 'loosely dashed'
> 'dash dot', 'densely dash dot', 'loosely dash dot'
> 'dash dot dot', 'densely dash dot dot', 'loosely dash
> dot dot'
>
> fill is a fill specification:
> TODO
> """
>
> class Path:
> def __init__(self, path_commands):
> """
> path_commands is either
> a coordinate (representing a move to in the first
> position, or a
> line to in any other position)

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Okay, I'm going to wait for more feedback.  An hour of design can be worth
ten hours of implementation :)

On Fri, May 15, 2015 at 11:11 AM, Thomas Caswell  wrote:

> I would advocate for calling yours something different.  path.Path is
> really a container for a Bezier curve and is probably best left as simple
> as possible.  There is probably an interesting discussion about right is-a
> and has-a relations between Path,  FancyPath (don't use that name!), and
> FancyArrow (which I do not have a clear view of yet).
>
> Tom
>
> On Fri, May 15, 2015 at 11:04 AM Neil Girdhar 
> wrote:
>
>> On Fri, May 15, 2015 at 10:53 AM, Thomas Caswell 
>> wrote:
>>
>>> A few very quick comments (just skimmed the docstrings)
>>>
>>> We already have a mpl.path.Path class, please don't shadow that.
>>>
>>
>> I read the Path class and based mine on that.  The problem is that I want
>> to be able to place nodes along the path (like labels) and so I need to ask
>> it questions.  Maybe we should just extend the existing Path class?  Or
>> else we should call my Path something different?
>>
>>
>>> Is your `Path` going to be an `Artist` that is responsible for drawing
>>> it's self or does in serve a role like the existing `Path` in that it is
>>> used by other artists as part of their `draw`?
>>>
>>> This feels very similar to the `FancyArrow` (with classes being passed
>>> in to control how the arrow is styled), would this make sense as an
>>> extension to that code?  This does seem more general, maybe it makes sense
>>> to start from scratch and implement `FancyArrow` in terms of this code.
>>>
>>
>> Yes!  Didn't know about that.  I think modifying and extending that code
>> might be a good way forward.
>>
>>
>>
>>>
>>> Tom
>>>
>>> On Fri, May 15, 2015 at 10:40 AM Neil Girdhar 
>>> wrote:
>>>
 I have a draft proposal of the long term goal for what an interface
 could look like for drawing arrows between coordinates or nodes.  I based
 the design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf),
 so it might help to flip through that to get an idea for the basis of this
 design.  I tried to separate the creating of Path objects with the drawing
 of paths since it's often really useful when compositing layouts to be able
 to do math with with the positions of things before drawing anything.  For
 example, when automatically positioning nodes.

 I'm not committed to this design; it's just an outline to get feedback.

 Best,

 Neil

 class Axes_(_AxesBase):
 def path(self, path, draw=True, fill=False):
 """
 If draw is not falsy, draws along the path using the draw
 specification.
 If fill is not falsy, fills the closed path using the fill
 specification.

 Parameters
 --
 path is a Path object or path commands with which to create one.

 draw is a draw specification:
 either the value True, which indicates some defaults, or
 else
 False, or else a dictionary with the following keys:
 color
 opacity
 line_width
 line_join
 begin_tip is a Tip object
 tip or end_tip is a Tip object
 dashed is a dash specification

 a dash specification
 either dictionary containing:
 dash_pattern
 an iterable of numbers specifying the length of the
 dashes
 and gaps in points.  E.g., [2, 3, 4, 3] means on
 for 2
 points, off for 3, on for 4, off for 3, i.e.,
 dash-dotted.
 dash_phase
 Shifts the start of the dash pattern by dash_phase
 points.
 or a string, one of:
 'solid'
 'dotted', 'densely dotted', 'loosely dotted'
 'dashed', 'densely dashed', 'loosely dashed'
 'dash dot', 'densely dash dot', 'loosely dash dot'
 'dash dot dot', 'densely dash dot dot', 'loosely dash
 dot dot'

 fill is a fill specification:
 TODO
 """

 class Path:
 def __init__(self, path_commands):
 """
 path_commands is either
 a coordinate (representing a move to in the first position,
 or a
 line to in any other position)
 MoveTo(coordinate)
 LineTo(coordinate_or_node, draw=None)
 CurveTo(coordinate_or_node, control_points, draw=None)
 ClosePolygon()

 optional draw commands override the draw specification of
 the whole
 path within that edge.

 a coordinate is ei

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Thomas Caswell]

I would advocate for calling yours something different.  path.Path is
really a container for a Bezier curve and is probably best left as simple
as possible.  There is probably an interesting discussion about right is-a
and has-a relations between Path,  FancyPath (don't use that name!), and
FancyArrow (which I do not have a clear view of yet).

Tom

On Fri, May 15, 2015 at 11:04 AM Neil Girdhar  wrote:

> On Fri, May 15, 2015 at 10:53 AM, Thomas Caswell 
> wrote:
>
>> A few very quick comments (just skimmed the docstrings)
>>
>> We already have a mpl.path.Path class, please don't shadow that.
>>
>
> I read the Path class and based mine on that.  The problem is that I want
> to be able to place nodes along the path (like labels) and so I need to ask
> it questions.  Maybe we should just extend the existing Path class?  Or
> else we should call my Path something different?
>
>
>> Is your `Path` going to be an `Artist` that is responsible for drawing
>> it's self or does in serve a role like the existing `Path` in that it is
>> used by other artists as part of their `draw`?
>>
>> This feels very similar to the `FancyArrow` (with classes being passed in
>> to control how the arrow is styled), would this make sense as an extension
>> to that code?  This does seem more general, maybe it makes sense to start
>> from scratch and implement `FancyArrow` in terms of this code.
>>
>
> Yes!  Didn't know about that.  I think modifying and extending that code
> might be a good way forward.
>
>
>
>>
>> Tom
>>
>> On Fri, May 15, 2015 at 10:40 AM Neil Girdhar 
>> wrote:
>>
>>> I have a draft proposal of the long term goal for what an interface
>>> could look like for drawing arrows between coordinates or nodes.  I based
>>> the design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf),
>>> so it might help to flip through that to get an idea for the basis of this
>>> design.  I tried to separate the creating of Path objects with the drawing
>>> of paths since it's often really useful when compositing layouts to be able
>>> to do math with with the positions of things before drawing anything.  For
>>> example, when automatically positioning nodes.
>>>
>>> I'm not committed to this design; it's just an outline to get feedback.
>>>
>>> Best,
>>>
>>> Neil
>>>
>>> class Axes_(_AxesBase):
>>> def path(self, path, draw=True, fill=False):
>>> """
>>> If draw is not falsy, draws along the path using the draw
>>> specification.
>>> If fill is not falsy, fills the closed path using the fill
>>> specification.
>>>
>>> Parameters
>>> --
>>> path is a Path object or path commands with which to create one.
>>>
>>> draw is a draw specification:
>>> either the value True, which indicates some defaults, or else
>>> False, or else a dictionary with the following keys:
>>> color
>>> opacity
>>> line_width
>>> line_join
>>> begin_tip is a Tip object
>>> tip or end_tip is a Tip object
>>> dashed is a dash specification
>>>
>>> a dash specification
>>> either dictionary containing:
>>> dash_pattern
>>> an iterable of numbers specifying the length of the
>>> dashes
>>> and gaps in points.  E.g., [2, 3, 4, 3] means on for
>>> 2
>>> points, off for 3, on for 4, off for 3, i.e.,
>>> dash-dotted.
>>> dash_phase
>>> Shifts the start of the dash pattern by dash_phase
>>> points.
>>> or a string, one of:
>>> 'solid'
>>> 'dotted', 'densely dotted', 'loosely dotted'
>>> 'dashed', 'densely dashed', 'loosely dashed'
>>> 'dash dot', 'densely dash dot', 'loosely dash dot'
>>> 'dash dot dot', 'densely dash dot dot', 'loosely dash
>>> dot dot'
>>>
>>> fill is a fill specification:
>>> TODO
>>> """
>>>
>>> class Path:
>>> def __init__(self, path_commands):
>>> """
>>> path_commands is either
>>> a coordinate (representing a move to in the first position,
>>> or a
>>> line to in any other position)
>>> MoveTo(coordinate)
>>> LineTo(coordinate_or_node, draw=None)
>>> CurveTo(coordinate_or_node, control_points, draw=None)
>>> ClosePolygon()
>>>
>>> optional draw commands override the draw specification of
>>> the whole
>>> path within that edge.
>>>
>>> a coordinate is either an (x, y) pair, or a Coordinate
>>> object.
>>> a node is a Node object.
>>> """
>>>
>>> def at_position(self, fraction=0.5):
>>> """
>>> Returns a coordinate fraction of the way along the line.
>>> fraction can be one of 'at end', 'very near end', '

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

On Fri, May 15, 2015 at 10:53 AM, Thomas Caswell  wrote:

> A few very quick comments (just skimmed the docstrings)
>
> We already have a mpl.path.Path class, please don't shadow that.
>

I read the Path class and based mine on that.  The problem is that I want
to be able to place nodes along the path (like labels) and so I need to ask
it questions.  Maybe we should just extend the existing Path class?  Or
else we should call my Path something different?


> Is your `Path` going to be an `Artist` that is responsible for drawing
> it's self or does in serve a role like the existing `Path` in that it is
> used by other artists as part of their `draw`?
>
> This feels very similar to the `FancyArrow` (with classes being passed in
> to control how the arrow is styled), would this make sense as an extension
> to that code?  This does seem more general, maybe it makes sense to start
> from scratch and implement `FancyArrow` in terms of this code.
>

Yes!  Didn't know about that.  I think modifying and extending that code
might be a good way forward.



>
> Tom
>
> On Fri, May 15, 2015 at 10:40 AM Neil Girdhar 
> wrote:
>
>> I have a draft proposal of the long term goal for what an interface could
>> look like for drawing arrows between coordinates or nodes.  I based the
>> design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf), so
>> it might help to flip through that to get an idea for the basis of this
>> design.  I tried to separate the creating of Path objects with the drawing
>> of paths since it's often really useful when compositing layouts to be able
>> to do math with with the positions of things before drawing anything.  For
>> example, when automatically positioning nodes.
>>
>> I'm not committed to this design; it's just an outline to get feedback.
>>
>> Best,
>>
>> Neil
>>
>> class Axes_(_AxesBase):
>> def path(self, path, draw=True, fill=False):
>> """
>> If draw is not falsy, draws along the path using the draw
>> specification.
>> If fill is not falsy, fills the closed path using the fill
>> specification.
>>
>> Parameters
>> --
>> path is a Path object or path commands with which to create one.
>>
>> draw is a draw specification:
>> either the value True, which indicates some defaults, or else
>> False, or else a dictionary with the following keys:
>> color
>> opacity
>> line_width
>> line_join
>> begin_tip is a Tip object
>> tip or end_tip is a Tip object
>> dashed is a dash specification
>>
>> a dash specification
>> either dictionary containing:
>> dash_pattern
>> an iterable of numbers specifying the length of the
>> dashes
>> and gaps in points.  E.g., [2, 3, 4, 3] means on for 2
>> points, off for 3, on for 4, off for 3, i.e.,
>> dash-dotted.
>> dash_phase
>> Shifts the start of the dash pattern by dash_phase
>> points.
>> or a string, one of:
>> 'solid'
>> 'dotted', 'densely dotted', 'loosely dotted'
>> 'dashed', 'densely dashed', 'loosely dashed'
>> 'dash dot', 'densely dash dot', 'loosely dash dot'
>> 'dash dot dot', 'densely dash dot dot', 'loosely dash dot
>> dot'
>>
>> fill is a fill specification:
>> TODO
>> """
>>
>> class Path:
>> def __init__(self, path_commands):
>> """
>> path_commands is either
>> a coordinate (representing a move to in the first position,
>> or a
>> line to in any other position)
>> MoveTo(coordinate)
>> LineTo(coordinate_or_node, draw=None)
>> CurveTo(coordinate_or_node, control_points, draw=None)
>> ClosePolygon()
>>
>> optional draw commands override the draw specification of the
>> whole
>> path within that edge.
>>
>> a coordinate is either an (x, y) pair, or a Coordinate object.
>> a node is a Node object.
>> """
>>
>> def at_position(self, fraction=0.5):
>> """
>> Returns a coordinate fraction of the way along the line.
>> fraction can be one of 'at end', 'very near end', 'near end',
>> 'midway', 'near start', 'very near start', 'at start'
>> """
>>
>> def node_at(node, fraction=0.5, location, ...)
>> """
>> Sets the node's position so that it sits flush to the path.
>>
>> Parameters
>> --
>> location :
>> Could be 'above', 'below', 'on', or a number, which is the
>> number
>> of points away from the path to place the node.
>> """
>>
>> def pin_node(node, pin_distance, draw=draw_specification):
>>   

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Thomas Caswell]

A few very quick comments (just skimmed the docstrings)

We already have a mpl.path.Path class, please don't shadow that.

Is your `Path` going to be an `Artist` that is responsible for drawing it's
self or does in serve a role like the existing `Path` in that it is used by
other artists as part of their `draw`?

This feels very similar to the `FancyArrow` (with classes being passed in
to control how the arrow is styled), would this make sense as an extension
to that code?  This does seem more general, maybe it makes sense to start
from scratch and implement `FancyArrow` in terms of this code.

Tom

On Fri, May 15, 2015 at 10:40 AM Neil Girdhar  wrote:

> I have a draft proposal of the long term goal for what an interface could
> look like for drawing arrows between coordinates or nodes.  I based the
> design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf), so it
> might help to flip through that to get an idea for the basis of this
> design.  I tried to separate the creating of Path objects with the drawing
> of paths since it's often really useful when compositing layouts to be able
> to do math with with the positions of things before drawing anything.  For
> example, when automatically positioning nodes.
>
> I'm not committed to this design; it's just an outline to get feedback.
>
> Best,
>
> Neil
>
> class Axes_(_AxesBase):
> def path(self, path, draw=True, fill=False):
> """
> If draw is not falsy, draws along the path using the draw
> specification.
> If fill is not falsy, fills the closed path using the fill
> specification.
>
> Parameters
> --
> path is a Path object or path commands with which to create one.
>
> draw is a draw specification:
> either the value True, which indicates some defaults, or else
> False, or else a dictionary with the following keys:
> color
> opacity
> line_width
> line_join
> begin_tip is a Tip object
> tip or end_tip is a Tip object
> dashed is a dash specification
>
> a dash specification
> either dictionary containing:
> dash_pattern
> an iterable of numbers specifying the length of the
> dashes
> and gaps in points.  E.g., [2, 3, 4, 3] means on for 2
> points, off for 3, on for 4, off for 3, i.e.,
> dash-dotted.
> dash_phase
> Shifts the start of the dash pattern by dash_phase
> points.
> or a string, one of:
> 'solid'
> 'dotted', 'densely dotted', 'loosely dotted'
> 'dashed', 'densely dashed', 'loosely dashed'
> 'dash dot', 'densely dash dot', 'loosely dash dot'
> 'dash dot dot', 'densely dash dot dot', 'loosely dash dot
> dot'
>
> fill is a fill specification:
> TODO
> """
>
> class Path:
> def __init__(self, path_commands):
> """
> path_commands is either
> a coordinate (representing a move to in the first position, or
> a
> line to in any other position)
> MoveTo(coordinate)
> LineTo(coordinate_or_node, draw=None)
> CurveTo(coordinate_or_node, control_points, draw=None)
> ClosePolygon()
>
> optional draw commands override the draw specification of the
> whole
> path within that edge.
>
> a coordinate is either an (x, y) pair, or a Coordinate object.
> a node is a Node object.
> """
>
> def at_position(self, fraction=0.5):
> """
> Returns a coordinate fraction of the way along the line.
> fraction can be one of 'at end', 'very near end', 'near end',
> 'midway', 'near start', 'very near start', 'at start'
> """
>
> def node_at(node, fraction=0.5, location, ...)
> """
> Sets the node's position so that it sits flush to the path.
>
> Parameters
> --
> location :
> Could be 'above', 'below', 'on', or a number, which is the
> number
> of points away from the path to place the node.
> """
>
> def pin_node(node, pin_distance, draw=draw_specification):
> pass
>
>
> class Coordinate:
> @property
> def coordinate(self):
> return (self.x, self.y)
>
> def node_at(self, node, angle):
> """
> Places the node so that it is in the direction angle from the
> coordinate.  E.g.,
> angle=pi/2, or angle='above' places the node so that the
> coordinate is
> touching the center-bottom of the node.
> angle could be 'above', 'below', 'left', 'right', 'above left',
> etc.
> """
>
> class Node:
> """
> Available Node objects:
> Rectangle, Cir

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

I have a draft proposal of the long term goal for what an interface could
look like for drawing arrows between coordinates or nodes.  I based the
design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf), so it
might help to flip through that to get an idea for the basis of this
design.  I tried to separate the creating of Path objects with the drawing
of paths since it's often really useful when compositing layouts to be able
to do math with with the positions of things before drawing anything.  For
example, when automatically positioning nodes.

I'm not committed to this design; it's just an outline to get feedback.

Best,

Neil

class Axes_(_AxesBase):
def path(self, path, draw=True, fill=False):
"""
If draw is not falsy, draws along the path using the draw
specification.
If fill is not falsy, fills the closed path using the fill
specification.

Parameters
--
path is a Path object or path commands with which to create one.

draw is a draw specification:
either the value True, which indicates some defaults, or else
False, or else a dictionary with the following keys:
color
opacity
line_width
line_join
begin_tip is a Tip object
tip or end_tip is a Tip object
dashed is a dash specification

a dash specification
either dictionary containing:
dash_pattern
an iterable of numbers specifying the length of the
dashes
and gaps in points.  E.g., [2, 3, 4, 3] means on for 2
points, off for 3, on for 4, off for 3, i.e.,
dash-dotted.
dash_phase
Shifts the start of the dash pattern by dash_phase
points.
or a string, one of:
'solid'
'dotted', 'densely dotted', 'loosely dotted'
'dashed', 'densely dashed', 'loosely dashed'
'dash dot', 'densely dash dot', 'loosely dash dot'
'dash dot dot', 'densely dash dot dot', 'loosely dash dot
dot'

fill is a fill specification:
TODO
"""

class Path:
def __init__(self, path_commands):
"""
path_commands is either
a coordinate (representing a move to in the first position, or a
line to in any other position)
MoveTo(coordinate)
LineTo(coordinate_or_node, draw=None)
CurveTo(coordinate_or_node, control_points, draw=None)
ClosePolygon()

optional draw commands override the draw specification of the
whole
path within that edge.

a coordinate is either an (x, y) pair, or a Coordinate object.
a node is a Node object.
"""

def at_position(self, fraction=0.5):
"""
Returns a coordinate fraction of the way along the line.
fraction can be one of 'at end', 'very near end', 'near end',
'midway', 'near start', 'very near start', 'at start'
"""

def node_at(node, fraction=0.5, location, ...)
"""
Sets the node's position so that it sits flush to the path.

Parameters
--
location :
Could be 'above', 'below', 'on', or a number, which is the
number
of points away from the path to place the node.
"""

def pin_node(node, pin_distance, draw=draw_specification):
pass


class Coordinate:
@property
def coordinate(self):
return (self.x, self.y)

def node_at(self, node, angle):
"""
Places the node so that it is in the direction angle from the
coordinate.  E.g.,
angle=pi/2, or angle='above' places the node so that the coordinate
is
touching the center-bottom of the node.
angle could be 'above', 'below', 'left', 'right', 'above left', etc.
"""

class Node:
"""
Available Node objects:
Rectangle, Circle
"""
@property
def center(self):
return (self.x, self.y)

def node_at(self, node, angle):
"""
Places the node so that it is in the direction angle from the
coordinate.  The node could be an arrowhead for example.
"""

def convex_hulls(self):
"""
Returns a list of convex hulls.  The convex hulls are used when
position one node or arrowhead flush with another using the
separating axis algorithm.
"""

class Tip:
"""
Available Tip objects:
ButtCap (no tip, the default)
RectangleCap, TriangleCap, RoundCap
ArcBarb, Bar, Bracket, Hooks, Parenthesis,
StraightBarb, TeeBarb
Circle, Diamond, Ellipse, Kite, Arrow,
Rectangle, Square, Stealth, Triangle,
TurnedSquare
TipCombination (accepts multiple tips and merges them)

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Thomas Caswell]

Sorry, I may have been being a bit dramatic

In mpl.patches: Arrow, FancyArrow, YAArrow, FancyArrowPatch,
ConnectionPatch  + annotation related artists + some classes in axisartist
which now that I look at them are not really general purpose arrow tools.
I had not been counting quiver (or barbs) or sankey.

Neil: Those are all great questions!  Much of the arrow related code was
written by Joe-Joon Lee who (by having read a good deal of his code) has a
habit of writing very power but very opaque python.

I believe that the line join style is controlled by `joinstyle` on the
graphics context and it is up to the backends to implement that correctly.

Tom

On Wed, May 13, 2015 at 10:58 PM Neil Girdhar  wrote:

> Okay, I'm looking at this in more detail and there may be some design
> concerns:
>
> The arrow placement is decided without asking the arrow any questions,
> such as its bounding box.  Instead, the arrow should return a bounding box
> and then the line should retreat until the bounding box no longer
> intersects the target node.  Then the arrow should be placed.  This doesn't
> matter so much when you have a simple arrow like this: >, but it's a
> big deal when you have an arrow like | .  In this case, the sides of
> the arrow risk intersecting with the target node.
>
> I'm not keen on implementing every arrow three times: <-, ->, <->.  This
> really should be handled by the code placing the arrows for many reasons:
> 1. It should also be possible to have a different arrowhead at either end
> of the line.
> 2. It should be possible to stack the arrows, for example having two heads
> one after another (to represent two kinds of relationships).  This is
> another reason to be able to ask the arrowhead its length and so on.
>
> I don't understand the "monolithic" keyword.  How can the arrow draw the
> line as well when it doesn't know the line style, color and so on?
>
> I think I like the design of the transmute function.  I'm curious:
> ultimately, where does the mutation_size come from?  Is it a global scale
> applied to the figure, or is it based on the linewidth, or?
>
> When you emit a set of lines, how are they joined?  If I draw a line
> having linewidth 0.1 from the origin to (1, 0), and back to (0, 0.5), what
> happens at the tip?  Are two rectangles drawn (each having width 0.1, but
> oriented differently)?  Is a bevel created?  A miter? Or is the tip
> rounded?  Can this be controlled?  See page 166 of the manual I sent
> earlier (search for tikz/line join).
>
> Best,
>
> Neil
>
> On Wed, May 13, 2015 at 10:14 PM, Neil Girdhar 
> wrote:
>
>> Thanks, it works!
>>
>> I needed to add:
>>
>> import matplotlib.patches
>>
>> to one file and
>>
>> plt.show()
>>
>> to the other.
>>
>> Any word on the locations in the code of the seven arrow drawing methods?
>>
>> I've located the arrow drawing code in tikz, and so I can start porting
>> it over.  I'm curious, do we know the linewidth of the edge being decorated
>> by the arrow?  To make arrows scale nicely, most of the arrow dimensions
>> are given in two pieces: an absolute value (in points for example) and a
>> line width factor.  The dimension is the absolute value plus the line width
>> factor times the line width.  The TikZ manual explains: "This makes it easy
>> to vary the size of an arrow tip in accordance with the line width –
>> usually a very good idea since thicker lines will need thicker arrow tips."
>>
>> Best,
>>
>> Neil
>>
>> On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn 
>> wrote:
>>
>>> Neil,
>>>
>>> I have attached code to draw the arrowhead.
>>>
>>> -Ben
>>>
>>>
>>>
>>> On May 13, 2015, at 7:44 PM, Neil Girdhar  wrote:
>>>
>>> Do you have the code that you used to draw the arrowhead?  I'm up to
>>> date now on the development workflow (
>>> http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm
>>> ready to start working.
>>>
>>> Thanks,
>>>
>>> Neil
>>>
>>> On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn 
>>> wrote:
>>>
 Yes, I fully agree that we need to unify the many different ways to
 draw arrows.

 Neil, in case an example would be helpful for you, I have attached a
 module that includes a custom arrowhead class.  The arrowhead class works
 with the with the ax.annotate() method.  (I like the annotate method
 because it allows me to easily mix and match coordinate systems for arrow
 placement.)  As you can see in the attached pdf, the custom arrowhead
 doesn't include fancy Bezier curves, but that could be added.

 -Ben



 On May 13, 2015, at 2:54 PM, Thomas Caswell  wrote:

 The other thing that should be done is to unify the (I think 7?!?)
 unique ways to draw arrows in mpl.

 On Wed, May 13, 2015 at 4:52 PM Neil Girdhar 
 wrote:

> Yes, I just noticed that as well.  That's how the tikz pgf code looks
> (a sequence of line_to and curve_to commands and so on) so it should be
> easy to port o

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Okay, I'm looking at this in more detail and there may be some design
concerns:

The arrow placement is decided without asking the arrow any questions, such
as its bounding box.  Instead, the arrow should return a bounding box and
then the line should retreat until the bounding box no longer intersects
the target node.  Then the arrow should be placed.  This doesn't matter so
much when you have a simple arrow like this: >, but it's a big deal
when you have an arrow like | .  In this case, the sides of the arrow
risk intersecting with the target node.

I'm not keen on implementing every arrow three times: <-, ->, <->.  This
really should be handled by the code placing the arrows for many reasons:
1. It should also be possible to have a different arrowhead at either end
of the line.
2. It should be possible to stack the arrows, for example having two heads
one after another (to represent two kinds of relationships).  This is
another reason to be able to ask the arrowhead its length and so on.

I don't understand the "monolithic" keyword.  How can the arrow draw the
line as well when it doesn't know the line style, color and so on?

I think I like the design of the transmute function.  I'm curious:
ultimately, where does the mutation_size come from?  Is it a global scale
applied to the figure, or is it based on the linewidth, or?

When you emit a set of lines, how are they joined?  If I draw a line having
linewidth 0.1 from the origin to (1, 0), and back to (0, 0.5), what happens
at the tip?  Are two rectangles drawn (each having width 0.1, but oriented
differently)?  Is a bevel created?  A miter? Or is the tip rounded?  Can
this be controlled?  See page 166 of the manual I sent earlier (search for
tikz/line join).

Best,

Neil

On Wed, May 13, 2015 at 10:14 PM, Neil Girdhar 
wrote:

> Thanks, it works!
>
> I needed to add:
>
> import matplotlib.patches
>
> to one file and
>
> plt.show()
>
> to the other.
>
> Any word on the locations in the code of the seven arrow drawing methods?
>
> I've located the arrow drawing code in tikz, and so I can start porting it
> over.  I'm curious, do we know the linewidth of the edge being decorated by
> the arrow?  To make arrows scale nicely, most of the arrow dimensions are
> given in two pieces: an absolute value (in points for example) and a line
> width factor.  The dimension is the absolute value plus the line width
> factor times the line width.  The TikZ manual explains: "This makes it easy
> to vary the size of an arrow tip in accordance with the line width –
> usually a very good idea since thicker lines will need thicker arrow tips."
>
> Best,
>
> Neil
>
> On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn 
> wrote:
>
>> Neil,
>>
>> I have attached code to draw the arrowhead.
>>
>> -Ben
>>
>>
>>
>> On May 13, 2015, at 7:44 PM, Neil Girdhar  wrote:
>>
>> Do you have the code that you used to draw the arrowhead?  I'm up to date
>> now on the development workflow (
>> http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm
>> ready to start working.
>>
>> Thanks,
>>
>> Neil
>>
>> On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn 
>> wrote:
>>
>>> Yes, I fully agree that we need to unify the many different ways to draw
>>> arrows.
>>>
>>> Neil, in case an example would be helpful for you, I have attached a
>>> module that includes a custom arrowhead class.  The arrowhead class works
>>> with the with the ax.annotate() method.  (I like the annotate method
>>> because it allows me to easily mix and match coordinate systems for arrow
>>> placement.)  As you can see in the attached pdf, the custom arrowhead
>>> doesn't include fancy Bezier curves, but that could be added.
>>>
>>> -Ben
>>>
>>>
>>>
>>> On May 13, 2015, at 2:54 PM, Thomas Caswell  wrote:
>>>
>>> The other thing that should be done is to unify the (I think 7?!?)
>>> unique ways to draw arrows in mpl.
>>>
>>> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar 
>>> wrote:
>>>
 Yes, I just noticed that as well.  That's how the tikz pgf code looks
 (a sequence of line_to and curve_to commands and so on) so it should be
 easy to port over the various shapes.

 On Wed, May 13, 2015 at 4:49 PM, Eric Firing 
 wrote:

> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>
>> If you want to make arrowheads look at all decent, they really need to
>> be enclosed in Bezier curves.  See the diagram here:
>>
>
> Mpl paths support Bezier curves.
> http://matplotlib.org/api/path_api.html?highlight=bezier
>
>
>>
>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>>
>> The first two look like garbage.  The last one is the only one that
>> looks good imho.
>>
>
> That depends on the application, and the observer.


 Sure, but I may as well port them all of the tikz arrowheads over since
 most of the work would be figuring out how to do i

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Eric Firing]

On 2015/05/13 4:14 PM, Neil Girdhar wrote:
> Thanks, it works!
>
> I needed to add:
>
> import matplotlib.patches
>
> to one file and
>
> plt.show()
>
> to the other.
>
> Any word on the locations in the code of the seven arrow drawing methods?

I'm not sure how to get to a count of seven.  One of them is in the 
quiver module, but it is very different from the others, and at least 
for now I suggest you ignore it.  Probably everything else is in the 
patches module, and much of it is called in the text module.  Maybe 
Thomas is counting the text module usage. Ah, yes, and then there is the 
sankey module.

See also https://github.com/matplotlib/matplotlib/pull/4178.

Eric

>
> I've located the arrow drawing code in tikz, and so I can start porting
> it over.  I'm curious, do we know the linewidth of the edge being
> decorated by the arrow?  To make arrows scale nicely, most of the arrow
> dimensions are given in two pieces: an absolute value (in points for
> example) and a line width factor.  The dimension is the absolute value
> plus the line width factor times the line width.  The TikZ manual
> explains: "This makes it easy to vary the size of an arrow tip in
> accordance with the line width – usually a very good idea since thicker
> lines will need thicker arrow tips."
>
> Best,
>
> Neil
>
> On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn  > wrote:
>
> Neil,
>
> I have attached code to draw the arrowhead.
>
> -Ben
>
>
>
> On May 13, 2015, at 7:44 PM, Neil Girdhar  > wrote:
>
>> Do you have the code that you used to draw the arrowhead?  I'm up
>> to date now on the development workflow
>> (http://matplotlib.org/devel/gitwash/development_workflow.html),
>> so I'm ready to start working.
>>
>> Thanks,
>>
>> Neil
>>
>> On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn
>> mailto:breed...@gmail.com>> wrote:
>>
>> Yes, I fully agree that we need to unify the many different
>> ways to draw arrows.
>>
>> Neil, in case an example would be helpful for you, I have
>> attached a module that includes a custom arrowhead class.  The
>> arrowhead class works with the with the ax.annotate() method.
>>  (I like the annotate method because it allows me to easily
>> mix and match coordinate systems for arrow placement.)  As you
>> can see in the attached pdf, the custom arrowhead doesn't
>> include fancy Bezier curves, but that could be added.
>>
>> -Ben
>>
>>
>>
>> On May 13, 2015, at 2:54 PM, Thomas Caswell
>> mailto:tcasw...@gmail.com>> wrote:
>>
>>> The other thing that should be done is to unify the (I think
>>> 7?!?) unique ways to draw arrows in mpl.
>>>
>>> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar
>>> mailto:mistersh...@gmail.com>> wrote:
>>>
>>> Yes, I just noticed that as well.  That's how the tikz
>>> pgf code looks (a sequence of line_to and curve_to
>>> commands and so on) so it should be easy to port over the
>>> various shapes.
>>>
>>> On Wed, May 13, 2015 at 4:49 PM, Eric Firing
>>> mailto:efir...@hawaii.edu>> wrote:
>>>
>>> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>>>
>>> If you want to make arrowheads look at all
>>> decent, they really need to
>>> be enclosed in Bezier curves.  See the diagram here:
>>>
>>>
>>> Mpl paths support Bezier curves.
>>> http://matplotlib.org/api/path_api.html?highlight=bezier
>>>
>>>
>>> 
>>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>>>
>>> The first two look like garbage.  The last one is
>>> the only one that
>>> looks good imho.
>>>
>>>
>>> That depends on the application, and the observer.
>>>
>>>
>>> Sure, but I may as well port them all of the tikz
>>> arrowheads over since most of the work would be figuring
>>> out how to do it.
>>>
>>>
>>>
>>> Eric
>>>
>>>
>>> Best,
>>>
>>> Neil
>>>
>>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing
>>> mailto:efir...@hawaii.edu>
>>> >> >> wrote:
>>>
>>> On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>>>
>>> I don't know matplotlib well enough (yet)
>>> to know what the
>>> change would
>>> consist of.
>>>
>>> I suggest you take a look at the
>>> beautiful ti

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Thanks, it works!

I needed to add:

import matplotlib.patches

to one file and

plt.show()

to the other.

Any word on the locations in the code of the seven arrow drawing methods?

I've located the arrow drawing code in tikz, and so I can start porting it
over.  I'm curious, do we know the linewidth of the edge being decorated by
the arrow?  To make arrows scale nicely, most of the arrow dimensions are
given in two pieces: an absolute value (in points for example) and a line
width factor.  The dimension is the absolute value plus the line width
factor times the line width.  The TikZ manual explains: "This makes it easy
to vary the size of an arrow tip in accordance with the line width –
usually a very good idea since thicker lines will need thicker arrow tips."

Best,

Neil

On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn 
wrote:

> Neil,
>
> I have attached code to draw the arrowhead.
>
> -Ben
>
>
>
> On May 13, 2015, at 7:44 PM, Neil Girdhar  wrote:
>
> Do you have the code that you used to draw the arrowhead?  I'm up to date
> now on the development workflow (
> http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm
> ready to start working.
>
> Thanks,
>
> Neil
>
> On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn 
> wrote:
>
>> Yes, I fully agree that we need to unify the many different ways to draw
>> arrows.
>>
>> Neil, in case an example would be helpful for you, I have attached a
>> module that includes a custom arrowhead class.  The arrowhead class works
>> with the with the ax.annotate() method.  (I like the annotate method
>> because it allows me to easily mix and match coordinate systems for arrow
>> placement.)  As you can see in the attached pdf, the custom arrowhead
>> doesn't include fancy Bezier curves, but that could be added.
>>
>> -Ben
>>
>>
>>
>> On May 13, 2015, at 2:54 PM, Thomas Caswell  wrote:
>>
>> The other thing that should be done is to unify the (I think 7?!?) unique
>> ways to draw arrows in mpl.
>>
>> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar 
>> wrote:
>>
>>> Yes, I just noticed that as well.  That's how the tikz pgf code looks (a
>>> sequence of line_to and curve_to commands and so on) so it should be easy
>>> to port over the various shapes.
>>>
>>> On Wed, May 13, 2015 at 4:49 PM, Eric Firing  wrote:
>>>
 On 2015/05/13 10:12 AM, Neil Girdhar wrote:

> If you want to make arrowheads look at all decent, they really need to
> be enclosed in Bezier curves.  See the diagram here:
>

 Mpl paths support Bezier curves.
 http://matplotlib.org/api/path_api.html?highlight=bezier


>
> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>
> The first two look like garbage.  The last one is the only one that
> looks good imho.
>

 That depends on the application, and the observer.
>>>
>>>
>>> Sure, but I may as well port them all of the tikz arrowheads over since
>>> most of the work would be figuring out how to do it.
>>>
>>>


 Eric


> Best,
>
> Neil
>
> On Wed, May 13, 2015 at 4:09 PM, Eric Firing  > wrote:
>
> On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>
> I don't know matplotlib well enough (yet) to know what the
> change would
> consist of.
>
> I suggest you take a look at the beautiful tikz manual:
> http://pgf.sourceforge.net/pgf_CVS.pdf
>
>
> Very helpful, thank you.
>
>
> The arrows.meta on page 201–212 are really well-designed and
> beautiful.
>
> Compare this with matplotlib's custom arrows:
>
> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>
> How do I make tikz's arrowheads available for all backends?
>
>
> My guess offhand is that this is a matter of using the mpl API.  I
> don't think we would want to add all of these types and options to
> the mpl core; but a toolkit might be ideal for this.  The mpl API,
> which generates the same results for all backends, is quite
> complete
> and flexible.  Things like arrowheads are Patch objects, and you
> can
> specify any path you want.  The main trick is figuring out how to
> handle transforms--what kind of coordinates should the path be
> specifying?  How should things scale as a figure is reshaped and
> resized?
>
> For many of these types you could also use mpl Line2D objects, for
> which several properties including cap style can be specified.  Not
> all of the TikZ options would be available, but perhaps enough.
>
> Eric
>
>
>

>>> --
>>> One dashboard for servers

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Benjamin Reedlunn]

Neil,I have attached code to draw the arrowhead.-Ben# -*- coding: utf-8 -*-
"""
Spyder Editor

This is a temporary script file.
"""

import custom_annotations
import matplotlib.pyplot as plt

plt.figure()
ax = plt.subplot(111)
length = 20.0
head_length = 7.0
#Convert the head length from mm into points (1/72")
head_length_pts = head_length * 72.0/25.4
#Calculate the head width
head_aspect_ratio = 2.5
head_width_pts = head_length_pts / head_aspect_ratio
#Define arrow style
style_str = '-)>'
arrowstyle_str = style_str + ', head_width = ' + str(head_width_pts) + \
', head_length = ' + str(head_length_pts) + ', length = ' + str(length * 72/25.4)
#Sets arrow orientation
x_1 = [0.25, 0.5]
#Sets arrowhead tip position
x_2 = [0.5, 0.5]
ax.annotate('', xytext = x_1, textcoords = 'axes fraction', \
xy = x_2, xycoords = 'axes fraction', clip_on = False, \
arrowprops = dict(arrowstyle = arrowstyle_str, mutation_scale = 1.0, \
linewidth = 1, facecolor = [0,0,0], connectionstyle = 'arc3', \
shrinkA = 0, shrinkB = 0))On May 13, 2015, at 7:44 PM, Neil Girdhar  wrote:Do you have the code that you used to draw the arrowhead?  I'm up to date now on the development workflow (http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm ready to start working.Thanks,NeilOn Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn  wrote:Yes, I fully agree that we need to unify the many different ways to draw arrows.  Neil, in case an example would be helpful for you, I have attached a module that includes a custom arrowhead class.  The arrowhead class works with the with the ax.annotate() method.  (I like the annotate method because it allows me to easily mix and match coordinate systems for arrow placement.)  As you can see in the attached pdf, the custom arrowhead doesn't include fancy Bezier curves, but that could be added.-BenOn May 13, 2015, at 2:54 PM, Thomas Caswell  wrote:The other thing that should be done is to unify the (I think 7?!?) unique ways to draw arrows in mpl.On Wed, May 13, 2015 at 4:52 PM Neil Girdhar  wrote:Yes, I just noticed that as well.  That's how the tikz pgf code looks (a sequence of line_to and curve_to commands and so on) so it should be easy to port over the various shapes.On Wed, May 13, 2015 at 4:49 PM, Eric Firing  wrote:On 2015/05/13 10:12 AM, Neil Girdhar wrote:

If you want to make arrowheads look at all decent, they really need to
be enclosed in Bezier curves.  See the diagram here:


Mpl paths support Bezier curves.
http://matplotlib.org/api/path_api.html?highlight=bezier



http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965

The first two look like garbage.  The last one is the only one that
looks good imho.


That depends on the application, and the observer.Sure, but I may as well port them all of the tikz arrowheads over since most of the work would be figuring out how to do it. 

Eric



Best,

Neil

On Wed, May 13, 2015 at 4:09 PM, Eric Firing > wrote:

    On 2015/05/13 9:36 AM, Neil Girdhar wrote:

        I don't know matplotlib well enough (yet) to know what the
        change would
        consist of.

        I suggest you take a look at the beautiful tikz manual:
        http://pgf.sourceforge.net/pgf_CVS.pdf


    Very helpful, thank you.


        The arrows.meta on page 201–212 are really well-designed and
        beautiful.

        Compare this with matplotlib's custom arrows:
        http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate

        How do I make tikz's arrowheads available for all backends?


    My guess offhand is that this is a matter of using the mpl API.  I
    don't think we would want to add all of these types and options to
    the mpl core; but a toolkit might be ideal for this.  The mpl API,
    which generates the same results for all backends, is quite complete
    and flexible.  Things like arrowheads are Patch objects, and you can
    specify any path you want.  The main trick is figuring out how to
    handle transforms--what kind of coordinates should the path be
    specifying?  How should things scale as a figure is reshaped and
    resized?

    For many of these types you could also use mpl Line2D objects, for
    which several properties including cap style can be specified.  Not
    all of the TikZ options would be available, but perhaps enough.

    Eric





--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Do you have the code that you used to draw the arrowhead?  I'm up to date
now on the development workflow (
http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm
ready to start working.

Thanks,

Neil

On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn 
wrote:

> Yes, I fully agree that we need to unify the many different ways to draw
> arrows.
>
> Neil, in case an example would be helpful for you, I have attached a
> module that includes a custom arrowhead class.  The arrowhead class works
> with the with the ax.annotate() method.  (I like the annotate method
> because it allows me to easily mix and match coordinate systems for arrow
> placement.)  As you can see in the attached pdf, the custom arrowhead
> doesn't include fancy Bezier curves, but that could be added.
>
> -Ben
>
>
>
> On May 13, 2015, at 2:54 PM, Thomas Caswell  wrote:
>
> The other thing that should be done is to unify the (I think 7?!?) unique
> ways to draw arrows in mpl.
>
> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar 
> wrote:
>
>> Yes, I just noticed that as well.  That's how the tikz pgf code looks (a
>> sequence of line_to and curve_to commands and so on) so it should be easy
>> to port over the various shapes.
>>
>> On Wed, May 13, 2015 at 4:49 PM, Eric Firing  wrote:
>>
>>> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>>>
 If you want to make arrowheads look at all decent, they really need to
 be enclosed in Bezier curves.  See the diagram here:

>>>
>>> Mpl paths support Bezier curves.
>>> http://matplotlib.org/api/path_api.html?highlight=bezier
>>>
>>>

 http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965

 The first two look like garbage.  The last one is the only one that
 looks good imho.

>>>
>>> That depends on the application, and the observer.
>>
>>
>> Sure, but I may as well port them all of the tikz arrowheads over since
>> most of the work would be figuring out how to do it.
>>
>>
>>>
>>>
>>> Eric
>>>
>>>
 Best,

 Neil

 On Wed, May 13, 2015 at 4:09 PM, Eric Firing >>> > wrote:

 On 2015/05/13 9:36 AM, Neil Girdhar wrote:

 I don't know matplotlib well enough (yet) to know what the
 change would
 consist of.

 I suggest you take a look at the beautiful tikz manual:
 http://pgf.sourceforge.net/pgf_CVS.pdf


 Very helpful, thank you.


 The arrows.meta on page 201–212 are really well-designed and
 beautiful.

 Compare this with matplotlib's custom arrows:

 http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate

 How do I make tikz's arrowheads available for all backends?


 My guess offhand is that this is a matter of using the mpl API.  I
 don't think we would want to add all of these types and options to
 the mpl core; but a toolkit might be ideal for this.  The mpl API,
 which generates the same results for all backends, is quite complete
 and flexible.  Things like arrowheads are Patch objects, and you can
 specify any path you want.  The main trick is figuring out how to
 handle transforms--what kind of coordinates should the path be
 specifying?  How should things scale as a figure is reshaped and
 resized?

 For many of these types you could also use mpl Line2D objects, for
 which several properties including cap style can be specified.  Not
 all of the TikZ options would be available, but perhaps enough.

 Eric



>>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
>
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Wow, this looks great.

Thank you all of you so far for the quick responses and pointers.

I've already done many diagrams in Python-generated TikZ, which I want to
port over to pure Python.  They are basically variants of this:
http://www.texample.net/tikz/examples/graph/ .  Do you think this will be
possible?  That is, drawing nodes with labels inside and then anchoring the
arrows to the edges of the nodes?

With respect to the unification of arrow types, would you be able to point
me to which files or methods in the source they are based on?  I would like
to familiarize myself with all of them before I make a proposal of what I
intend to do.

Thanks,

Neil

On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn 
wrote:

> Yes, I fully agree that we need to unify the many different ways to draw
> arrows.
>
> Neil, in case an example would be helpful for you, I have attached a
> module that includes a custom arrowhead class.  The arrowhead class works
> with the with the ax.annotate() method.  (I like the annotate method
> because it allows me to easily mix and match coordinate systems for arrow
> placement.)  As you can see in the attached pdf, the custom arrowhead
> doesn't include fancy Bezier curves, but that could be added.
>
> -Ben
>
>
>
> On May 13, 2015, at 2:54 PM, Thomas Caswell  wrote:
>
> The other thing that should be done is to unify the (I think 7?!?) unique
> ways to draw arrows in mpl.
>
> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar 
> wrote:
>
>> Yes, I just noticed that as well.  That's how the tikz pgf code looks (a
>> sequence of line_to and curve_to commands and so on) so it should be easy
>> to port over the various shapes.
>>
>> On Wed, May 13, 2015 at 4:49 PM, Eric Firing  wrote:
>>
>>> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>>>
 If you want to make arrowheads look at all decent, they really need to
 be enclosed in Bezier curves.  See the diagram here:

>>>
>>> Mpl paths support Bezier curves.
>>> http://matplotlib.org/api/path_api.html?highlight=bezier
>>>
>>>

 http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965

 The first two look like garbage.  The last one is the only one that
 looks good imho.

>>>
>>> That depends on the application, and the observer.
>>
>>
>> Sure, but I may as well port them all of the tikz arrowheads over since
>> most of the work would be figuring out how to do it.
>>
>>
>>>
>>>
>>> Eric
>>>
>>>
 Best,

 Neil

 On Wed, May 13, 2015 at 4:09 PM, Eric Firing >>> > wrote:

 On 2015/05/13 9:36 AM, Neil Girdhar wrote:

 I don't know matplotlib well enough (yet) to know what the
 change would
 consist of.

 I suggest you take a look at the beautiful tikz manual:
 http://pgf.sourceforge.net/pgf_CVS.pdf


 Very helpful, thank you.


 The arrows.meta on page 201–212 are really well-designed and
 beautiful.

 Compare this with matplotlib's custom arrows:

 http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate

 How do I make tikz's arrowheads available for all backends?


 My guess offhand is that this is a matter of using the mpl API.  I
 don't think we would want to add all of these types and options to
 the mpl core; but a toolkit might be ideal for this.  The mpl API,
 which generates the same results for all backends, is quite complete
 and flexible.  Things like arrowheads are Patch objects, and you can
 specify any path you want.  The main trick is figuring out how to
 handle transforms--what kind of coordinates should the path be
 specifying?  How should things scale as a figure is reshaped and
 resized?

 For many of these types you could also use mpl Line2D objects, for
 which several properties including cap style can be specified.  Not
 all of the TikZ options would be available, but perhaps enough.

 Eric



>>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> One dashboard for servers and applications across Physical-Virtual-C

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Thomas Caswell]

The other thing that should be done is to unify the (I think 7?!?) unique
ways to draw arrows in mpl.

On Wed, May 13, 2015 at 4:52 PM Neil Girdhar  wrote:

> Yes, I just noticed that as well.  That's how the tikz pgf code looks (a
> sequence of line_to and curve_to commands and so on) so it should be easy
> to port over the various shapes.
>
> On Wed, May 13, 2015 at 4:49 PM, Eric Firing  wrote:
>
>> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>>
>>> If you want to make arrowheads look at all decent, they really need to
>>> be enclosed in Bezier curves.  See the diagram here:
>>>
>>
>> Mpl paths support Bezier curves.
>> http://matplotlib.org/api/path_api.html?highlight=bezier
>>
>>
>>>
>>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>>>
>>> The first two look like garbage.  The last one is the only one that
>>> looks good imho.
>>>
>>
>> That depends on the application, and the observer.
>
>
> Sure, but I may as well port them all of the tikz arrowheads over since
> most of the work would be figuring out how to do it.
>
>
>>
>>
>> Eric
>>
>>
>>> Best,
>>>
>>> Neil
>>>
>>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing >> > wrote:
>>>
>>> On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>>>
>>> I don't know matplotlib well enough (yet) to know what the
>>> change would
>>> consist of.
>>>
>>> I suggest you take a look at the beautiful tikz manual:
>>> http://pgf.sourceforge.net/pgf_CVS.pdf
>>>
>>>
>>> Very helpful, thank you.
>>>
>>>
>>> The arrows.meta on page 201–212 are really well-designed and
>>> beautiful.
>>>
>>> Compare this with matplotlib's custom arrows:
>>>
>>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>>>
>>> How do I make tikz's arrowheads available for all backends?
>>>
>>>
>>> My guess offhand is that this is a matter of using the mpl API.  I
>>> don't think we would want to add all of these types and options to
>>> the mpl core; but a toolkit might be ideal for this.  The mpl API,
>>> which generates the same results for all backends, is quite complete
>>> and flexible.  Things like arrowheads are Patch objects, and you can
>>> specify any path you want.  The main trick is figuring out how to
>>> handle transforms--what kind of coordinates should the path be
>>> specifying?  How should things scale as a figure is reshaped and
>>> resized?
>>>
>>> For many of these types you could also use mpl Line2D objects, for
>>> which several properties including cap style can be specified.  Not
>>> all of the TikZ options would be available, but perhaps enough.
>>>
>>> Eric
>>>
>>>
>>>
>>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

Yes, I just noticed that as well.  That's how the tikz pgf code looks (a
sequence of line_to and curve_to commands and so on) so it should be easy
to port over the various shapes.

On Wed, May 13, 2015 at 4:49 PM, Eric Firing  wrote:

> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>
>> If you want to make arrowheads look at all decent, they really need to
>> be enclosed in Bezier curves.  See the diagram here:
>>
>
> Mpl paths support Bezier curves.
> http://matplotlib.org/api/path_api.html?highlight=bezier
>
>
>>
>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>>
>> The first two look like garbage.  The last one is the only one that
>> looks good imho.
>>
>
> That depends on the application, and the observer.


Sure, but I may as well port them all of the tikz arrowheads over since
most of the work would be figuring out how to do it.


>
>
> Eric
>
>
>> Best,
>>
>> Neil
>>
>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing > > wrote:
>>
>> On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>>
>> I don't know matplotlib well enough (yet) to know what the
>> change would
>> consist of.
>>
>> I suggest you take a look at the beautiful tikz manual:
>> http://pgf.sourceforge.net/pgf_CVS.pdf
>>
>>
>> Very helpful, thank you.
>>
>>
>> The arrows.meta on page 201–212 are really well-designed and
>> beautiful.
>>
>> Compare this with matplotlib's custom arrows:
>>
>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>>
>> How do I make tikz's arrowheads available for all backends?
>>
>>
>> My guess offhand is that this is a matter of using the mpl API.  I
>> don't think we would want to add all of these types and options to
>> the mpl core; but a toolkit might be ideal for this.  The mpl API,
>> which generates the same results for all backends, is quite complete
>> and flexible.  Things like arrowheads are Patch objects, and you can
>> specify any path you want.  The main trick is figuring out how to
>> handle transforms--what kind of coordinates should the path be
>> specifying?  How should things scale as a figure is reshaped and
>> resized?
>>
>> For many of these types you could also use mpl Line2D objects, for
>> which several properties including cap style can be specified.  Not
>> all of the TikZ options would be available, but perhaps enough.
>>
>> Eric
>>
>>
>>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Eric Firing]

On 2015/05/13 10:12 AM, Neil Girdhar wrote:
> If you want to make arrowheads look at all decent, they really need to
> be enclosed in Bezier curves.  See the diagram here:

Mpl paths support Bezier curves.
http://matplotlib.org/api/path_api.html?highlight=bezier

>
> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>
> The first two look like garbage.  The last one is the only one that
> looks good imho.

That depends on the application, and the observer.

Eric

>
> Best,
>
> Neil
>
> On Wed, May 13, 2015 at 4:09 PM, Eric Firing  > wrote:
>
> On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>
> I don't know matplotlib well enough (yet) to know what the
> change would
> consist of.
>
> I suggest you take a look at the beautiful tikz manual:
> http://pgf.sourceforge.net/pgf_CVS.pdf
>
>
> Very helpful, thank you.
>
>
> The arrows.meta on page 201–212 are really well-designed and
> beautiful.
>
> Compare this with matplotlib's custom arrows:
> 
> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>
> How do I make tikz's arrowheads available for all backends?
>
>
> My guess offhand is that this is a matter of using the mpl API.  I
> don't think we would want to add all of these types and options to
> the mpl core; but a toolkit might be ideal for this.  The mpl API,
> which generates the same results for all backends, is quite complete
> and flexible.  Things like arrowheads are Patch objects, and you can
> specify any path you want.  The main trick is figuring out how to
> handle transforms--what kind of coordinates should the path be
> specifying?  How should things scale as a figure is reshaped and
> resized?
>
> For many of these types you could also use mpl Line2D objects, for
> which several properties including cap style can be specified.  Not
> all of the TikZ options would be available, but perhaps enough.
>
> Eric
>
>


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

If you want to make arrowheads look at all decent, they really need to be
enclosed in Bezier curves.  See the diagram here:

http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965

The first two look like garbage.  The last one is the only one that looks
good imho.

Best,

Neil

On Wed, May 13, 2015 at 4:09 PM, Eric Firing  wrote:

> On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>
>> I don't know matplotlib well enough (yet) to know what the change would
>> consist of.
>>
>> I suggest you take a look at the beautiful tikz manual:
>> http://pgf.sourceforge.net/pgf_CVS.pdf
>>
>
> Very helpful, thank you.
>
>
>> The arrows.meta on page 201–212 are really well-designed and beautiful.
>>
>> Compare this with matplotlib's custom arrows:
>>
>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>>
>> How do I make tikz's arrowheads available for all backends?
>>
>>
> My guess offhand is that this is a matter of using the mpl API.  I don't
> think we would want to add all of these types and options to the mpl core;
> but a toolkit might be ideal for this.  The mpl API, which generates the
> same results for all backends, is quite complete and flexible.  Things like
> arrowheads are Patch objects, and you can specify any path you want.  The
> main trick is figuring out how to handle transforms--what kind of
> coordinates should the path be specifying?  How should things scale as a
> figure is reshaped and resized?
>
> For many of these types you could also use mpl Line2D objects, for which
> several properties including cap style can be specified.  Not all of the
> TikZ options would be available, but perhaps enough.
>
> Eric
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Eric Firing]

On 2015/05/13 9:36 AM, Neil Girdhar wrote:
> I don't know matplotlib well enough (yet) to know what the change would
> consist of.
>
> I suggest you take a look at the beautiful tikz manual:
> http://pgf.sourceforge.net/pgf_CVS.pdf

Very helpful, thank you.

>
> The arrows.meta on page 201–212 are really well-designed and beautiful.
>
> Compare this with matplotlib's custom arrows:
> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>
> How do I make tikz's arrowheads available for all backends?
>

My guess offhand is that this is a matter of using the mpl API.  I don't 
think we would want to add all of these types and options to the mpl 
core; but a toolkit might be ideal for this.  The mpl API, which 
generates the same results for all backends, is quite complete and 
flexible.  Things like arrowheads are Patch objects, and you can specify 
any path you want.  The main trick is figuring out how to handle 
transforms--what kind of coordinates should the path be specifying?  How 
should things scale as a figure is reshaped and resized?

For many of these types you could also use mpl Line2D objects, for which 
several properties including cap style can be specified.  Not all of the 
TikZ options would be available, but perhaps enough.

Eric


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Benjamin Root]

Just to point out, matplotlib does have a fairly new PGF backend. Perhaps
you might want to look at that and see where the TikZ library might fit in
with that?

Cheers!
Ben Root

On Wed, May 13, 2015 at 3:36 PM, Neil Girdhar  wrote:

> I don't know matplotlib well enough (yet) to know what the change would
> consist of.
>
> I suggest you take a look at the beautiful tikz manual:
> http://pgf.sourceforge.net/pgf_CVS.pdf
>
> The arrows.meta on page 201–212 are really well-designed and beautiful.
>
> Compare this with matplotlib's custom arrows:
> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>
> How do I make tikz's arrowheads available for all backends?
>
>
>
> On Wed, May 13, 2015 at 2:55 PM, Eric Firing  wrote:
>
>> On 2015/05/13 12:39 AM, Neil Girdhar wrote:
>> > TikZ is an extremely well-designed library for generating professional
>> > figures within the cumbersome TeX framework.  Currently, my work flow is
>> > to generate TikZ code using Python.  The TikZ is compiled into PDFs,
>> > which are then included in my LaTeX files.  I would like to work
>> > entirely in Python.
>> >
>> > This means that I want to incorporate TikZ's features into matplotlib.
>> > I want to start with custom pgf arrowheads.  Will this be possible.
>> > What is the process from feature idea to pull request that I would have
>> > to go through?
>>
>> You're on the right track by raising the idea here.  Depending on how
>> complicated the idea is, the next step after some mailing list
>> discussion could be either a MEP or a PR; but personally I would prefer
>> to get a better picture of what you are talking about via this mailing
>> list first.
>>
>> Are you talking about adding high-level functionality that would be
>> applicable to all backends?  Can you give an example of what sorts of
>> changes would be required in mpl, and what they would accomplish?
>>
>> Eric
>>
>> >
>> > Best,
>> >
>> > Neil
>>
>>
>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Neil Girdhar]

I don't know matplotlib well enough (yet) to know what the change would
consist of.

I suggest you take a look at the beautiful tikz manual:
http://pgf.sourceforge.net/pgf_CVS.pdf

The arrows.meta on page 201–212 are really well-designed and beautiful.

Compare this with matplotlib's custom arrows:
http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate

How do I make tikz's arrowheads available for all backends?



On Wed, May 13, 2015 at 2:55 PM, Eric Firing  wrote:

> On 2015/05/13 12:39 AM, Neil Girdhar wrote:
> > TikZ is an extremely well-designed library for generating professional
> > figures within the cumbersome TeX framework.  Currently, my work flow is
> > to generate TikZ code using Python.  The TikZ is compiled into PDFs,
> > which are then included in my LaTeX files.  I would like to work
> > entirely in Python.
> >
> > This means that I want to incorporate TikZ's features into matplotlib.
> > I want to start with custom pgf arrowheads.  Will this be possible.
> > What is the process from feature idea to pull request that I would have
> > to go through?
>
> You're on the right track by raising the idea here.  Depending on how
> complicated the idea is, the next step after some mailing list
> discussion could be either a MEP or a PR; but personally I would prefer
> to get a better picture of what you are talking about via this mailing
> list first.
>
> Are you talking about adding high-level functionality that would be
> applicable to all backends?  Can you give an example of what sorts of
> changes would be required in mpl, and what they would accomplish?
>
> Eric
>
> >
> > Best,
> >
> > Neil
>
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Eric Firing]

On 2015/05/13 12:39 AM, Neil Girdhar wrote:
> TikZ is an extremely well-designed library for generating professional
> figures within the cumbersome TeX framework.  Currently, my work flow is
> to generate TikZ code using Python.  The TikZ is compiled into PDFs,
> which are then included in my LaTeX files.  I would like to work
> entirely in Python.
>
> This means that I want to incorporate TikZ's features into matplotlib.
> I want to start with custom pgf arrowheads.  Will this be possible.
> What is the process from feature idea to pull request that I would have
> to go through?

You're on the right track by raising the idea here.  Depending on how 
complicated the idea is, the next step after some mailing list 
discussion could be either a MEP or a PR; but personally I would prefer 
to get a better picture of what you are talking about via this mailing 
list first.

Are you talking about adding high-level functionality that would be 
applicable to all backends?  Can you give an example of what sorts of 
changes would be required in mpl, and what they would accomplish?

Eric

>
> Best,
>
> Neil


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel