bugGNU Octave - Bugs: bug #31468, Printing of multi-line text...


bug #31468: Printing of multi-line text objects (OpenGL)

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Tue 26 Oct 2010 02:56:59 PM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Ben Abbott Open/Closed:  Closed
Release:  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)

Wed 14 Oct 2015 09:39:25 PM UTC, comment #74:

I pushed the patches here:


Closing report.

Pantxo Diribarne <pantxo>
Project Member
Sun 11 Oct 2015 02:36:08 PM UTC, comment #73:

@Panxto: I think you can go ahead and start committing some of these patches. From the e-mails I get from the bug tracker I see that you have perhaps 3 different bugs which are all interrelated to the same issues. My feeling is that this is working well enough that you can commit it to the development branch, and then refine it from there.

Rik <rik5>
Project Administrator
Sun 11 Oct 2015 12:46:58 PM UTC, comment #72:

@Rik: some more info on comment #69 items:
1) If you change the second axes position, e.g. swap subplot(222) and subplot(221), the texts are no more partly hidden behind the background. The problem is that currently all axes are treated in gl2ps as a single depth tree, which leads to those unexpected results after primitive sorting. Fixing bug #44765 also fixes the hidden characters here.

2) The patch I provided splits parsed string and places them by hand in gl2ps. The critical part of it is the position of strings as computed using freetype in Octave: they must be consistent with what external renderers will produce. My understanding is that there are two issues here:

  • freetype is used to produce pixel outputs: we thus approximate (integer divisions) the size of type faces to produce digits.
  • mismatch between Octave (fontconfig) replacement for Helvetica font and what other renderers choose: a possible solution to this is keep track of the actual rendered fonts in Octave, replace the font name in gl2ps EPS output and later use ghostscript to embed the actual font and convert to any format we like (including EPS).
Pantxo Diribarne <pantxo>
Project Member
Tue 29 Sep 2015 09:45:10 PM UTC, comment #71:

@Pantxo: Thanks for the explanation of item 3. I think you're right that using the Symbol font is the best way forward.

Rik <rik5>
Project Administrator
Tue 29 Sep 2015 09:33:05 PM UTC, comment #70:

1) No this is not a problem with your version of gl2ps, I also see hidden texts with the current dev version of gl2ps. I will dig into it.

2) I have to dig into this to.

3) gl2ps doesn't handle any characters out of the standard ascii 127 characters. The UTF-8 characters we use to represent Tex symbols simply can't be included using gl2ps except with svg terminal. That's why I chose this dirty solution, replacing Tex characters with their counterpart in the symbol font for eps/pdf output.
I think the warnings you are talking about are those Octave sends when a specific character is absent from the font fontconfig chose, and can't be rendered on-screen.
In this situation the printout currently ends up with overlapping symbols ... to be cleaned.

Pantxo Diribarne <pantxo>
Project Member
Tue 29 Sep 2015 04:03:55 PM UTC, comment #69:

This looks like a good improvment. I particularly like the superscripts on the log axis ticks.

As you are polishing up the changeset I would look at a few things:

1) There appears to be a blank tesselation triangle obscuring some of the Greek letters. This may be a bug with my version of gl2ps (1.3.6-1). I've attached an image of it so you can see what I mean.

2) There seems to be extra space in the output around the italicized and bolded text. I tried moving the space outside the italics declaration as shown below, but it didn't help.

{\\fontsize{15}large} and {\\color{red}coloured} texts")

3) I think eventually we would like to stay within the fontname chosen even for TeX symbols, rather than switching over to Symbol. Right now I believe we do that and issue a warning when the fontset does not include the proper glyph. On the other hand, Matlab always switches over to Symbol as far as I can tell so we will at least be compatible.

(file #35011)

Rik <rik5>
Project Administrator
Sat 26 Sep 2015 11:28:32 AM UTC, comment #68:

I forgot the teaser :-) see attached eps and svg with the original script.

(file #34987, file #34988)

Pantxo Diribarne <pantxo>
Project Member
Sat 26 Sep 2015 11:06:13 AM UTC, comment #67:

I have worked out a series of patches in order to have multi line support in printed images also. The 3 attached patches still have to be polished and the change log is still missing, but it works as follows:

  • txt-eng-ft:

When parsing the string using freetype (text_to_pixels), the position and other font style informations are stored in a list of ftstring class objects. Those objects represent a string segment with homogeneous font properties, e.g parsing "This_{string}" will result in a list of 2 ftstrings, one for "This" and one for "string". When tex symbols are present, their utf8 code is also stored.
The list of parsed strings can be retrieved using a new method "text_to_strlist" that has the same interface as "text_to_pixels" but retruns the list instead of a pixel array.
Note: The ftstring class capabilities currently overlap with ft_face class so I should polish that and make one overload the other.

  • gl-render:

Add "text_to_strlist" method (see above).
Add a method "fix_strlist_position" to align the ftstring list using the current graphics_tranform (Note: this could be a gl2ps-renderer only method).

  • gl2ps-renderer:

Retrieve the ftstring list and decide what to do with it:
-if the list has only one element and no tex symbol, let gl2ps align the string (this what we currently do)
-else: each string segment is translated/rotated as necessary and then printed using gl2ps. Tex symbols are replaced by their counterpart in the "Symbol" font except when printing to svg which has built-in utf8 support.

I ran dump_plot_demos.m with fltk and compared the figures using those patches or 4.0 and I didn't see any obvious regression.

As symbols in the "Symbol" font don't have the exact same size as the original ones, the alignment is often not righ.
As fontconfig (in Octave) doesn't generally pick the same replacement font for Times and Helvetica as pdf renderers (I tried Okular and Evince), there are also some sligh alignement issues. This could be solved in the future by replacing Times/Helvetica font, in gl2ps output, by the one fontconfig has picked and then embeding the font using ghostscript (see e.g. in R [1]).

Well now I'd like to have comments on the approach before I start polishing. Can some of you test the patches please? See file names for the order in which you have to apply the patches.

[1] http://stat.ethz.ch/R-manual/R-patched/library/grDevices/html/embedFonts.html

(file #34984, file #34985, file #34986)

Pantxo Diribarne <pantxo>
Project Member
Sun 08 Mar 2015 10:09:23 PM UTC, comment #66:

Rik must have meant that it worked on-screen; that works fine since Sept. 2011.
At the time of comment #57 printing wasn't yet in the picture (no pun intended :-) )

Printing multi-line objects doesn't work, also not in Qt (just tried on Windows with .png and 'title ({"Line 1", "Line 2"})'.

Changing bug title "FLTK"->"OpenGL"

Philip Nienhuis <philipnienhuis>
Project Member
Sun 08 Mar 2015 03:00:10 PM UTC, comment #65:

Confirmed here on Linux also. Rik claimed in comment #57 that this was working at one point on Linux, but it now apparently does not, with either FLTK or Qt plotting (tested both 3.8.2 and current development version). Updating OS to any.

Mike Miller <mtmiller>
Project Administrator
Sun 08 Mar 2015 12:09:31 PM UTC, comment #64:

@Philiip (comment 62)
I have tried some of the examples. It seems that
breaking line works in plotting data, but (I did not notice
it when I asked my question), not in printing, so this is still a valid bug report.

Avinoam Kalma <avinoam>
Project Member
Thu 05 Mar 2015 07:46:44 PM UTC, comment #63:

I tried the example in comment #49
and the file looks different than the figure.

Doug Stewart <dastew>
Thu 05 Mar 2015 06:56:37 PM UTC, comment #62:

Have you tried yourself and did it work OK?

Philip Nienhuis <philipnienhuis>
Project Member
Thu 05 Mar 2015 02:21:29 PM UTC, comment #61:

Is this bug report still valid?

Avinoam Kalma <avinoam>
Project Member
Wed 28 Sep 2011 08:54:42 PM UTC, comment #60:

I'm re-titling this report to accurately reflect the remaining issue of printing multi-line text objects with the FLTK toolkit.

Rik <rik5>
Project Administrator
Wed 28 Sep 2011 08:34:53 PM UTC, comment #59:

I updated my sources and all the dependencies. Today the FLTK renders the multi-line text objects correctly for me (I'm guessing my recent update to FLTK from MacPorts fixed this).

Perhaps the summary should be changed to indicate the problem is with printing/gl2ps output?

Ben Abbott <bpabbott>
Project Member
Wed 28 Sep 2011 07:33:29 PM UTC, comment #58:

Hi Rik,

I got an email reply for this thread, so I figured I'd chime in:

  • mangled TrueType rendering for Mac OS X in txt-eng-ft.cc. I believe Ben's image captures it in file #23826, versus file #23823.

I can't add much to this since I don't have OS X environment to test with, but maybe checking some of the return values for the FreeType calls in txt-eng-ft.cc would be a good place to start.

  • lack of multi-line support in print/gl2ps plots because gl2psTextOpt() does not parse newlines.

I was working on an experimental patch that used the TrueType rendered pixels in txt-eng-ft.cc instead of gl2psTextOpt(), since they already took into account the alignment (left, center, right). The patch for this is file #23814, a sample output image is #23815, and the test code in the second half of comment #49. The output looked good, except for a position offset that I haven't had time to track down. If that offset is taken care of, print/gl2ps plots would have the same multi-line rendering as the FLTK/OpenGL frontend (same pixels). The resolution could be better, though.


Vanya Sergeev <vsergeev>
Wed 28 Sep 2011 07:14:29 PM UTC, comment #57:

Ben, this bug has quite a few comments. Is it localized now to multi-line text objects with FLTK on Mac OS platforms only?

I tried multi-line text on Linux with the FLTK toolkit and it is working fine as of 9/28/2011.

Rik <rik5>
Project Administrator
Wed 17 Aug 2011 03:39:51 PM UTC, comment #56:

I've run the test and attached both pixels.rgba and pixels.png.

The latter looks mangled on my Mac.

(file #23825, file #23826)

Ben Abbott <bpabbott>
Project Member
Wed 17 Aug 2011 03:22:23 AM UTC, comment #55:

Hi Ben,

Please disregard my last "txt_eng_ft_rendering.patch" patch (file #23813), for some reason I'm not seeing negative xoffset+face->glyph->bitmap_left at all anymore... Not sure what changed.

Attached is the test patch. Here is a sample run:

It will make pixels.rgba, and then just run the command it gives you (assuming you have imagemagick installed) to make pixels.png.

Attached is my pixels.png as my_pixels_test.png.


(file #23822, file #23823)

Vanya Sergeev <vsergeev>
Tue 16 Aug 2011 10:10:48 PM UTC, comment #54:

I'm happy to accept your offer to write some code to test TrueType.


Ben Abbott <bpabbott>
Project Member
Tue 16 Aug 2011 10:06:47 PM UTC, comment #53:

Hi Ben,

I'm being verbose here to make sure I've got this right, please forgive my detail if this is obvious and feel free to correct me.

My understanding is that FLTK just gives you the window, buttons, hooks for mouse events, and most importantly is simply a container for an OpenGL context that you can render to. Then you can use OpenGL methods like glBitmap/glDrawPixels/glVertex*/etc. to create structures and ultimately render them in your OpenGL area in the FLTK window. (gl-render.cc)

gl2ps is similar in that it gives you an OpenGL mimicing & compatible interface (e.g. gl2psDrawPixels with identical arguments to glDrawPixels), so it can work with the same OpenGL structures that you've created and rendered somewhere else with OpenGL, but gl2ps instead renders them to a file in file formats it supports like eps, pdf, svg, ps, etc. The similarity and compatibility in interface make it easy to support rendering to a file for an OpenGL application. It has nothing to do with FLTK, though. (gl2ps-renderer.cc)

The third player relevant here is FreeType, the font engine. After initializing it with relevant parameters like font, size, etc., it will accept characters and gives you back bitmaps that you can render with something like glDrawPixels or gl2psDrawPixels. (txt-eng-ft.cc)

Unless things are different in the Mac OS X version, the plot text in the FLTK/OpenGL GUI should be rendered with just FreeType and OpenGL...

Currently, the print/gl2ps draws text by passing the raw text string directly to gl2psTextOpt(), but this function doesn't interpret any kind of newline, which makes rendering multi-lines with it an open ended question. The experimental patch substitutes gl2psTextOpt() for gl2psDrawPixels(), and instead draws rendered FreeType pixels (just like for the FLTK/OpenGL GUI), which already account for multi-lines in txt-eng-ft.cc.

For your Mac OS X problem, though, if it's mangled in both FLTK/OpenGL and print/gl2ps, it might be worth it to check out the pixels rendered by FreeType, and make sure there is no problem there. If you'd like, I could write a piece of code later today to export these pixels so you can check them out independently of the OpenGL / gl2ps business, to make sure they're okay...


Vanya Sergeev <vsergeev>
Tue 16 Aug 2011 08:49:23 PM UTC, comment #52:

Some time in the last couple of months, either an update to MacOS X or an update to Fink FLTK libs resulted all the FLTK text in GUI being mangled (I see this on more than one computer).

Do I understand you correctly that FLTK has not part in the printed output? If so, then I think it safe to assume it is Apple's OpenGL that changed.

Ben Abbott <bpabbott>
Project Member
Tue 16 Aug 2011 08:41:45 PM UTC, comment #51:

Hi Ben,

The gl2ps patch is just currently an experiment, but this is interesting to see. Just so I'm on the same page here, these attached PDFs are print() outputs? How does the text look in the FLTK GUI itself?

For communication purposes here, it might be worth it to distinguish the two as FLTK/OpenGL and print/gl2ps, because the rendering code invoked for both is similar but different and separate (both for example, have a distinct draw_text(), and the experimental patch is implementing the print/gl2ps renderer's draw_text() similar to the FLTK/OpenGL renderer draw_text()).


Vanya Sergeev <vsergeev>
Tue 16 Aug 2011 08:23:19 PM UTC, comment #50:

I ran demo("text",4) and saved the result with the default branch's tip (12973:b80b18f537ca) and with the experimental gl2ps patch.

I'm seeing a strange result with FLTK on MacOS. Note, presently all the text displayed for me using the FLTK backend is mangled, but before the gl2ps patch, the printed output has been clean.

I've attached a pair of pdfs.

(file #23819, file #23820)

Ben Abbott <bpabbott>
Project Member
Tue 16 Aug 2011 02:17:28 PM UTC, comment #49:

Attached is an additional fix, this time as a mercurial patch txt_eng_ft_rendering.patch:

More pixel accurate opengl multi-line text alignment, and fixed previously out-of-bounds unrendered pixels.

txt-eng-ft.cc: Accounted for the face->glyph->bitmap_left x offset in both rendering and bounding box mode, which was previously ignored and occasionally led to scrunched characters (bitmap_left < 0 -> x0 = 0) or a column of missing pixels (bitmap_left > 0 -> ignored out of bounds pixels). Added comments explaining some of the glyph rendering code.

To see an example of the difference, render "world" with the old code versus the new code, you'll notice "wo" are a scrunched up with the old version, and render properly with the new version.


Also attached is an experimental patch for gl2ps rendering of the TrueType rendered pixels for the multi-line text labels. Currently the xlabel and ylabels are offset from their correct position. Perhaps pos(0),pos(1),pos(2) need to be adjusted with the pixels bbox size. But I need to look into the internal methods for converting the bbox matrix into the units used in gl2ps rendering. I'm also unsure if this is a desired feature (using the rendered pixels). I was thinking that if LaTeX rendering ever comes to the opengl backend, using the rendered pixel array would give it for free to the gl2ps converter. An alternative for now is also spacing multiple separate gl2psTextOpt() labels, but I imagine things might messy when things like rotation need to be implemented.

Here is a test demonstrating the rendered pixels and xlabel/ylabel offset:

Rendered gl2ps_ft_render_pixels_test.png is attached.


(file #23813, file #23814, file #23815)

Vanya Sergeev <vsergeev>
Mon 15 Aug 2011 10:58:38 PM UTC, comment #48:


Yup, that's true. gl2psTextOpt() doesn't handle newlines at all in the text string. I'm working on an experimental patch for the gl2ps rendering to use the pixels array as rendered with ft_render (mentioned in comment #28). Right now it renders the pixels array, but the xlabel position is offset too high.


Vanya Sergeev <vsergeev>
Mon 15 Aug 2011 10:48:31 PM UTC, comment #47:

With tip


The printed output for FLTK doesn't handle multiple lines correctly. I've attached the pdf produced by the commands below.

(file #23812)

Ben Abbott <bpabbott>
Project Member
Mon 15 Aug 2011 09:50:00 PM UTC, comment #46:


I tested your patch. I didn't see any problems with the rendering, so I pushed it.


Ben Abbott <bpabbott>
Project Member
Mon 15 Aug 2011 06:46:09 PM UTC, comment #45:

Attached is a patch for txt-eng-ft.cc and txt-eng-ft.h, to add center, right, and left alignments to the fltk/opengl multi-line text labels. It uses the same horizontal alignment specified by "halign" passed to text_to_pixels(). It can be applied on top of my previous txt-eng-ft.cc modifications ( which I understand are now in the recent hg changeset 22bc9ec80c2c ).

Currently, the horizontal alignment "halign" parameter also moves the whole pixel box to the left, center, or right (see the halign switch () in text_to_pixels() ), so things look a little bit unnatural at the moment for left and right alignments, e.g. for a "right alignment" halign, the entire label is moved to the right, in addition to the multi-lines being right-aligned. Things do look natural if the pixel box is anchored in the center (switch (halign) -> switch (1) in text_to_pixels() to test), and only the multi-line text is responsible for changes in alignment. But I'm not sure whose alignment "halign" is precisely supposed to describe.


(file #23810)

Vanya Sergeev <vsergeev>
Mon 15 Aug 2011 04:47:26 PM UTC, comment #44:

Thanks for checking in the sources. Everything looks to be working correctly.

I'll do more testing before you return next week.

Ben Abbott <bpabbott>
Project Member
Mon 15 Aug 2011 02:35:04 PM UTC, comment #43:

The changeset I checked in is:


I credited you with the change since I think most of the work was yours and I just made a few changes to adapt to my addition of the text_label_property object in my previous changeset.

John W. Eaton <jwe>
Project Administrator
Mon 15 Aug 2011 02:33:08 PM UTC, comment #42:

Ben, I checked in an additional change that should fix the problem you are seeing. To make it work, I had to make most of the changes from your earlier file #23799: multiline_text_for_gnuplot.patch, so rather than split that up, I just included all of it with my changes.

I'm not sure that the code in the text function is completely right at this point, but the demos seem to work. For example, I'm wondering whether the conversion to cellstr objects from char objects is correct now.

I noticed that you were working on the stable branch, but I think these changes are too invasive for that, so I put them on the default branch.

Let me know if you see any problems. I won't be able to look at this again for a week, but if there is something else I need to do, I'll try to take care of it promptly then.

John W. Eaton <jwe>
Project Administrator
Sun 14 Aug 2011 08:35:16 PM UTC, comment #41:

John with your change (0c86ae6f7c34 ) and none of the related patches I did some tests using the script below.

The Matlab result is below.

Except for the first test, Octave gives a different result.

You mentioned the changes needed aren't complete. Is this what you were referring to?

Ben Abbott <bpabbott>
Project Member
Sun 14 Aug 2011 04:40:22 PM UTC, comment #40:

I checked in the following change.


I don't think it is complete, but it is a start. Specifically, I think the get_string function should return a string_vector object, but this will require changes to any code that currently uses the string property and assumes that the get_string method returns a std::string object.

Ben, I recommend that you apply the attached patch "extra-text-diffs.txt" so that text.m will allow labels to be specified with numeric values. This is in addition to your most recent patch, which I did not apply. It also eliminates some duplicate logic.

Let me know if there are problems with my changes.

(file #23800)

John W. Eaton <jwe>
Project Administrator
Sun 14 Aug 2011 02:24:13 AM UTC, comment #39:

the {x,y,z}label objects are text objects. I think it is sufficient that their "string" property be of the new class.

AFAIK, the only properties that need the new class are text.string and axes.{x,y.z}ticklabels

With ML, the passing (1:2) to title(), xlabel(), ylabel(), and zlabel() produces 2 lines with "1" and "2". The string property value for these text objects is ["1";"2"]. Passing {1,"2"} produces the same visual result. In this case the string is a cellstr with the value is {"1", "2"}.

Ben Abbott <bpabbott>
Project Member
Sun 14 Aug 2011 02:13:48 AM UTC, comment #38:

Do all of these label objects ({x,y,z}ticklabel, text, title, any others? What about {x,y,z}label?) work the same way in Matlab with respect to the data they accept and the appaerent representation as either char or cellstr? For example, can you pass a numeric array or a cell array of numbers to title the same as you can text?

I can probably write the class. I might be able to have a first draft by tomorrow. If I can't do it by Monday, it will be at least another week before I can do it.

John W. Eaton <jwe>
Project Administrator
Sat 13 Aug 2011 09:34:24 PM UTC, comment #37:

The any_property class is currently used for the properties userdata, xticklabel, yticklabel, zticklabel, string, and _plot_stream_. I agree it desired that a new class be used for xticklabel, yticklabel, zticklabel, and string. Calling it text_label_property sounds good to me.

I ran some tests in Matlab for reference.

John, may I assume you'll take care of the new text_label_property for us?

Ben Abbott <bpabbott>
Project Member
Sat 13 Aug 2011 07:59:26 PM UTC, comment #36:

You changed the "string" property of the text object to be any_property. I'd rather not do that, since then it could be possible for this property to be incorrectly constructed and contain things that the rendering code is not expecting.

I'm not sure what would be most convenient, but I think the string property should use some other type of property object that more closely models what is going on here. The object should only store char matrices or cellstr objects. It should have a constructor (or constructors) that accepts strings, char matrices, cellstr objects, and numeric arrays and converts to the appropriate internal representation.

By restricting what this object can contain to only what we need, users of the object don't have to check to be sure that some unexpected type of value is stored there, which makes things simpler for the rendering code.

I'm also not sure what the best name is for this new object. Maybe a text_label_property or similar?

John W. Eaton <jwe>
Project Administrator
Sat 13 Aug 2011 05:38:02 PM UTC, comment #35:

I've attached a 3rd version.

I haven't tested it with the fltk backend (I'm having some fltk problems, which I haven't had time to investigate).

(file #23799)

Ben Abbott <bpabbott>
Project Member
Sat 13 Aug 2011 03:32:17 PM UTC, comment #34:

I ran some additional tests for the text() command. ML's text() command only accepts string and cellstr arguments. However, the string property for the text object can be set using numeric values.

I can modify the changeset to be compatible in most cases. The one thing I don't know how to do is change set(h,'string', 1:3) so that the result is stored as num2str((1:3)(:)).

For those who are interested, I've attached a pdf (test_text.pdf) illustrating the result of the ML commands above.

(file #23798)

Ben Abbott <bpabbott>
Project Member
Sat 13 Aug 2011 02:48:06 AM UTC, comment #33:

Sorry, I should have been more specific. The 'string' property itself can be set a numeric scalar, numeric cell-array, mixed cell-array, etc in ML. It seems the elements get converted internally into strings, but remain in the same form (scalar / cell / matrix).


Vanya Sergeev <vsergeev>
Sat 13 Aug 2011 02:35:07 AM UTC, comment #32:

John, I just checked. ML supports numeric scalars & numeric cell-arrays for its titles and axis labels.

Vanya Sergeev <vsergeev>
Sat 13 Aug 2011 01:52:22 AM UTC, comment #31:

I don't think you want to do "char (value)". It would make more sense to convert numbers to strings using num2str or sprintf or something like that.

I think you want the "string" property to be stored as a string or a cellstr, but not as a numeric object or a cell array containing anything other than character strings. Then the internals can always assume that the string property is really a string or cellstr object, which simplifies things there.

If someone gives a numeric object or a cell array containing something other than character strings, it would be fine with me to throw an error, but you might want to see what Matlab does if you care about compatibility.

John W. Eaton <jwe>
Project Administrator
Sat 13 Aug 2011 01:17:02 AM UTC, comment #30:


I'd like to avoid specifying how the underlying architecture works (there may be solutions I've not considered).

What is I understand is needed ...

str = "hello world"';
h = text (0, 0, str);
assert (strcmp (str, get (h, "string"))

... and ....

str = ["hello"; "world"]';
h = text (0, 0, str);
assert (strcmp (str, get (h, "string"))

.. and ...

str = {"hello", "world"}';
h = text (0, 0, str);
assert (strcmp (str, get (h, "string"))

We could copy what is done for ticklabels, but what should be done for numeric values? We might do a num2str(value), char(value), or throw an error.

Ben Abbott <bpabbott>
Project Member
Sat 13 Aug 2011 12:56:46 AM UTC, comment #29:


I hope I'm not adding noise to an already very populated bug report, but here is my analysis of your request: all of the _go_foo_ objects are essentially the "same" object: a collection of name-value properties and a pointer to a parent. They are all implemented the same way; the only thing that changes is the name of the object. AIUI, you want the "string" property of _go_text_ to accept cell strings in addition to ordinary strings, as well as character arrays, for reasons I don't understand. I was stepping through the code, and I think this should be easy to do, but then any other _go_foo_ object that has a "string" property could also accept cell string values.

If this is what you want, I can prepare a patch quite easily. If only the "string" property of _go_text_ should accept cell strings, that would require more in-depth hackery.

Do you also want character arrays or just cell strings?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sat 13 Aug 2011 12:55:53 AM UTC, comment #28:

It turns out gl2psTextOpt() (used for opengl plot printing) does not account for newline characters "\n", "\r", or "\r\n".

All plots come out with "abc def" on one line...

Perhaps gl2psDrawPixels() ( http://geuz.org/gl2ps/#tth_sEc2.3 ) should be used instead of gl2psTextOpt() with the pixel array generated by the ft_render class, to support multi-lines in the gl2ps prints?


Vanya Sergeev <vsergeev>
Fri 12 Aug 2011 09:24:46 PM UTC, comment #27:

Attached is an experimental patch for txt-eng-ft.cc to process newline characters in the rendering process. When the glyph rendering loop encounters a '\n', it attempts to look up the glyph for a space (' ') and use it's face->size->metrics.height to increment yoffset, and resets xoffset to 0. It builds the initial bounding box similarly.

Now multiple lines work in FLTK labels, except they are not centered with respect to one another...

Here is a sample run:
Screenshot of the plot attached.

Also, all of the "missing glyph" messages are taken care of since the newline is processed.


(file #23794, file #23795)

Vanya Sergeev <vsergeev>
Fri 12 Aug 2011 09:17:37 PM UTC, comment #26:

I've attached an updated changeset using Vanya's rev2 patch.

(file #23793)

Ben Abbott <bpabbott>
Project Member
Fri 12 Aug 2011 09:15:30 PM UTC, comment #25:


In text.m I see ...

I think we want the "string" property value to be either character (rows x length), or cell-strings.

Are you saying that all the _go_foo_ objects will need to be modified to accept either cell, or character, inputs for "string" properties?

Currently, the ticklabels for axes objects and string properties for text objects may be numeric, character, or cellstrings. Perhaps the same approach can be used for "string" properties?

Ben Abbott <bpabbott>
Project Member
Fri 12 Aug 2011 05:54:47 PM UTC, comment #24:

Jordi, I repeated the tests I posted in my previous comment with FLTK. All forms (char matrix / cellstr) of the multi-line labels come through, but the newlines don't show up, so the strings are just concatenated together (like "line1line2" for the first one).


Vanya Sergeev <vsergeev>
Fri 12 Aug 2011 05:32:42 PM UTC, comment #23:

I'm not really following all of the discussion, but all of the _go_foo_ objects in C++ are implemented uniformly with some macros. It's not easy to make _go_text_ accept cell arguments without making every other _go_foo_ function also accept cell arguments. I can make this change, if you wish, then potentially every property of a graphics object can be a cell. Is this desirable?

I'm also not sure if this is still needed; Vanya, can you please test with fltk too?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 12 Aug 2011 05:28:19 PM UTC, comment #22:

I applied your patch Ben, taking into account rev2 of mine. Nice! all of these are working as expected with gnuplot:

(I omitted the "skipping missing glyph messages" for clarity).


Vanya Sergeev <vsergeev>
Fri 12 Aug 2011 05:09:23 PM UTC, comment #21:

I expanded/generalized my experimental patch a bit:
* recognizing multi-dimensional string/char matrices, e.g. ["abcd","efg"]
* adding support for the multi-lines in glps_renderer::draw_text(), identical newline addition code from what I have graphics.cc
* rendering "" in glps_renderer::draw_text() and text::properties::update_text_extent() if the value is neither a string/charmatrix nor cellstr

Attached is rev2 of the experimental patch.

I believe Philip's txt-eng-ft.cc.diff patch cleans up the ft_render missing glyph messages.


(file #23791)

Fri 12 Aug 2011 04:44:44 PM UTC, comment #20:

Jordi, taking care of _go_text_ would be great (see the note in text.m).

There may be other problems encountered when tested on fltk.

Ben Abbott <bpabbott>
Project Member
Fri 12 Aug 2011 04:37:05 PM UTC, comment #19:

Ben, what is it you need help with? _go_text__()? I'll take a look at it.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 12 Aug 2011 04:33:50 PM UTC, comment #18:

I've attached a changeset for the stable branch. It works for the gnuplot backend, but it untested on fltk. This changeset includes Vanya's work.

I have a bit more work to do on the m-file side, but will need some help on the c/c++ side.


Test using the FLTK OpenGL backend.

Suppress the "missing glyph" warnings from gnuplot. This may be done by converting the multiline text objects can be split into separate gnuplot text labels, or we can ask the gnuplot development team to avoid warnings for NL characters.

Modify the _go_text_() built-in to accept cell-strings.

Minor rewrite of text.m to ensure that string property for text objects has the same class as the input to text().

(file #23790)

Ben Abbott <bpabbott>
Project Member
Fri 12 Aug 2011 12:15:03 AM UTC, comment #17:

Okay, so it really doesn't like the rest of my comment. If only there were a preview button here...

with Ben's _go_draw_axes_.m patch applied.

I figured maybe I'd get some pointers here in case I'm working in the wrong direction. I hadn't delved into the octave source before, so I ran into a few question:
- Is is_empty() the analogous empty-checking method for octave_value?
- I read the top of genprops.awk, but I'm not exactly sure about the 'u' versus 'm' versus 'mu' properties. The 'm' modifier on the "string member" seems to require the method string_setmode() that doesn't exist / isn't generated during the build.

I attached the purely experimental patch, really just for bumping the bugfix.


Vanya Sergeev <vsergeev>
Fri 12 Aug 2011 12:12:33 AM UTC, comment #16:


You patch applied cleanly to the stable branch of the developers sources. Tomorrow I'll test it and report back.

Thanks for the quick assistance.

Ben Abbott <bpabbott>
Project Member
Fri 12 Aug 2011 12:11:53 AM UTC, comment #15:

It seems like the rest of my comment got cut-off, sorry. The last bit was:

Vanya Sergeev <vsergeev>
Fri 12 Aug 2011 12:05:41 AM UTC, comment #14:

Philip, for attribution purposes the fix was really David's, I just made a slight modification. Throwing it in title.m does fix things for me though, as far as the title goes.

Ben, I understand, you'd like the strings of text objects to take arbitrary form (string, char matrix, cell matrix) in the backend itself.

I worked with your string_property -> any_property modification a bit. This means that the "string member" of text::properties is stored as an any_property which wraps the very generic octave_value, instead of a string_property which wraps a std::string, and leads to a number of changes in other source files.

"string_property string u" -> "any_property string u"

gl-render.cc / gl2ps-renderer.cc / graphics.cc:
empty() for std::string -> is_empty() for octave_value

glps_renderer::draw_text(): in the patch I have it pass the c-string to gl2psTextOpt() if the "string member" is actually a string, otherwise it just passes along "". I'm not sure how gl2psTextOpt() is supposed to handle multi-lines, so I left it like this for now.

if "string member" is a string, it passes along the std::string to text_to_pixels()
if "string member" is a char matrix or cell string, it pulls out the strings with all_strings(), appends "\n" between them and sends the total string to text_to_pixels().

The attached experimental patch builds for me.

Now, instead of:

I get this far:

Vanya Sergeev <vsergeev>
Thu 11 Aug 2011 07:56:15 PM UTC, comment #13:


Matlab provides two ways to implement text objects. The documented approach is ...

In addition, this (undocumented approach) also works

I'd like to see both of these approaches work in Octave.

Since title(), xlabel(), and ylabel() each produce text objects, patching the sources to allow text objects to be multiline should resolve all these problems.

This will require that all backends are able to handle strings that are character arrays, and cell-strings.

Ben Abbott <bpabbott>
Project Member
Thu 11 Aug 2011 05:59:25 PM UTC, comment #12:

As far as just titles go, Vanya's version of the patch looks much simpler than fixing gnuplot and can be improved even a little bit more:

to get rid of the useless trailing newline (this is how I have patched it in my Octave installations).

Perhaps this patch had rather be implemented in title.m instead of _axis_label_.m

I would be very glad if this missing feature could be fixed at last.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 11 Aug 2011 02:20:23 PM UTC, comment #11:

I think a ML compatible implementation for the gnuplot backend is straight forward. The "string" property for a text object needs to be modified so that its value may be of class "char", or "cell". For the ticklabels this is done by making the change below.

The above is changed to ...

Unfortunately, this change results in a compiler error for the OpenGL renderers.

My c/c++ skills are embarrassingly poor. If someone can provide a change that allows the OpenGL code to compile and function properly with the above change, I should be able to handle the result of the needed changes for the the gnuplot backend.

In any event, beyond the above change, the text.m and _go_draw_axes_.m functions need to be changed. I can't test the changes needed by these until the OpenGL build error is resolved, but I've attached a diff that should be sufficient.

For those unfamiliar with how ML implements multi-line text, the commands below would give multi-line results.

text (x, y, {"Hello", "World"})
text (x, y, ["Hello";"World"])


(file #23784)

Ben Abbott <bpabbott>
Project Member
Thu 11 Aug 2011 10:37:22 AM UTC, comment #10:

I was interested in cell-based multi-line titles in Octave 3.4.2, and discovered this bug report.

The _axis_label_.m patch below works but it produces extra newlines at the end for me. For example:

txt = line1Zline2Zline3ZZZ

(The second line forgets to take into account that the cell length has been doubled by the first, so as many extra newlines as there were original elements are added at the end)

This does the trick for me:


Vanya Sergeev <vsergeev>
Sun 13 Feb 2011 12:10:27 PM UTC, comment #9:

This issue hadn't been solved yet in 3.4.0.

- Using GNUplot the fix by David Bateman works OK.
- Using FLTK that works too but warning messages "ft-render: missing glyph for character '
' show up (note the newline between quotes).
(Surprisingly (for me) this warning shows up twice for each newline. I also see newlines silently inserted when using cell string arrays as input arg to title(), as
title ({"Title"})

I made a fix for suppressing those messages that works for me on Linux. I expect it to work on MinGW too but I can't check as I cannot build Octave on Windows.

I'm attaching two patches (using diff -cp):

- One for _axis_label_.m, the patch suggested by David Bateman

- One for src/txt-eng-ft.cc

+ a Changelog entry.

The 2nd patch makes txt-eng-ft() skip only newline warnings, as newline characters aren't "printed" (but turn out to work OK). Tabs and \r (char return) do show up with dashed boxes, but I think this is currently no big deal for the multi-line fix itself. David's fix doesn't add in \r chars, only \n's
BTW my 2nd patch is about as far as I can get using my limited C++ knowledge :-)

I don't know how to make a changeset, sorry. I couldn't find a useful ready-to-fill-in template.

(file #22667, file #22668, file #22669)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 28 Jan 2011 11:01:56 PM UTC, comment #8:


Ok, I think I understand what you were commenting on. My first impression what you had set the string property of a text object to a cell-of-strings ... but I got errors when I tried.


Ben Abbott <bpabbott>
Project Member
Fri 28 Jan 2011 09:52:58 PM UTC, comment #7:

> Philip, when you wrote "David's suggestion works OK in 3.3.90 (& 3.3.54+)&
> gnuplot", what is the suggestion you refer to?

(repost of David's comment)

Am I missing something, but can't this be fixed by adding something like

if (iscellstr (txt))
## Treat cell string array as multi-line text
txt(1:2:2*numel(txt)) = txt;
txt(2:2:2*numel(txt)) = "n";
txt = [txt{:}];

to the top of the axis_label function?

BTW, David also asked for Matlab behaviour:

Can Matlab set multiline text in the handle directly? What does matlab give for something like
h = title('One Line');
set (h, 'string', {'Two','lines'})

ML 2010b first shows a figure with title 'One line', after set() the title changes into:

Philip Nienhuis <philipnienhuis>
Project Member
Fri 28 Jan 2011 09:36:22 PM UTC, comment #6:

gnuplot's text and axis labels allow an "offset" parameter to be set that (I expect) makes implementing compliant multi-line text objects rather convenient.

I've been meaning to take a look, but have been waiting for the text objects to be modified to accept a cell of strings.

Philip, when you wrote "David's suggestion works OK in 3.3.90 (& 3.3.54+) & gnuplot", what is the suggestion you refer to?

Ben Abbott <bpabbott>
Project Member
Fri 28 Jan 2011 09:07:33 PM UTC, comment #5:

David's suggestion works OK in 3.3.90 (& 3.3.54+) & gnuplot, but I get these warnings when using FLTK backend in 3.3.90 (MingW):

"warning: ft_render: skipping missing glyph for character '

(w/o double quotes, note the newline between the single quotes)

I suppose ft_render() should be instructed to ignore newlines?

Philip Nienhuis <philipnienhuis>
Project Member
Wed 08 Dec 2010 01:11:29 PM UTC, comment #4:

(repost of David's comment)

Am I missing something, but can't this be fixed by adding something like

to the top of the _axis_label_ function? The "text" function already treat
cell string arrays as multiple calls to the text function with different
values of "x", "y" and "z". Therefore "x", "y" and "z" are expected to have as
many elements as there are elements in the cell string array.

So as far as I can tell _axis_label_ is the only function that needs to be
treated in this way. Does it make sense to treat multiline strings in tick
labels? If so then we'd need to treat this feature request in graphics.cc as
the ticklabels might be set directly from the handle.

Can Matlab set multiline text in the handle directly? What does matlab give
for something like

give in matlab. If the above works, maybe the text objects themselves should
be adapted to handle cell string arrays.


Ben Abbott <bpabbott>
Project Member
Wed 08 Dec 2010 01:10:13 PM UTC, comment #3:

(report of Rik's comment)

We do need to know how Matlab handles cell string arguments to title. In addition, there is still a problem of using inserted newlines with the FLTK backend which doesn't interpret 'n'. My suggested hack of title("hellonworld") only works with gnuplot.

Ben Abbott <bpabbott>
Project Member
Wed 08 Dec 2010 01:07:09 PM UTC, comment #2:

In Matlab I tried ...

h = title('One Line');
set (h, 'string', {'Two','lines'})
get (h, 'horizontalalignment')
ans = center

The result is a two line title with each line justified to the center. With
activepositionproperty == "outerposition" the position property is modified to
accomodate the additional line.

AFAIK Matlab treats the title, xlabel, ylabel, and zlabel as all other text
objects on the parent axis. The differences are their handles are hidden in
the list of children, but are listed in the properties of the axis.

Ben Abbott <bpabbott>
Project Member
Wed 27 Oct 2010 05:00:34 AM UTC, comment #1:

For compatibility I agree that it would be nice to change the Octave parser to handle cell arrays of strings for this purpose.

As a workaround until that is coded, the UNIX standard of using "\n" for newline works.
produces a 2-line title using gnuplot 4.4.0 and Octave dev.

Rik <rik5>
Project Administrator
Tue 26 Oct 2010 02:56:59 PM UTC, original submission:

ML allows for multi-line text objects by setting the string property to a cell array of strings.

Octave gives an error.

octave:1> title ({'hello','world'})
error: title: expecting first argument to be character string

Ben Abbott <bpabbott>
Project Member


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

Attach Files:

Attached Files
file #35011:  truncated_text.png added by rik5 (20KiB - image/png)
file #34987:  multiline.eps added by pantxo (1MiB - image/x-eps)
file #34988:  tester.m added by pantxo (1KiB - d2l/unknowntype)
file #34984:  1-txtengmods.patch added by pantxo (8KiB - text/x-diff)
file #34985:  2-glrendermods.patch added by pantxo (5KiB - text/x-diff)
file #34986:  3-gl2psmods.patch added by pantxo (12KiB - text/x-diff)
file #23825:  pixels.rgba added by bpabbott (2KiB - application/octet-stream)
file #23826:  pixels.png added by bpabbott (302B - image/png)
file #23823:  my_pixels_test.png added by vsergeev (405B - image/png)
file #23819:  demo4-tip.pdf added by bpabbott (94KiB - application/pdf)
file #23820:  demo4-patch.pdf added by bpabbott (100KiB - application/pdf)
file #23812:  demo4.pdf added by bpabbott (94KiB - application/pdf)
file #23810:  fltk_multiline_alignment.patch added by vsergeev (3KiB - application/octet-stream)
file #23800:  extra-text-diffs.txt added by jwe (1KiB - text/plain)
file #23799:  multiline_text_for_gnuplot.patch added by bpabbott (19KiB - application/octet-stream - Third attampt)
file #23798:  test_text.pdf added by bpabbott (10KiB - application/pdf)
file #23794:  fltk_multiline_render_experimental.patch added by vsergeev (6KiB - application/octet-stream)
file #23793:  multiline_text_for_gnuplot.patch added by bpabbott (10KiB - application/octet-stream - Using Vanya's rev2 patch)
file #23791:  experimental_any_property_string_rev2_octave-3.4.2.patch added by None (4KiB - application/octet-stream)
file #23790:  multiline_text_for_gnuplot.patch added by bpabbott (10KiB - application/octet-stream - Ben's second changetset)
file #23784:  multiline_text_for_gnuplot.diff added by bpabbott (3KiB - application/octet-stream)
file #22668:  txt-eng-ft.cc.diff added by philipnienhuis (1KiB - text/x-patch)
file #22669:  Changelog_31468 added by philipnienhuis (196B - application/octet-stream)


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by vsergeev (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Posted a comment)
  • -email is unavailable- added by bpabbott (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 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-18 andy1978 Dependencies- => bugs #49121 is dependent
    2015-10-14 pantxo StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2015-09-29 rik5 Dependencies- => bugs #46055 is dependent
    2015-09-29 rik5 Attached File- => Added truncated_text.png, #35011
    2015-09-26 pantxo Attached File- => Added multiline.eps, #34987
        Attached File- => Added tester.m, #34988
    2015-09-26 pantxo Attached File- => Added 1-txtengmods.patch, #34984
        Attached File- => Added 2-glrendermods.patch, #34985
        Attached File- => Added 3-gl2psmods.patch, #34986
    2015-03-08 philipnienhuis SummaryPrinting of multi-line text objects (FLTK) => Printing of multi-line text objects (OpenGL)
    2015-03-08 mtmiller Operating SystemMac OS => Any
    2014-06-03 mtmiller Dependencies- => bugs #42481 is dependent
    2014-03-25 rik5 Dependencies- => bugs #41954 is dependent
    2011-09-28 rik5 Summarymulti-line text objects => Printing of multi-line text objects (FLTK)
    2011-09-28 rik5 CategoryNone => Plotting with OpenGL
    2011-08-17 bpabbott Attached File- => Added pixels.rgba, #23825
        Attached File- => Added pixels.png, #23826
    2011-08-17 vsergeev Attached File- => Added freetype_pixels_dump_test.patch, #23822
        Attached File- => Added my_pixels_test.png, #23823
    2011-08-16 bpabbott Attached File- => Added demo4-tip.pdf, #23819
        Attached File- => Added demo4-patch.pdf, #23820
    2011-08-16 vsergeev Attached File- => Added txt_eng_ft_rendering.patch, #23813
        Attached File- => Added gl2ps_ft_pixels_rendering.patch, #23814
        Attached File- => Added gl2ps_ft_render_pixels_test.png, #23815

    Back to the top

    Powered by Savane 3.4