bugGNU Octave - Bugs: bug #39692, text objects ignore...

 
 

bug #39692: text objects ignore backgroundcolor, linestyle, edgecolor

Submitter:  None
Submitted:  Sun 04 Aug 2013 05:26:32 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
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

Thu 26 Oct 2017 11:55:32 AM UTC, comment #27: 

@Rik: many thanks for the thorough review work.

Shouldn't we leave this report open since gnuplot toolkit still does not support background area?
atcl in comment #4 provided a link to a so discussion about how to implement this in gnuplot 5.x

I also pushed the patch for the layer of axes lines since this is actually a regression from 4.2.1. See e.g. "demo hold 6" here https://josoansi.de/octave_plot_compare/compare_plot_demos_03.html#hold_06


Pantxo Diribarne <pantxo>
Group Member
Thu 26 Oct 2017 01:12:40 AM UTC, comment #26: 

I changed the code slightly to cache the results of glIsEnabled (GL_DEPTH_TEST).  I also added a note in the NEWS file about the excellent new capabilities.


 ** The properties "BackgroundColor", "EdgeColor", "LineStyle",
    "LineWidth", and "Margin" are now implemented for text objects using
    an OpenGL toolkit.


See http://hg.savannah.gnu.org/hgweb/octave/rev/730227072acb.

I'm going to close this report.  The other issue about axes overlap can be fixed, if necessary, when we have the results from Richard.


Rik <rik5>
Group administrator
Wed 25 Oct 2017 09:45:55 PM UTC, comment #25: 


>> For the margin property, Octave is always using pixels while Matlab is always using points. Maybe file another bug report about this minor incompatibility? That's a small issue and doesn't need to hold up resolving this bug report.


In fact "margin" will be interpreted in pixels onscreen but in points for printout (see bug #45600).
Currently freetype is setup so that "1 pixel = 1 point" (see bug #45600, we can't change this easily) and I chose to follow the same convention so that a 2 pixels margin is 20% the actual hight of a 10 "points" text.
We could document this somewhere but we would end up explaining some internal nasty intricate conventions that we hope (or will have) to change someday (see also bug #49627).

>> Does polygon offset need to be set for the lines as well as the background color patch?


No indeed. Attached is an updated patch.

>> Also, I went back to 2-D plots and the overlap with the axes.  ... Should this be another test case for Richard?


Since this is another matter, I'll send another request to not hold up Richard's licence :-). In any event the change is easy. See attached patch.

>> Finally, and there is a separate bug report about this, but could we use the glRotate code that you have here for the arbitrary rotation of text?


No. We currently we use glDrawPixels to directly dump pixels produced by freetype onto the screen. This  function use an independent raster coordinates system that is not affected by transformations (see e.g. https://stackoverflow.com/questions/223894/opengl-rotation-using-gldrawpixels#223920)
A solution could be to use textures to display pixels (or "texels") but it is way more work. Note that we already have a well hidden but functional implementation of textures on surface objects.

(file #42260, file #42261)

Pantxo Diribarne <pantxo>
Group Member
Wed 25 Oct 2017 04:20:02 PM UTC, comment #24: 

Seems good to me.

Is there an easy way to summarize the logic of what is shown and what is not shown?  That would help, and maybe should be put in the documentation.

For the margin property, Octave is always using pixels while Matlab is always using points.  Maybe file another bug report about this minor incompatibility?  That's a small issue and doesn't need to hold up resolving this bug report.

Does polygon offset need to be set for the lines as well as the background color patch?  I tried not using that bit of code with this patch


diff -r 5202841a0bb2 libinterp/corefcn/gl-render.cc
--- a/libinterp/corefcn/gl-render.cc        Sun Oct 15 21:06:47 2017 +0200
+++ b/libinterp/corefcn/gl-render.cc        Wed Oct 25 09:12:20 2017 -0700
@@ -3536,14 +3536,16 @@ namespace octave
         glVertex2d (x1, y1);
         glVertex2d (x0, y1);
         glEnd ();
+
+        set_polygon_offset (false);
       }

     if (! ecol.isempty ())
       {
         glColor3f (ecol(0), ecol(1), ecol(2));

-        if (glIsEnabled (GL_DEPTH_TEST))
-          set_polygon_offset (true, 0);
+//        if (glIsEnabled (GL_DEPTH_TEST))
+//          set_polygon_offset (true, 0);

         set_linestyle (props.get_linestyle (), false, props.get_linewidth ());
         set_linewidth (props.get_linewidth ());
@@ -3557,7 +3559,7 @@ namespace octave
         glEnd ();
       }

-    set_polygon_offset (false);
+//    set_polygon_offset (false);

     // Restore previous coordinate system
     glPopMatrix();


It seems to work fine.

Also, I went back to 2-D plots and the overlap with the axes.


clf;
ht = text (0.5, 0.5, 'Hello World', 'backgroundcolor', 'r', 'margin', 20, 'fontsize', 20, 'linewidth', 5, 'edgecolor', 'g')
ht2 = text (0.6, 0.6, 'Goodbye World', 'backgroundcolor', 'b', 'margin', 20, 'fontsize', 20, 'linewidth', 5, 'edgecolor', 'k')
axis ([0.076037   1.076037   0.446976   1.446976])
## At this point, text background overlaps ticks and ticklabels
set (gca, 'layer', 'top')
## At this point, axes object ticks and ticklabels are in front
## However, axes line objects are not on top.  This seems to be a bug
## in how the axes backplane is drawn.


It seems like there is still some work to do, but I would like confirmation from Matlab?  Should this be another test case for Richard?

Finally, and there is a separate bug report about this, but could we use the glRotate code that you have here for the arbitrary rotation of text?  It's been a longstanding issue that text onscreen is limited to 0, 90, 180, and 270 degree rotations, even though it can print correctly for any angle.



Rik <rik5>
Group administrator
Wed 25 Oct 2017 11:18:00 AM UTC, comment #23: 

I had this test ran in ML:


clf
peaks ();
for p = -3:3
  text (p, p, p, 'toto', 'backgroundcolor', 'r', 'margin', 20);
end
drawnow ()
c = getframe (gcf);
imwrite (c.cdata, 'peaks_and_text.png');


and the resulting png is attached. As I said on the mailing list, this probably means that ML draws this axes in 3 stages, between which the depth buffer is cleared so that subsequent objects are drawn on top of previous ones, regardless of their actual position in space. See http://octave.1599824.n4.nabble.com/Request-for-a-test-in-Matlab-td4685352.html

My conclusion is that the latest version of the patch produces less visual artifacts than Matlab implementation so I'd like to go on with that strategy.


Pantxo Diribarne <pantxo>
Group Member
Wed 25 Oct 2017 08:31:09 AM UTC, comment #22: 

In Matlab text anchor position seams to be respected ([0.5 0.5 0.0]) but the background is drawn as if the position was [0.5 0.0 0.0], or most probably as if the depth testing had been disabled.

Disabling the depth test for both the text and the background eliminates the problem of polygon_offset, but also produces weird looking plots. I asked for an additional test about this.

Pantxo Diribarne <pantxo>
Group Member
Wed 25 Oct 2017 12:32:26 AM UTC, comment #21: 

Matlab seems to produce compatible output from the pictures posted to the Octave-Maintainers mailing list.  One thing I noticed was that the lines and tick marks for the axes are always in front of the text object.  I don't know if we need to try and copy that behavior or not.  It might relate to the "layer" property of the axes.  But if the "layer" is set to bottom, then the text object should obscure the axes object.  The patch seems like a vast improvement on what we have now.

Rik <rik5>
Group administrator
Tue 24 Oct 2017 09:45:49 PM UTC, comment #20: 

I updated the patch to handle clipping for the background area as well. I also posted a request on the mailing list  to have he code from comment #14 ran in Matlab.

(file #42249)

Pantxo Diribarne <pantxo>
Group Member
Tue 24 Oct 2017 03:50:55 PM UTC, comment #19: 

@Pantxo: You are right.  I set clipping to "on" for the axes object and I thought that would take precedence, but one does have to set it on every object for which it should apply.

I can verify that


clf
ht = text (.5, .5, 'toto', "backgroundcolor", "r");  # background visible
pause (1);
set (ht, "clipping", "on");                          # background invisible


We might need to put a request in on the Octave-Help or Octave-Maintainer's list to run the test code in Matlab because I'm not sure that anyone following this bug report has access to it.

Rik <rik5>
Group administrator
Tue 24 Oct 2017 11:19:13 AM UTC, comment #18: 

@Rik: clipping does work for text objects, it is simply set to "off" by default.


clf
ht = text (.5, 1.05, 'toto'); ## the text is visible even if outside the axes limits
set (ht, "clipping", "on"); ## the text is now invisible/clipped


The problem with the patch I provided is that the background area disappears as long as "clipping" is set "on", even when the text is (unambiguously) inside the axes:


clf
ht = text (.5, .5, 'toto', "backgroundcolor", "r");
set (ht, "clipping", "on"); ## the text is still there as expected but the background disappeared


I will check how clipping is handled for markers and report back here.

In any event it would be good to have someone test this in Matlab

Pantxo Diribarne <pantxo>
Group Member
Mon 23 Oct 2017 11:08:22 PM UTC, comment #17: 

Clipping works for the surface object, but not for the text object.  That seems to have been a problem before this patch.  It should be fixed, but it can be the subject of a different bug report.

Rik <rik5>
Group administrator
Mon 23 Oct 2017 11:04:02 PM UTC, comment #16: 

@Pantxo: I see the same results on-screen as you do in comment #13.  If this is what it is supposed to look like, even in Matlab, then that is fine and we can check this patch in.

Rik <rik5>
Group administrator
Mon 23 Oct 2017 10:22:52 PM UTC, comment #15: 

Actually clipping does not work at all, wether the text background crosses the border or not it is clipped.

Pantxo Diribarne <pantxo>
Group Member
Mon 23 Oct 2017 06:11:58 PM UTC, comment #14: 

If someone tests those cases could she/he also try with clipping enabled. With the current patch, setting "clipping" to "on" makes the background disappear entirely since it crosses the border while the text does not. Here is the updated test case


clf
set (gca, 'color', 'b');
ht = text (.5, .5, 'toto', 'backgroundcolor', 'r', 'margin', 20);
xlim ([0 3])
ylim ([0 3])
surface ();
view (90, 35);
drawnow
c = getframe (gcf);
imwrite (c.cdata, "view_90_35.png");
view (0, 26.8)
drawnow
c = getframe (gcf);
imwrite (c.cdata, "view_0_26.8.png");
set (ht, "clipping", "on")
drawnow
c = getframe (gcf);
imwrite (c.cdata, "view_0_26.8_clipping.png");


Pantxo Diribarne <pantxo>
Group Member
Mon 23 Oct 2017 05:49:31 PM UTC, comment #13: 

@Rik: can you describe what you observe (and eventually add a screenshot). On my system I obtain the attached figures (obtained using getframe):

  • view (90, 35): part of the text background is hidden because it traverses the axes plane
  • view (0,26.8): again part of the text background traverses the axes plane but this time the lower part is visible (due to the small  elevation).








Pantxo Diribarne <pantxo>
Group Member
Mon 23 Oct 2017 03:46:33 PM UTC, comment #12: 

There is definitely still some weirdness going on, but I'm not sure whether we want to deal with it.  I see two choices.  First, we could try and find a solution that works, provably, for all situations.  This might mean giving up the current strategy based on polygon_offset and going back to loking at the ordering of drawing objects.  Or, we could acknowledge that the code works for 90% of cases, but that some corner cases are always going to have problems.

It seems that tuning the margin can cause problems with whether the axes background patch or the text background patch are in the foreground.

With txtback4.patch applied, I used this code


clf
set (gca, 'color', 'b');
ht = text (.5, .5, 'toto', 'backgroundcolor', 'r', 'margin', 20);
xlim ([0 3])
ylim ([0 3])
surface ();
view (90, 35)
#view (0, 26.8)  # This produces another odd view


Maybe it is worth checking in Matlab to see what the code above does?  It could be that their patch object also is modified in size depending on the viewing angle.


Rik <rik5>
Group administrator
Sun 22 Oct 2017 08:40:54 PM UTC, comment #11: 

@Rik: thanks for the review. Indeed I had not noticed the misbehavior of rotation as "demo text 2" seemingly worked. I could also check that those settings (9 for axces, 4 for text background) make flickering disappear for me. I attached a patch updated from your verion with the "-" sign fixed.



(file #42221)

Pantxo Diribarne <pantxo>
Group Member
Sat 21 Oct 2017 08:21:39 PM UTC, comment #10: 

Changing the glRotated command to use the negative Z-axis fixes the printed rotation issue for me.


      glRotated (rotation, 0.0, 0.0, -1.0);



Rik <rik5>
Group administrator
Sat 21 Oct 2017 07:15:12 PM UTC, comment #9: 

I was not aware of this report.  The polygon offset is very finicky and the correct value has to be determined experimentally.  I used the code from Pantxo in comment #7 as my test vehicle.  On my system, pushing the polygon to offset 4 and the axes background to offset 9 seems to work.  I also modified the help text for background color slightly.  I've attached txtback3.cset as the next version of a patch for testing.

Currently, there seems to be a problem with text rotation and printing of 2-D plots.  The following code shows the problem.


clf
ht = text (0.5, 0.5, "Hello World", "backgroundcolor", 'r', "rotation", 45)
print tst.svg


In the output, the text is correctly rotated, but the background patch is rotated in the opposite direction, i.e., -45 degrees.  That should be simple to fix.


(file #42215)

Rik <rik5>
Group administrator
Mon 16 Oct 2017 06:33:26 PM UTC, comment #8: 

Adding Rik to the recipients of this report.

Pantxo Diribarne <pantxo>
Group Member
Mon 16 Oct 2017 06:29:19 PM UTC, comment #7: 

@Markus: thanks for testing. Indeed I saw the flickering but though it was not an issue sine the text always seamed to end up on top of the area when I stopped moving the view.
Since then I tested again and there are some cases where the text ends up covered by the background (at least in printout). Pushing the offset to 8 is currently not enough since the axes background is at 2.5 (see failing example below).

I attached an updated version (cleaned up) of the patch with offset set to 8. With this patch the example below will still fail:


clf
## The following works as expected because pure 2D axes are
## rendered sequentially
text (.5, .5, "toto", "backgroundcolor", "r")
xlim ([0 3])
ylim ([0 3])
## Now add a 3D object in the 2D scene.
surface ();
## The objects are now rendered sorted by depth and the text
## background is hidden by the axes background


@Rik: I think you are the one who originally set those offset numbers right. Do you think we can safely push the axes background to e.g. 9?

(file #42168)

Pantxo Diribarne <pantxo>
Group Member
Sat 14 Oct 2017 02:33:20 PM UTC, comment #6: 

I compiled with your patch and tested it with "demo text 2". It seems to work fine: The text background is displayed and the printed figure also includes all rotation angle.
However, the text sometimes disappears (behind the text background?) when manually rotating the axes. Increasing the polygon offset for the background quad to 8, removes the flickering in that demo for me. (It still disappears intermittently while rotating with 7 for me.)

Markus Mützel <mmuetzel>
Group administrator
Thu 12 Oct 2017 03:42:50 PM UTC, comment #5: 

I attached a cset that handles text background area for opengl toolkits only. AFAICS printing works correctly also (even better since all rotation angles work).

(file #42127)

Pantxo Diribarne <pantxo>
Group Member
Mon 05 Jun 2017 11:26:18 PM UTC, comment #4: 

I wanted to ask about the state of this issue and if this may help fixing it: https://stackoverflow.com/a/32600654

Thank you

CH <atcl>
Tue 22 Nov 2016 09:14:55 PM UTC, comment #3: 

This feature is still missing in Octave 4.2.0.

Here is a small script to easily reproduce the behavior:


graphics_toolkit qt % or fltk
close all
text(0.5, 0.5, 'my text', 'backgroundcolor', 'green', 'edgecolor', [0,0,0])


Currently this results is no green area behind the text, nor any kind of warning.

Hartmut <hardy>
Wed 14 Aug 2013 03:57:23 PM UTC, comment #2: 

Gnuplot doesn't support placing text in a box.  And since we don't have access to the font metrics used by Gnuplot, I think that falls in to the "won't fix".

However, we do need to include this functionality for the OpenGL  toolkits.  So, I'm changing the category to "Plotting with OpenGL".

Ben Abbott <bpabbott>
Group Member
Mon 05 Aug 2013 01:43:31 PM UTC, comment #1: 

Confirmed, the backgroundcolor and edgecolor properties have no effect on text objects, with either gnuplot or OpenGL plotting.

Mike Miller <mtmiller>
Group Member
Sun 04 Aug 2013 05:26:32 PM UTC, original submission:  

Hi,

text(10,20,output,'backgroundcolor','green','edgecolor',[0,0,0]) takes no effekt on the plot. There is still no background and no edge around the text i saved as output.

How can i get a box around the text field, with a backgroundcolor and an edgecolor? like matlab does

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #42260:  txtback6.patch added by pantxo (8KiB - text/x-patch)
file #42261:  axeslinelayer.patch added by pantxo (1KiB - text/x-patch)
file #42254:  peaks_and_text.png added by pantxo (79KiB - image/png)
file #42249:  txtback5.patch added by pantxo (8KiB - text/x-patch)
file #42240:  view90_85.png added by pantxo (11KiB - image/png)
file #42241:  view0_26.8.png added by pantxo (11KiB - image/png)
file #42221:  txtback4.patch added by pantxo (8KiB - text/x-patch)
file #42215:  txtback3.cset added by rik5 (8KiB - application/octet-stream)
file #42168:  txtback2.patch added by pantxo (8KiB - text/x-patch)
file #42127:  txtback.patch added by pantxo (7KiB - 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 rik5 (Updated the item)
  • -email is unavailable- added by pantxo
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by atcl (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  •  

    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 21 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-26 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2017-10-25 pantxo Attached File- Added txtback6.patch, #42260
        Attached File- Added axeslinelayer.patch, #42261
    2017-10-25 pantxo Attached File- Added peaks_and_text.png, #42254
    2017-10-24 pantxo Attached File- Added txtback5.patch, #42249
    2017-10-23 pantxo Attached File- Added view90_85.png, #42240
        Attached File- Added view0_26.8.png, #42241
    2017-10-22 pantxo Attached File- Added txtback4.patch, #42221
    2017-10-21 rik5 Attached File- Added txtback3.cset, #42215
    2017-10-16 pantxo Carbon-Copy- Added -email is unavailable-
    2017-10-16 pantxo Attached File- Added txtback2.patch, #42168
    2017-10-12 pantxo Attached File- Added txtback.patch, #42127
        StatusConfirmed Patch Submitted
    2013-08-14 bpabbott CategoryPlotting Plotting with OpenGL
        Summarytext(....\'backgroundcolor\',\'green\') has no effect text objects ignore backgroundcolor, linestyle, edgecolor
    2013-08-05 mtmiller CategoryPlotting with gnuplot Plotting
        StatusNone Confirmed
        Release3.4.2 dev
        Operating SystemGNU/Linux Any
        Summarytext(....\'backgroundcolor\',\'green\') takes no effekt text(....'backgroundcolor','green') has no effect

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code