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

 
 

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

Submitted by:  None
Submitted on:  Sun 04 Aug 2013 05:26:32 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: Originator Email: -unavailable-
Open/Closed: ClosedRelease: dev
Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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.

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>
Project 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>
Project 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

It seems to work fine.

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

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>
Project Administrator
Wed 25 Oct 2017 11:18:00 AM UTC, comment #23:

I had this test ran in ML:

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.

(file #42254)

Pantxo Diribarne <pantxo>
Project 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>
Project 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>
Project 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>
Project 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

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>
Project 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.

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:

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>
Project 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>
Project 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>
Project 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>
Project 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

Pantxo Diribarne <pantxo>
Project 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).

(file #42240, file #42241)

Pantxo Diribarne <pantxo>
Project 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

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>
Project 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>
Project 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.

Rik <rik5>
Project 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.

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>
Project Administrator
Mon 16 Oct 2017 06:33:26 PM UTC, comment #8:

Adding Rik to the recipients of this report.

Pantxo Diribarne <pantxo>
Project 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:

@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>
Project 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>
Project Member
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>
Project 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:

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>
Project 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>
Project Administrator
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 File(s):
   
   
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
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by pantxo
  • -unavailable- added by mmuetzel (Posted a comment)
  • -unavailable- added by pantxo (Updated the item)
  • -unavailable- added by atcl (Posted a comment)
  • -unavailable- added by hardy (Posted a comment)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 21 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 26 Oct 2017 01:12:40 AM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Wed 25 Oct 2017 09:45:55 PM UTCpantxoAttached File-=>Added txtback6.patch, #42260
      Attached File-=>Added axeslinelayer.patch, #42261
    Wed 25 Oct 2017 11:18:00 AM UTCpantxoAttached File-=>Added peaks_and_text.png, #42254
    Tue 24 Oct 2017 09:45:49 PM UTCpantxoAttached File-=>Added txtback5.patch, #42249
    Mon 23 Oct 2017 05:49:31 PM UTCpantxoAttached File-=>Added view90_85.png, #42240
      Attached File-=>Added view0_26.8.png, #42241
    Sun 22 Oct 2017 08:40:54 PM UTCpantxoAttached File-=>Added txtback4.patch, #42221
    Sat 21 Oct 2017 07:15:12 PM UTCrik5Attached File-=>Added txtback3.cset, #42215
    Mon 16 Oct 2017 06:33:26 PM UTCpantxoCarbon-Copy-=>Added -unavailable-
    Mon 16 Oct 2017 06:29:19 PM UTCpantxoAttached File-=>Added txtback2.patch, #42168
    Thu 12 Oct 2017 03:42:50 PM UTCpantxoAttached File-=>Added txtback.patch, #42127
      StatusConfirmed=>Patch Submitted
    Wed 14 Aug 2013 03:57:23 PM UTCbpabbottCategoryPlotting=>Plotting with OpenGL
      Summarytext(....\'backgroundcolor\',\'green\') has no effect=>text objects ignore backgroundcolor, linestyle, edgecolor
    Mon 05 Aug 2013 01:43:31 PM UTCmtmillerCategoryPlotting 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.1-cleanup1