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)

Submitter:  Rik <rik5>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

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>
Group administrator
Thu 17 Jan 2019 08:37:44 AM UTC, comment #7: 

Thanks Rik, I attached a patch.

(file #45991)

Pantxo Diribarne <pantxo>
Group 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");

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator


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

Attach Files:

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)

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