octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with printing plots


From: Michael Goffioul
Subject: Re: Problem with printing plots
Date: Fri, 9 Mar 2012 14:05:18 +0000

On Fri, Mar 9, 2012 at 1:48 PM, Ben Abbott <address@hidden> wrote:
> On Mar 9, 2012, at 1:08 AM, Jordi Gutiérrez Hermoso wrote:
>
>> 2012/3/9 Jordi Gutiérrez Hermoso <address@hidden>:
>>> Okay, here is a clue. I just ran this in gdb. There is definitely a
>>> problem with this code. The reason I'm seeing this is that in my debug
>>> build I compiled with --enable-bounds-checking. On line 600 of
>>> src/graphics.cc, the p vector only has two coordinates but is being
>>> indexed one past the end.
>>>
>>> Ben, I think you understand this code best. Why is this indexing past the 
>>> end?
>>
>> Sorry, the pos vector. This is being called from by
>> text::get_properties::get_extent on line 6899.
>>
>> - Jordi G. H.
>
> I took a quick look and am off to work in a minute (running late today).
>
> The text position property is a coordinate pair or triplet (2D or 3D). The 
> position property for axes and figures are vectors of length 4. The first two 
> are coordinates for the LL corner and the latter pair are the width and 
> height.
>
> My impression is that convert_text_position(pos, ...) is written to accept a 
> position vector as a coordinate triplet or [xLL, yLL, width, height].
>
> As the position property should be saved as a triplet (z coordinate is zero 
> if not specified), it looks to me like get_position() should return (x,y,z). 
> This is the way Matlab & Octave work from the command line.
>
> The other option is to modify convert_text_position to treat pos.numel() == 2 
> and pos.numel() == 3 differently.
>
> Thoughts ?

Any idea where the 2D position is coming from? (I mean, where is it set?)

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]