Re: Problem with printing plots

[Ben Abbott]

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

bug_33163.m
Description: Binary data