Thread Subject: Text property, 'extent', not working properly

It appears that the text property 'extent' does not correctly report the position of the text extent box, unless the position is a multiple of 4. The position it reports is close, which is probably why I can't find anyone else who has noticed this, but it is clearly wrong as demonstrated by the following script.

________________________________________________________________________
figure;
f=[450,450];
set(gcf,'Units','points','position',[0,0,f(1),f(2)])
fig_ax=axes('Units','points','Position',[0 0 f(1) f(2)],'Visible','off');
axis([0 f(1) 0 f(2)]);
grid_spacing=25;
for i=1:4
    for j=1:4
        label=text(j*grid_spacing,450-i*grid_spacing,'\delta','FontSize',18,...
            'HorizontalAlignment','left','Interpreter','tex',...
            'VerticalAlignment','bottom','FontName','Helvetica','units','points');
        %Print subscript if specified
        label_ext=get(label,'extent');
        label_pos=get(label,'position');
        x_ext(i,j)=label_ext(1);
        x_pos(i,j)=label_pos(1);
        y_ext(i,j)=label_ext(2);
        y_pos(i,j)=label_pos(2);
    end
end
_______________________________________________________________________
The output variables x_ext, x_pos, y_ext, and y_pos give the position of the text box. Here are those 4 outputs, for the grid spacing of 25:

x_ext =
   24.8000 50.4000 75.2000 100.0000
   24.8000 50.4000 75.2000 100.0000
   24.8000 50.4000 75.2000 100.0000
   24.8000 50.4000 75.2000 100.0000

x_pos =
    25 50 75 100
    25 50 75 100
    25 50 75 100
    25 50 75 100

y_ext =
  423.2000 423.2000 423.2000 423.2000
  398.4000 398.4000 398.4000 398.4000
  373.6000 373.6000 373.6000 373.6000
  348.0000 348.0000 348.0000 348.0000

y_pos =
   425 425 425 425
   400 400 400 400
   375 375 375 375
   350 350 350 350

As you can see, the spacing of 25 is correctly reported by x_pos and y_pos, but incorrectly reported by x_ext, and y_ext. If the grid spacing is set to 24 (a multiple of 4), the outputs x_ext and y_ext are correct. Well, hopefully I'm doing something wrong, or MathWorks will see this and correct the bug.

"Ben " <breedlun@hotmail.com> wrote in message <h3slb9$nsa$1@fred.mathworks.com>...
> It appears that the text property 'extent' does not correctly report the position of the text extent box, unless the position is a multiple of 4. The position it reports is close, which is probably why I can't find anyone else who has noticed this, but it is clearly wrong as demonstrated by the following script.

as usual: it is not a ML bug...
rather, you're snippet does not set the axis-lims correctly...

one of the solutions

% the data
     cs=24;
     f=[450,450];
% the engine
     grid_spacing=cs;
     fh=figure;
     set(fh,...
          'units','points',...
          'position',[500,100,f(1),f(2)]);
     fig_ax=axes(...
          'units','points',...
          'position',[0,0,f(1),f(2)],...
          'xlim',[0,f(1)],... % <- set XLIM!
          'ylim',[0,f(2)],... % <- set YLIM!
          'visible','off');
for i=1:4
     ypos=450-i*grid_spacing;
for j=1:4
     xpos=j*grid_spacing;
     label=text(xpos,ypos,'\delta',...
          'units','data',...
          'interpreter','tex',...
          'horizontalalignment','left',...
          'verticalalignment','bottom',...
          'fontsize',18,...
          'fontname','helvetica',...
          'backgroundcolor',[1,1,0]);
     label_ext=get(label,'extent');
     label_pos=get(label,'position');
     x_ext(i,j)=label_ext(1);
     x_pos(i,j)=label_pos(1);
     y_ext(i,j)=label_ext(2);
     y_pos(i,j)=label_pos(2);
     line([x_pos(i,j),x_pos(i,j)],[0,f(2)],...
          'color',[1,0,0]);
     line([x_ext(i,j),x_ext(i,j)],[0,f(2)],...
          'color',[0,1,0]);
end
end

us

> as usual: it is not a ML bug...
> rather, you're snippet does not set the axis-lims correctly...
>
Thanks for taking the time to reply to my post. I ran your code, but unfortunately I ran into the same problem. Here is the output from your code:

x_ext =
   23.1383 47.0745 71.0106 94.9468
   23.1383 47.0745 71.0106 94.9468
   23.1383 47.0745 71.0106 94.9468
   23.1383 47.0745 71.0106 94.9468

x_pos =
    24 48 72 96
    24 48 72 96
    24 48 72 96
    24 48 72 96

y_ext =
  422.8723 422.8723 422.8723 422.8723
  398.9362 398.9362 398.9362 398.9362
  375.0000 375.0000 375.0000 375.0000
  351.0638 351.0638 351.0638 351.0638

y_pos =
   426 426 426 426
   402 402 402 402
   378 378 378 378
   354 354 354 354

The x_pos and y_pos outputs are all spaced at 24 point intervals, but the x_ext and y_ext are at 23.9361 point intervals. This is slightly better than before, since the interval is constant, but it's still wrong. Maybe I'm missing something...

> This is slightly better than before, since the interval is constant, ...

Actually, it's not much better than before. In the latest attempt, the interval was a constant 23.9361 when it should have been 24. In the first attempt, the interval was also a constant: I got 25.6, when it should have been 25.

On 19 Jul, 04:24, "Ben " <breed...@hotmail.com> wrote:
> >  This is slightly better than before, since the interval is constant, ...
>
> Actually, it's not much better than before.  In the latest attempt, the interval was a constant 23.9361 when it should have been 24.  In the first attempt, the interval was also a constant: I got 25.6, when it should have been 25.

This question is a bit more involved than you might think.

First of all, the normalized text size is dynamic, since the
glyphs appear at the same size on screen irrespective of
axis settings in the figure.

So there is a scaling step between the fontsize and the
axis scale.

Next, there is a discretizasion / raster step when the
figure is drawn on screen. The contents has to be drawn
on a regular (x,y) grid. This is what you see.

If matlab works - as I suspect it does - by expressing
text extents in the axis scale, there are two scaling
steps in between the reported numbers and the printed
image on screen.

So you need to figure out why you need these numbers,
and add suitable safety limits around the text.

Rune

"Ben " <breedlun@hotmail.com> wrote in message <h3u041$lov$1@fred.mathworks.com>...
> > This is slightly better than before, since the interval is constant, ...
>
> Actually, it's not much better than before. In the latest attempt, the interval was a constant 23.9361 when it should have been 24. In the first attempt, the interval was also a constant: I got 25.6, when it should have been 25.

well, you seem to misunderstand the difference between
- extent
- position
if you run the snippet and change the CS, you'll see that the LINE commands that is inserted show precisely what you are asking for (if you're really(!?) asking for the extent of the TEXT box)...
also, have another look at

     doc text;
% the look at the definition of EXTENT...
% in general, yet depending on the UNITs',
% the EXTENT is NOT equal to the POSITON

us

"us " <us@neurol.unizh.ch> wrote in message <h3v2ih$6h1$1@fred.mathworks.com>...
> % the look at the definition of EXTENT...
> % in general, yet depending on the UNITs',
> % the EXTENT is NOT equal to the POSITON

Yes, I understand this. The extent is rarely equal to the position.

I may have done a poor job of explaining my issue. My claim is that the spacing between the text extent boxes should be the same as the grid spacing (cs).

I've changed my code to try to emphasize this:
_______________________________________________________________________
figure;
f=[450,450];
set(gcf,'Units','points','position',[0,0,f(1),f(2)])
fig_ax=axes('Units','points','Position',[0 0 f(1) f(2)],...
    'xlim',[0,f(1)],'ylim',[0,f(2)],'Visible','off'); %<-Setting axis limits your way
axis([0 f(1) 0 f(2)]); %<-This also sets the axis limits

grid_spacing=24;
for i=1:2
    for j=1:2
        label=text(j*grid_spacing,450-i*grid_spacing,'f','FontSize',18,...
            'HorizontalAlignment','center','Interpreter','tex',...
            'VerticalAlignment','bottom','FontName','Helvetica','units','points');
        label_ext=get(label,'extent');
        x_ext(i,j)=label_ext(1);
        y_ext(i,j)=label_ext(2);
    end
end
dx=x_ext(:,2)-x_ext(:,1)
dy=y_ext(1,:)-y_ext(2,:)
_______________________________________________________________________

When grid_spacing=24, the output is:

dx =
   24.0000
   24.0000

dy =
    24 24

This is correct. The grid spacing matches the spacing between the text extent boxes.

However, when grid_spacing=25, the output is:

dx =
   25.6000
   25.6000

dy =
   24.8000 24.8000

This, in my view, is incorrect. The grid spacing does not match the spacing between the text extent boxes.

Well, hopefully I've been a little more clear now.

"Ben " <breedlun@hotmail.com> wrote in message <h3v5pm$6sa$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <h3v2ih$6h1$1@fred.mathworks.com>...
> > % the look at the definition of EXTENT...
> > % in general, yet depending on the UNITs',
> > % the EXTENT is NOT equal to the POSITON
>
> Yes, I understand this. The extent is rarely equal to the position.
>
> I may have done a poor job of explaining my issue. My claim is that the spacing between the text extent boxes should be the same as the grid spacing (cs).
>
> I've changed my code to try to emphasize this:
> _______________________________________________________________________
> figure;
> f=[450,450];
> set(gcf,'Units','points','position',[0,0,f(1),f(2)])
> fig_ax=axes('Units','points','Position',[0 0 f(1) f(2)],...
> 'xlim',[0,f(1)],'ylim',[0,f(2)],'Visible','off'); %<-Setting axis limits your way
> axis([0 f(1) 0 f(2)]); %<-This also sets the axis limits
>
> grid_spacing=24;
> for i=1:2
> for j=1:2
> label=text(j*grid_spacing,450-i*grid_spacing,'f','FontSize',18,...
> 'HorizontalAlignment','center','Interpreter','tex',...
> 'VerticalAlignment','bottom','FontName','Helvetica','units','points');
> label_ext=get(label,'extent');
> x_ext(i,j)=label_ext(1);
> y_ext(i,j)=label_ext(2);
> end
> end
> dx=x_ext(:,2)-x_ext(:,1)
> dy=y_ext(1,:)-y_ext(2,:)
> _______________________________________________________________________
>
> When grid_spacing=24, the output is:
>
> dx =
> 24.0000
> 24.0000
>
> dy =
> 24 24
>
> This is correct. The grid spacing matches the spacing between the text extent boxes.
>
> However, when grid_spacing=25, the output is:
>
> dx =
> 25.6000
> 25.6000
>
> dy =
> 24.8000 24.8000
>
> This, in my view, is incorrect. The grid spacing does not match the spacing between the text extent boxes.
>
> Well, hopefully I've been a little more clear now.

well, yes - and no...
1) did you use my snippet at all - including the LINEs, which (precisely) show you
    the POS and EXT of the background colored characters...
2) if you add these commands to your snippet: what do you see(?)...
3) now, what happens if you do this (make your snippet a bit more versatile...)
a) change your
     f=[450,450];
   to
     f=[450,250];
   and, thus, change
     label=text(j*grid_spacing,450-i*grid_spacing,'f','FontSize',18,...
   to
     label=text(j*grid_spacing,f(2)-i*grid_spacing,'f','FontSize',18,...
b) observe your Ds
c) now, since you're using PEL units, think about quantization...

us

Ok, I modified my code to include your suggestions:
________________________________________________________________________
figure;
f=[450,250];
set(gcf,'Units','points','position',[0,0,f(1),f(2)])
fig_ax=axes('Units','points','Position',[0 0 f(1) f(2)],...
    'xlim',[0,f(1)],'ylim',[0,f(2)],'Visible','off');
axis([0 f(1) 0 f(2)]);

grid_spacing=25;
for i=1:2
    for j=1:2
        label=text(j*grid_spacing,f(2)-i*grid_spacing,'\delta','FontSize',18,...
            'HorizontalAlignment','center','Interpreter','tex',...
            'VerticalAlignment','bottom','FontName','Helvetica','units','points');
        label_ext=get(label,'extent');
        label_pos=get(label,'position');
        x_ext(i,j)=label_ext(1);
        x_pos(i,j)=label_pos(1);
        y_ext(i,j)=label_ext(2);
        y_pos(i,j)=label_pos(2);
        line([x_pos(i,j),x_pos(i,j)],[0,f(2)],...
          'color',[1,0,0]);
        line([x_ext(i,j),x_ext(i,j)],[0,f(2)],...
          'color',[0,1,0]);
    end
end
dx=x_ext(:,2)-x_ext(:,1)
dy=y_ext(1,:)-y_ext(2,:)
_______________________________________________________________________

1) The lines do show me that position and extent are not the same, but I was not disputing this. The red lines are in the center of the text, and they are correctly spaced at 25. The green lines are at the left edge of the text, and they are spaced at 25.6.

2) I changed the figure window size like you suggested. Here is my output:

dx =
   25.6000
   25.6000

dy =
   24.8000 24.8000

The values of dx and dy did not change when I changed the figure window size.

3) You mentioned quantization, and so did Rune in an earlier post. This is possible, but I would be surprised if it is this bad. I'm not sure if this is the right comparison, but an error of 0.6 out of 1440 pixels across my screen isn't very good. That would mean there is only about 12 bits of resolution.

I think it is a quantization thing. For whatever reason it seems the value of extent is rounded to 0.2. (This might be true of all position properties, I can't remember ever seeing better precision than that... but i could be wrong) Assuming your get(0,'screenpixelsperinch') is 96, one point is 96/72=4/3 pixels. Thus 24 points is 32 pixels, but 25 points is 33.333 pixels, which when rounded the nearest .2 is gonna give some error.

But what is the problem you're trying to solve here? I've always just found it more annoying to have positions that are not rounded to the nearest pixel (since that's how they appear on screen). Is there any reason you can't just work in pixel units and avoid this problem entirely? Do you really need sub-pixel resolution in your answers?

"matt dash" <n.a@mail.com> wrote in message <h3veu5$739$1@fred.mathworks.com>...
>
>
> I think it is a quantization thing. For whatever reason it seems the value of extent is rounded to 0.2. (This might be true of all position properties, I can't remember ever seeing better precision than that... but i could be wrong) Assuming your get(0,'screenpixelsperinch') is 96, one point is 96/72=4/3 pixels. Thus 24 points is 32 pixels, but 25 points is 33.333 pixels, which when rounded the nearest .2 is gonna give some error.
>
> But what is the problem you're trying to solve here? I've always just found it more annoying to have positions that are not rounded to the nearest pixel (since that's how they appear on screen). Is there any reason you can't just work in pixel units and avoid this problem entirely? Do you really need sub-pixel resolution in your answers?

Thanks, Matt, for your reply. I think you may be right. Extent only gives me values rounded to 0.2 (position can give me more precise values). My get(0,'screenpixelsperinch')=90, so one point is 5/4 pixels. Extent seems to give correct locations for the extent box when grid_spacing is any multiple of 4. And 24 happens to be a multiple of 4 and 3, which is why your analysis worked out too.

The problem I'm trying to solve here is a rather ridiculous one. In a plot, my advisor absolutely requires roman letters to be 18 pt helvetica font and greek letters to be 21 pt symbol font. He also wants the subscripts in a specific location relative to the base variable. The only way I can figure out how to do this in Matlab is to explicitly place the subscript, rather than use LaTeX or TeX. To place the subscript accurately I need to know the location and size of the base variable, which is why I was trying to use the extent property. Once I'm done creating a plot, I export it to pdf, and sometimes blow it up to put in posters and presentations. In these cases, having sub-pixel resolution becomes important. It's insane, I know, but my advisor is rather draconian about the appearance of plots.

"Ben " <breedlun@hotmail.com> wrote in message
> Thanks, Matt, for your reply. I think you may be right. Extent only gives me values rounded to 0.2 (position can give me more precise values). My get(0,'screenpixelsperinch')=90, so one point is 5/4 pixels. Extent seems to give correct locations for the extent box when grid_spacing is any multiple of 4. And 24 happens to be a multiple of 4 and 3, which is why your analysis worked out too.
>
> The problem I'm trying to solve here is a rather ridiculous one. In a plot, my advisor absolutely requires roman letters to be 18 pt helvetica font and greek letters to be 21 pt symbol font. He also wants the subscripts in a specific location relative to the base variable. The only way I can figure out how to do this in Matlab is to explicitly place the subscript, rather than use LaTeX or TeX. To place the subscript accurately I need to know the location and size of the base variable, which is why I was trying to use the extent property. Once I'm done creating a plot, I export it to pdf, and sometimes blow it up to put in posters and presentations. In these cases, having sub-pixel resolution becomes important. It's insane, I know, but my advisor is rather draconian about the appearance of plots.


Ah, I suppose that's as good a reason as any.

On further investigation, I think it's a little different that I said above. The rounding is actually to (in your case) 72/90 = 0.8 (all your extents are multiples of 0.8). In my case the rounding is to 0.75 because i have 96 dpi. Apparently MATLAB calculates all positions/extents in integer values of pixels, so when you ask for the extent in points, it just calculates it rounded to the nearest pixel, and then converts to points by multiplying by 72/90. I suppose this means you can't actually specify a precision to a fraction of a pixel, so if you need more precision you'll need to actually make your figure larger on the screen so it has more pixels to work with. You might be able to set up your figure, then set all units to "normalized" using set(get(gcf,'children'),'units','normalized) then scale up the figure and everything inside should scale up accordingly. Maybe then you can make
minor adjustments where you need to before you export.

On 19 Jul, 18:22, "Ben " <breed...@hotmail.com> wrote:

> It's insane, I know, but my advisor is rather draconian about the appearance of plots.

This advisor doesn't have the faintest clue what he is doing.
People who know their field are leniant about bueraucratic
details like the appearance of plots. Such people pragmatically
accept the results of whatever tools are available instead of
demanding this and that format, that is hard to achieve.

In contrast, people who are already in deep waters address
these kinds of things because they are easy to spot and either
correct or wrong. That way such people grasp on to an illusion
of being in control, when in fact they are not.

Get a different advisor. Or switch jobs. A soon as possible.
The present advisor will do you no good.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <2f4d4d0b-44d5-4ab2-b4bb-82d776a1655c@g31g2000yqc.googlegroups.com>...
> On 19 Jul, 18:22, "Ben " <breed...@hotmail.com> wrote:
>
> >?It's insane, I know, but my advisor is rather draconian about the appearance of plots.
>
> This advisor doesn't have the faintest clue what he is doing.
> People who know their field are leniant about bueraucratic
> details like the appearance of plots. Such people pragmatically
> accept the results of whatever tools are available instead of
> demanding this and that format, that is hard to achieve.
>
> In contrast, people who are already in deep waters address
> these kinds of things because they are easy to spot and either
> correct or wrong. That way such people grasp on to an illusion
> of being in control, when in fact they are not.
>
> Get a different advisor. Or switch jobs. A soon as possible.
> The present advisor will do you no good.
>
> Rune

...i just ABSOLUTELY(!) AGREE with rune...
and again, if you use PEL units, any non-integer value is - at most - hilarious...

us

I saw a similar issue before when trying to use centimeters.

Even if one naively uses 1 inch = 2.54 cm. Only a grid spacing of multiples of 2.53807 (MATLAB's conversion factor) will yield matching extent and position values.

"Matt Fig" <spamanon@yahoo.com> wrote in message <h3vrue$mvb$1@fred.mathworks.com>...
> I saw a similar issue before when trying to use centimeters.
>
> Even if one naively uses 1 inch = 2.54 cm. Only a grid spacing of multiples of 2.53807 (MATLAB's conversion factor) will yield matching extent and position values.

Thanks again, Matt. You nailed it on the head when you said that it rounds to the nearest pixel. I checked and it always reports the extent values to the nearest 72 pt/96 pix=0.8 pt/pix.

I'm just going to write my own extent function that uses the position property to get the location of the center of the text (all text will be center and middle aligned), and uses the extent property to find the height and width. The height and width will still round to the nearest 0.8 pt (on my computer), but their impact will be cut in half since I'm referencing from the center of the text. Also, by using the position property, which doesn't seem to be subject to this nearest pixel rounding, I won't have the tolerance stackup issue, so that will reduce my error as well. Worst case before was 0.8 pt off the location and 0.8 pt off in the width, leading to 1.6 pt off total. Now, worst case will be 0.4 pt off. That should be more manageable.

Just to be clear: Matt Dash and I are two different people.


I wish I had time last night to clarify what you were seeing (as I experienced this before), but I only had time to tag the thread "nobug" to remind myself to come back to it today. Fortunately, by the time I had time today, Matt Dash had already come to the rescue. Glad it was resolved.

"Matt Fig" <spamanon@yahoo.com> wrote in message <h3vugu$fk9$1@fred.mathworks.com>...
> Just to be clear: Matt Dash and I are two different people.
>
>
> I wish I had time last night to clarify what you were seeing (as I experienced this before), but I only had time to tag the thread "nobug" to remind myself to come back to it today. Fortunately, by the time I had time today, Matt Dash had already come to the rescue. Glad it was resolved.

Oh, I guess the thanks just go to Matt Dash. =)

Just to be clear, I wouldn't say this issue is really resolved. I just have the work around I described in post #16. Matlab still rounds to the nearest pixel, which is fine if you are never going to blow up a figure, but it's unacceptable if you are going to use a figure in a poster or a presentation. The whole point of vector graphics is that they can be scaled and moved without running into resolution issues, but this pixel rounding kills that ability.

On 20 Jul, 17:27, "Ben " <breed...@hotmail.com> wrote:

> Just to be clear, I wouldn't say this issue is really resolved.  I just have the work around I described in post #16.  Matlab still rounds to the nearest pixel, which is fine if you are never going to blow up a figure, but it's unacceptable if you are going to use a figure in a poster or a presentation.  The whole point of vector graphics is that they can be scaled and moved without running into resolution issues, but this pixel rounding kills that ability.

Wrong. The problem is that you magnify a font
that was designed to work at the resolution you
drew it. If you magnify the figure, then of course
rasterization effect will make your life miserable.

If you want to make a figure in several sizes,
make a function file:

- Script the drawing of the figure
- Then configure the figure, setting line widths,
  font sizes, fonts, colors etc.
- Set the papersize and paperposition
- Print the figure

In other words, something like

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
plot(randn(10,1),'linewidth',23)
set(gca,'linewidth',20)
set(gca,'fontsize',20)
text(2,1,'Text','fontsize',128)
set(gcf,'papertype','A0')
set(gcf,'paperunits','normalized')
set(gcf,'paperposition',[0.05 0.05 0.9 0.9])
print -dpdf text.pdf
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

If you print this A0-size picture, there will be
no problems with jagged edges of fonts or anything
like that.

If you structure your function correctly, you only
have to call it with two sets of parameters,
and you get one figure for your report and one figure
that works in big size.

Rune