bugGNU Octave - Bugs: bug #55075, text displayed in italic font is...

 
 

bug #55075: text displayed in italic font is clipped on right-hand side (GUI and printing)

Submitter:  Rik <rik5>
Submitted:  Thu 22 Nov 2018 08:59:34 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 10 Dec 2018 02:12:16 AM UTC, comment #10: 

I pushed Pantxo's changeset here https://hg.savannah.gnu.org/hgweb/octave/rev/8d4f23b7f4eb.

I followed it up with a change to render the "Margin" property of text objects in points, rather than pixels.  This is a hack.  See https://hg.savannah.gnu.org/hgweb/octave/rev/6652de1fe896.

There is the problem with legend objects looking clipped, but I will make that the subject of a new bug report.

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Sun 09 Dec 2018 04:01:16 PM UTC, comment #9: 

The code for rendering text in gl-render.cc is at line 3702.


    double m = props.get_margin ();
    const Matrix bbox = props.get_extent_matrix ();
    double x0 = bbox (0) / m_devpixratio - m;
    double x1 = x0 + bbox(2) / m_devpixratio + 2 * m;
    double y0 = -(bbox (1) / m_devpixratio - m);
    double y1 = y0 - (bbox(3) / m_devpixratio + 2 * m);


So it appears that the Margin is being correctly added to every side of the text object.  However, it seems to be measured in pixels in Octave which does produce too small a result.

Rik <rik5>
Group administrator
Sun 09 Dec 2018 03:44:16 PM UTC, comment #8: 

For testing purposes, I have attached a short script tst_text.m


ht = text (0.5, 0.5, 'Hello World', 'FontSize', 20, 'FontName', 'Times New Roman', 'BackgroundColor', 'r', 'edgecolor', 'k', 'linewidth', 2);




(file #45609)

Rik <rik5>
Group administrator
Sun 09 Dec 2018 03:42:16 PM UTC, comment #7: 

The spacing issue that I identified in comment #6 is probably easier to resolve than I thought.

There seems to be two issues.  The first issue is that the "Margin" property in Octave seems to be divided by 2 and half of the Margin value applied above any text and haf applied below any text.  This should be verified with Matlab, but my understanding is that the Margin is applied on every side of the Extent property to determine the final bounding box size.  For documentation see https://www.mathworks.com/help/matlab/ref/matlab.graphics.primitive.text-properties.html

The second possible issue is that the extent default in Octave is 2, and maybe measured in pixels, rather than 3, and measured in points as in Matlab.  If measured in points, I would expect that 3/72 of an inch is 4 pixels on most display where there ar 96 PPI.

I checked in a changeset to make the default 3 here (https://hg.savannah.gnu.org/hgweb/octave/rev/ef0998af70f9).  However, if the text Margin code is still using pixels rather than points, then this will be too small.

Rik <rik5>
Group administrator
Tue 27 Nov 2018 08:27:08 PM UTC, comment #6: 

Results are much prettier now.  I have two questions.  In the commit message, there is this remark,


  (ft_text_renderer::process_character): In BBOX mode update m_ymin, m_ymax and
  m_deltax after each rendered character.


Is that going to introduce a lot of overhead and slow down plotting?

Second question, there is a spacing issue with text and axes in legend objects.  See the attached file of "demo area 1".  The bottom "cos^2" is too close (exactly on) the legend border.  When printed, extra space is introduced so that output looks okay, but the onscreen rendering isn't as good.



Rik <rik5>
Group administrator
Tue 27 Nov 2018 09:03:06 AM UTC, comment #5: 

Thank you both for testing. I attached an updated version of the patch. Axes ticks and labels are now placed pretty much the same way as before, except that the offset for tick labels is based on the fontsize (so that ticks don't overlap at the origin even with large fonts).

(file #45536)

Pantxo Diribarne <pantxo>
Group Member
Sat 24 Nov 2018 05:10:28 PM UTC, comment #4: 

The patch solves the issue I reported.  I think it is a step forward, and then we have to go back and adjust the rest of the code.  It seems that the "tightinset" propert has changed (it is probably more accurate now).  See the results below:

Old Code:


>> get (gca, 'tightinset')
ans =

   0.048214   0.069058   0.000000   0.054762


New Code:


>> get (gca, 'tightinset')
ans =

   0.048214   0.042868   0.000000   0.050000


The second value has changed quite a bit and is probably where the fix needs to happen.  Or, we need to add a specific offset to tightinset for all of the labels.


Rik <rik5>
Group administrator
Fri 23 Nov 2018 10:56:06 AM UTC, comment #3: 

I tried the patch and it seems to work: there's no clipping horizontally any more and the bbox is a bit tighter vertically (making the width of the border uniform around the text).

Guillaume <gyom>
Fri 23 Nov 2018 10:21:10 AM UTC, comment #2: 

I am attaching here a "work in progress" version of my patch:

  • It solves the issue of this report.
  • The bbox height is no more over estimated, see e.g.



clf;
ht = text (0.25, 0.5, "Hello World", "FontSize", 40, ...
           "FontAngle", "Italic", "backgroundcolor", "r");


The main issue to be resolved is that now that the text bbox is more accurate, xtick labels are too close to the axes ...

Anyway, Rik, can you test the preliminary patch?

Thanks in advance.

(file #45514)

Pantxo Diribarne <pantxo>
Group Member
Fri 23 Nov 2018 08:34:01 AM UTC, comment #1: 

Confirmed. I have been working on a patch to improve the calculation of text height. Before submitting the patch, I'll polish it try to also do a better job at handling the text width.

Pantxo Diribarne <pantxo>
Group Member
Thu 22 Nov 2018 08:59:34 PM UTC, original submission:  

Try the following code:


close all
grapics_toolkit qt
ht = text (0.25, 0.5, "Hello World", "FontSize", 40, "FontAngle", "Italic");


The final letter 'd' is not fully displayed.  This is onscreen and also when printing to a raster format such as PNG.  Printing to PDF displays the entire text.

This is probably because the extents for the text box are not calculated properly when the font is slanted.


Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45609:  tst_text.m added by rik5 (142B - text/x-matlab)
file #45541:  area1.new.png added by rik5 (15KiB - image/png)
file #45536:  ftfont4.patch added by pantxo (14KiB - text/x-patch)
file #45514:  ftbbox.patch added by pantxo (9KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-10 rik5 StatusPatch Reviewed Fixed
        Open/ClosedOpen Closed
    2018-12-09 rik5 StatusPatch Submitted Patch Reviewed
    2018-12-09 rik5 Attached File- Added tst_text.m, #45609
    2018-11-27 rik5 Attached File- Added area1.new.png, #45541
    2018-11-27 pantxo Attached File- Added ftfont4.patch, #45536
        StatusConfirmed Patch Submitted
    2018-11-23 pantxo Attached File- Added ftbbox.patch, #45514
    2018-11-23 pantxo StatusNone Confirmed
    2018-11-22 rik5 Carbon-Copy- Added pantxo

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code