MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

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

 Subject: Text property, 'extent', not working properly From: Ben Date: 18 Jul, 2009 14:14:01 Message: 1 of 20 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.
 Subject: Text property, 'extent', not working properly From: us Date: 18 Jul, 2009 19:58:01 Message: 2 of 20 "Ben " wrote in message ... > 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
 Subject: Text property, 'extent', not working properly From: Ben Date: 19 Jul, 2009 01:34:01 Message: 3 of 20 > 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...
 Subject: Text property, 'extent', not working properly From: Ben Date: 19 Jul, 2009 02:24:01 Message: 4 of 20 > 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.
 Subject: Text property, 'extent', not working properly From: Rune Allnor Date: 19 Jul, 2009 12:03:09 Message: 5 of 20 On 19 Jul, 04:24, "Ben " 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
 Subject: Text property, 'extent', not working properly From: us Date: 19 Jul, 2009 12:12:01 Message: 6 of 20 "Ben " wrote in message ... > > 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
 Subject: Text property, 'extent', not working properly From: Ben Date: 19 Jul, 2009 13:07:02 Message: 7 of 20 "us " wrote in message ... > % 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.
 Subject: Text property, 'extent', not working properly From: us Date: 19 Jul, 2009 14:00:02 Message: 8 of 20 "Ben " wrote in message ... > "us " wrote in message ... > > % 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
 Subject: Text property, 'extent', not working properly From: Ben Date: 19 Jul, 2009 14:52:01 Message: 9 of 20 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.
 Subject: Text property, 'extent', not working properly From: matt dash Date: 19 Jul, 2009 15:43:01 Message: 10 of 20 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?
 Subject: Text property, 'extent', not working properly From: Ben Date: 19 Jul, 2009 16:22:01 Message: 11 of 20 "matt dash" wrote in message ... > > > 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.
 Subject: Text property, 'extent', not working properly From: Rune Allnor Date: 19 Jul, 2009 17:23:39 Message: 13 of 20 On 19 Jul, 18:22, "Ben " 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
 Subject: Text property, 'extent', not working properly From: us Date: 19 Jul, 2009 18:02:01 Message: 14 of 20 Rune Allnor wrote in message <2f4d4d0b-44d5-4ab2-b4bb-82d776a1655c@g31g2000yqc.googlegroups.com>... > On 19 Jul, 18:22, "Ben " 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
 Subject: Text property, 'extent', not working properly From: Matt Fig Date: 19 Jul, 2009 19:25:03 Message: 15 of 20 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.
 Subject: Text property, 'extent', not working properly From: Ben Date: 19 Jul, 2009 20:00:02 Message: 16 of 20 "Matt Fig" wrote in message ... > 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.
 Subject: Text property, 'extent', not working properly From: Matt Fig Date: 19 Jul, 2009 20:09:02 Message: 17 of 20 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.
 Subject: Text property, 'extent', not working properly From: Ben Date: 20 Jul, 2009 15:27:01 Message: 18 of 20 "Matt Fig" wrote in message ... > 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.
 Subject: Text property, 'extent', not working properly From: Rune Allnor Date: 20 Jul, 2009 16:15:03 Message: 19 of 20 On 20 Jul, 17:27, "Ben " 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
 Subject: Text property, 'extent', not working properly From: Billy Date: 21 Mar, 2010 07:23:22 Message: 20 of 20 "us " wrote in message ... > "Ben " wrote in message ... > > "us " wrote in message ... > > > % 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. http://www.wikio.com/article/bad-credit-payday-loans-176415445 > > > > 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