Re: Problem with printing plots

[Ben Abbott]

On Mar 9, 2012, at 10:19 AM, Ben Abbott wrote:

> On Mar 9, 2012, at 10:07 AM, Ben Abbott wrote:
> 
>> On Mar 9, 2012, at 10:02 AM, Michael Goffioul wrote:
>> 
>>> 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.
>> 
>> The code that produced Jordi's error is from geometry_images.m. 
>> Specifically, ...
>> 
>> rand ("state", 9);
>> x = rand (10, 1);
>> y = rand (10, 1);
>> tri = delaunay (x, y);
>> [vx, vy] = voronoi (x, y, tri);
>> triplot (tri, x, y, "b");
>> hold on;
>> plot (vx, vy, "r");
>> [r, c] = tri2circ (tri(end,:), x, y);
>> pc = [-1:0.01:1];
>> xc = r * sin(pi*pc) + c(1);
>> yc = r * cos(pi*pc) + c(2);
>> plot (xc, yc, "g-", "LineWidth", 3);
>> axis([0, 1, 0, 1]);
>> legend ("Delaunay Triangulation", "Voronoi Diagram");
>> print -dpdfwrite voronoi.pdf
>> 
>> I've attached an m-file. I suspect the m-file set() command you're looking 
>> for is part of legend.m
>> 
>> Ben
> 
> After running that script I attached, text objects 9 and 10 have position 
> vectors of length 2. These are part of the legend.
> 
> get (findall (gcf, "type", "text"), "position")
> ans = 
> {
>  [1,1] =
> 
>     0.50000  -0.05260   0.00000
> 
>  [2,1] =
> 
>    -0.05069   0.50000   0.00000
> 
>  [3,1] =
> 
>     0.00000   1.01462   0.50000
> 
>  [4,1] =
> 
>     0.50000   1.02921   0.50000
> 
>  [5,1] =
> 
>     0.50000  -0.15625   0.00000
> 
>  [6,1] =
> 
>    -0.03125   0.50000   0.00000
> 
>  [7,1] =
> 
>     0.00000   1.15625   0.50000
> 
>  [8,1] =
> 
>     0.50000   1.31691   0.50000
> 
>  [9,1] =
> 
>     0.83526   0.75000
> 
>  [10,1] =
> 
>     0.83526   0.25000
> 
>  [11,1] =
> 
>     0   0   0
> 
> }
> 
> I have no idea why the position isn't returned as a triplet.
> 
> Ben

This is not working correctly.

p = get (ht(9), "position")
p =

   0.83526   0.75000

set (ht(9), "position", [p, 0])
get (ht(9), "position")
ans =

   0.83526   0.75000   0.00000

set (ht(9), "position", p)
get (ht(9), "position")
ans =

   0.83526   0.75000

get (ht, "position") should always return a triplet.

Ben