text with dash problems

Manuel and Michael worked on fixing a bug with TextWithDash, but this
introduced a bug will all tick labels so I reverted the changes. The
problem is that the text layout code in Text (eg draw,
get_window_extent) is using "get_position" which in TextWithDash is
the dash position, according to the doc string and the original impl.
On the branch, the draw and layout methods of Text use _get_xy_display
which TextWithDash overrides. That is why it works on the branch and
not the trunk. The changes of M&M to make set_position and
get_position refer to the x and y locs fixed dash with text for
reasons that are not completely clear t me, but broke tick labels
which are also TextWithDash instances.

I did not write TextWithDash so cannot vouch for its conventions, but
I don't have time to dig deeply enough right now to fix this, so I
wanted to revert the changes so regular plots would work again and
give a head's up here so Manuel, Michael and I would not be doing and
undoing each other's changes w/o some understanding of where the
discerpancy was arising.

Thanks,
JDH

John Hunter wrote:

Manuel and Michael worked on fixing a bug with TextWithDash, but this
introduced a bug will all tick labels so I reverted the changes. The
problem is that the text layout code in Text (eg draw,
get_window_extent) is using "get_position" which in TextWithDash is
the dash position, according to the doc string and the original impl.
On the branch, the draw and layout methods of Text use _get_xy_display
which TextWithDash overrides. That is why it works on the branch and
not the trunk. The changes of M&M to make set_position and
get_position refer to the x and y locs fixed dash with text for
reasons that are not completely clear t me, but broke tick labels
which are also TextWithDash instances.

I did not write TextWithDash so cannot vouch for its conventions, but
I don't have time to dig deeply enough right now to fix this, so I
wanted to revert the changes so regular plots would work again and
give a head's up here so Manuel, Michael and I would not be doing and
undoing each other's changes w/o some understanding of where the
discerpancy was arising.

Hm, the patch I applied was exactly because I got also problems with the tick labels -- they were all squashed to one place -- and I thought to have fixed that. Now, it seems this wasn't quite correct :wink:
   As I have also no deeper understanding what's _really_ going on in TextWithDash, I will now better keep my hands off TextWithDash ...

Manuel

···

Thanks,
JDH

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hate to say "me too", but I don't really understand text with dash either... I'll have a look when I have adequate time to devote to it, if no one else volunteers.

Cheers,
Mike

Manuel Metz wrote:

···

John Hunter wrote:
  

Manuel and Michael worked on fixing a bug with TextWithDash, but this
introduced a bug will all tick labels so I reverted the changes. The
problem is that the text layout code in Text (eg draw,
get_window_extent) is using "get_position" which in TextWithDash is
the dash position, according to the doc string and the original impl.
On the branch, the draw and layout methods of Text use _get_xy_display
which TextWithDash overrides. That is why it works on the branch and
not the trunk. The changes of M&M to make set_position and
get_position refer to the x and y locs fixed dash with text for
reasons that are not completely clear t me, but broke tick labels
which are also TextWithDash instances.

I did not write TextWithDash so cannot vouch for its conventions, but
I don't have time to dig deeply enough right now to fix this, so I
wanted to revert the changes so regular plots would work again and
give a head's up here so Manuel, Michael and I would not be doing and
undoing each other's changes w/o some understanding of where the
discerpancy was arising.
    
Hm, the patch I applied was exactly because I got also problems with the tick labels -- they were all squashed to one place -- and I thought to have fixed that. Now, it seems this wasn't quite correct :wink:
   As I have also no deeper understanding what's _really_ going on in TextWithDash, I will now better keep my hands off TextWithDash ...

Manuel

Thanks,
JDH

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
    
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Daishi,

I don't know if this is still the right email address for you, but if
so could you let us know if you could look at the TextWithDash
implementation in matplotlib svn trunk. Our transformations have
undergone a bit of refactoring, and some relatively minor changes were
made in the Text base class positioning code, but these were enough to
break the TextWithDash layout. Let us know if you have a minute to
look at this and perhaps provide a patch to bring TextWithDash
functionality back.

Thanks,
JDH

···

On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <mdroe@...31...> wrote:

Hate to say "me too", but I don't really understand text with dash
either... I'll have a look when I have adequate time to devote to it,
if no one else volunteers.

Daishi's original contribution of TextWithDash used delegation, which was
causing some trouble with object introspection and the dynamically generated
list of properties. I refactored his work way back in March 2006, svn 2226:
http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd55%40cornell.edu

Sorry I'm just now getting to this thread. I recall the behavior of
get_position referring to the dash position was strange for a subclass of
Text, but this was simply a continuation of the original implimentation. I
was only concerned with exposing all of TextWithDash's methods to object
introspection when I made my contribution. I also recall seeing strange
behavior like what Manuel posted. I'll have a look when I get a chance,
hopefully this evening.

···

On Monday 30 June 2008 09:06:59 am John Hunter wrote:

On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <mdroe@...31...> wrote:
> Hate to say "me too", but I don't really understand text with dash
> either... I'll have a look when I have adequate time to devote to it,
> if no one else volunteers.

Daishi,

I don't know if this is still the right email address for you, but if
so could you let us know if you could look at the TextWithDash
implementation in matplotlib svn trunk. Our transformations have
undergone a bit of refactoring, and some relatively minor changes were
made in the Text base class positioning code, but these were enough to
break the TextWithDash layout. Let us know if you have a minute to
look at this and perhaps provide a patch to bring TextWithDash
functionality back.

I *think* I found a simple fix: use the Text._x and ._y directly in draw,
rather than get_position which refers to the text position in Text and the
Dash position in TextWith Dash (thank you for pointing this out, John). Please
let me know if something is still amiss, svn 5701.

I had another working solution which let get/set_position refer to the text
position, and added get/set_dashposition. I didn't like it as much, because
the text position could be set by the user and would then be overridden by
update_coords. But maybe it was a more coherent way to do it. set_position
could recalculate the dash length, and set_dashlength/pad/push would
recalculate the text position. (The dash position is always the reference.) I
think it might be more trouble than its worth, it would take a lot of work and
would cause API breakage.

Darren

···

On Monday 30 June 2008 10:40:27 Darren Dale wrote:

On Monday 30 June 2008 09:06:59 am John Hunter wrote:
> On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <mdroe@...31...> wrote:
> > Hate to say "me too", but I don't really understand text with dash
> > either... I'll have a look when I have adequate time to devote to it,
> > if no one else volunteers.
>
> Daishi,
>
> I don't know if this is still the right email address for you, but if
> so could you let us know if you could look at the TextWithDash
> implementation in matplotlib svn trunk. Our transformations have
> undergone a bit of refactoring, and some relatively minor changes were
> made in the Text base class positioning code, but these were enough to
> break the TextWithDash layout. Let us know if you have a minute to
> look at this and perhaps provide a patch to bring TextWithDash
> functionality back.

Daishi's original contribution of TextWithDash used delegation, which was
causing some trouble with object introspection and the dynamically
generated list of properties. I refactored his work way back in March 2006,
svn 2226:
http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd
55%40cornell.edu

Sorry I'm just now getting to this thread. I recall the behavior of
get_position referring to the dash position was strange for a subclass of
Text, but this was simply a continuation of the original implimentation. I
was only concerned with exposing all of TextWithDash's methods to object
introspection when I made my contribution. I also recall seeing strange
behavior like what Manuel posted. I'll have a look when I get a chance,
hopefully this evening.

Darren Dale wrote:

Hate to say "me too", but I don't really understand text with dash
either... I'll have a look when I have adequate time to devote to it,
if no one else volunteers.

Daishi,

I don't know if this is still the right email address for you, but if
so could you let us know if you could look at the TextWithDash
implementation in matplotlib svn trunk. Our transformations have
undergone a bit of refactoring, and some relatively minor changes were
made in the Text base class positioning code, but these were enough to
break the TextWithDash layout. Let us know if you have a minute to
look at this and perhaps provide a patch to bring TextWithDash
functionality back.

Daishi's original contribution of TextWithDash used delegation, which was
causing some trouble with object introspection and the dynamically
generated list of properties. I refactored his work way back in March 2006,
svn 2226:
http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd
55%40cornell.edu

Sorry I'm just now getting to this thread. I recall the behavior of
get_position referring to the dash position was strange for a subclass of
Text, but this was simply a continuation of the original implimentation. I
was only concerned with exposing all of TextWithDash's methods to object
introspection when I made my contribution. I also recall seeing strange
behavior like what Manuel posted. I'll have a look when I get a chance,
hopefully this evening.

I *think* I found a simple fix: use the Text._x and ._y directly in draw, rather than get_position which refers to the text position in Text and the Dash position in TextWith Dash (thank you for pointing this out, John). Please let me know if something is still amiss, svn 5701.

I had another working solution which let get/set_position refer to the text position, and added get/set_dashposition. I didn't like it as much, because the text position could be set by the user and would then be overridden by update_coords. But maybe it was a more coherent way to do it. set_position could recalculate the dash length, and set_dashlength/pad/push would recalculate the text position. (The dash position is always the reference.) I think it might be more trouble than its worth, it would take a lot of work and would cause API breakage.

   With that patch everything is working for me: dashpointlabel is working, tick labels are also correctly drawn, and the dashtick example now also works fine again (both GUI and png output) !

Manuel

···

On Monday 30 June 2008 10:40:27 Darren Dale wrote:

On Monday 30 June 2008 09:06:59 am John Hunter wrote:

On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <mdroe@...31...> > wrote:

Darren

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

That seems like an easy enough fix, and my simple tests are working
fine, but it speaks well of you that you found it, because the dash
with text innards are sufficiently confusing that it left Michael,
Manuel and I scratching our heads. All the better because my email to
Daishi bounced. Thanks, Darren.

JDH

···

On Mon, Jun 30, 2008 at 6:34 PM, Darren Dale <dsdale24@...149...> wrote:

I *think* I found a simple fix: use the Text._x and ._y directly in draw,
rather than get_position which refers to the text position in Text and the
Dash position in TextWith Dash (thank you for pointing this out, John). Please
let me know if something is still amiss, svn 5701.