Re: Problem with printing plots

[Michael Goffioul]

On Fri, Mar 9, 2012 at 2:54 PM, Ben Abbott <address@hidden> wrote:
>
> On Mar 9, 2012, at 9:05 AM, Michael Goffioul wrote:
>
>> 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.
>
> I have no idea why a 2D vector is being returned. The text position property 
> is defined in graphics.h.in
>
> 4241     BEGIN_PROPERTIES (text)
> 4242       text_label_property string u , ""
> 4243       radio_property units u , 
> "{data}|pixels|normalized|inches|centimeters|points"
> 4244       array_property position mu , Matrix (1, 3, 0.0)
> 4245       double_property rotation mu , 0
>
> I'd expect that both pos = get_position ().matrix_value () or pos = 
> position.get () would always return a triplet.
>
> I noticed the code below in graphics.h.in. I don't understand what its 
> supposed to do, but it looks suspicious to me.
>
> 4287   protected:
> 4288     void init (void)
> 4289       {
> 4290         position.add_constraint (dim_vector (1, 2));
> 4291         position.add_constraint (dim_vector (1, 3));
> 4292         cached_units = get_units ();
> 4293         update_font ();
> 4294       }

This does not change the text position, but simply relax the
constraint on the position property by allowing a 2D vector. What I'm
trying to figure out is where the 2D vector is assigned. I also see
the code in update_xlabel_position (and similar), but the set_position
call also uses a triplet. Maybe the 2D vector is coming from the
m-code...

Michael.