bugGNU Octave - Bugs: bug #55485, Printing rotated text only works...

 
 

bug #55485: Printing rotated text only works for 90 degree increments with qt toolkit (regression)

Submitted by:  Rik <rik5>
Submitted on:  Wed 16 Jan 2019 03:37:21 AM UTC  
 
Category:  Plotting with OpenGL Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  5.0.1 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)

Thu 17 Jan 2019 04:29:39 PM UTC, comment #8: 

I pushed your patch here https://hg.savannah.gnu.org/hgweb/octave/rev/bf05a7c16e9e.

I had to make one small change and rename the warning ID to use a hyphen '-' instead of a space.  If the warning() function finds a space it assumes that the argument is text to be printed, rather than a warning ID.

warning ('Octave:print:unsupported-renderer',

This is fixed and I am closing the report.

Rik <rik5>
Project Administrator
Thu 17 Jan 2019 08:37:44 AM UTC, comment #7: 

Thanks Rik, I attached a patch.

(file #45991)

Pantxo Diribarne <pantxo>
Project Member
Thu 17 Jan 2019 02:51:00 AM UTC, comment #6: 

I agree.  FLTK doesn't need to be fully supported so just issuing a warning and using -painters instead would be fine.

If you want to detect rotated text, this code should work

ht = findall (gca, "type", "text");
angles = [get(ht, "rotation"){:}];
if (any (mod (angles, 90)))
  disp ("non-90 degree rotation");
endif

I put this code in a script find_90.m and then did

demo text 1
tic; find_90; toc

It takes about 35 milliseconds on my computer and this is with 112 text objects.  On an ordinary plot it is 10X faster.

plot (1:10, 'o-')
tic; find_90; toc
Elapsed time is 0.00353289 seconds.

So, I think you could put this in as a placeholder.

Eventually, and I think there is already a bug report on this, we would like to support rotated text onscreen and then WYSIWYG will be appropriate.

Rik <rik5>
Project Administrator
Wed 16 Jan 2019 10:42:03 PM UTC, comment #5: 

For this bug, haw about detecting the presence of rotated (non text objects (non 0-90-...) and eventually disable the -opengl render?

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 09:49:32 PM UTC, comment #4: 

Yes, I couldn't get the fltk toolkit to do well with the -opengl renderer, so I disabled it by default. It is mentioned in the NEWS file ("qt" toolkit only) but not in the help text.

For the time being I propose to issue a warning when -opengl option is used together with fltk, and use -painters instead.

Is it fine?

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 04:45:18 PM UTC, comment #3: 

To my first point, it seems that the fltk toolkit defaults to "-painters".  When I force it with '-opengl' it produces very ugly results.

Still, there is probably something that was not coded up in the fltk print routine because it should switch automatically between the two backends if the "RendererMode" property is "auto".  That, at least, would make the two OpenGl toolkits behave the same.

Rik <rik5>
Project Administrator
Wed 16 Jan 2019 04:38:03 PM UTC, comment #2: 

But why is it WYSIWYG only for the qt toolkit?  I thought fltk and qt both used the same backend for printing.

And if it is WYSIWYG, then why is it changing the appearance of dashed lines in "demo line 1".  Onscreen, the appearance is correct, but printed it is not (bug #55484).

Rik <rik5>
Project Administrator
Wed 16 Jan 2019 07:49:23 AM UTC, comment #1: 

It is possible to recover from this regression by using the "-painters" option when printing to raster formats. Octave now is WYSIWYG for raster outputs: what doesn't look right onscreen won't look better in png,jpg,tif...

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 03:37:21 AM UTC, original submission:  

Although text displayed onscreen with the OpenGl renderer can only take on the values 0, 90, 180, 270 degrees, the printing of text rotated to other angles has not been a problem.

With the latest tip on stable, however, this is no longer possible with the qt toolkit, but works fine with the fltk toolkit.

Sample code to reproduce:

demo text 1
print tst.png

Attached are pngs created with the qt and fltk toolkits which show the difference.

Rik <rik5>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45991:  opengl_textrot.patch added by pantxo (2KiB - text/x-patch)
file #45984:  text1.qt.png added by rik5 (67KiB - image/png)
file #45985:  text1.fltk.png added by rik5 (115KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-17 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2019-01-17 pantxo Attached File- => Added opengl_textrot.patch, #45991
        StatusConfirmed => Patch Submitted
    2019-01-16 rik5 Attached File- => Added text1.qt.png, #45984
        Attached File- => Added text1.fltk.png, #45985

    Back to the top


    Powered by Savane 3.5