[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with printing plots
From: |
Ben Abbott |
Subject: |
Re: Problem with printing plots |
Date: |
Fri, 09 Mar 2012 10:19:57 -0500 |
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
- Re: Problem with printing plots, (continued)
- Re: Problem with printing plots, Daniel J Sebald, 2012/03/09
- Re: Problem with printing plots, Daniel J Sebald, 2012/03/09
- Re: Problem with printing plots, Jordi Gutiérrez Hermoso, 2012/03/09
- Re: Problem with printing plots, Jordi Gutiérrez Hermoso, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Michael Goffioul, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Michael Goffioul, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots,
Ben Abbott <=
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Michael Goffioul, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Michael Goffioul, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Michael Goffioul, 2012/03/10
- Re: Problem with printing plots, Ben Abbott, 2012/03/10
- Re: Problem with printing plots, Michael Goffioul, 2012/03/10