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

 
 

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

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Tue 26 Oct 2010 02:56:59 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: ConfirmedAssigned to: None
Originator Name: Ben AbbottOpen/Closed: Open
Release: devOperating System: Mac OS

Add a New Comment (Rich MarkupRich 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)

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.

Thanks,
~vsergeev

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.

Thanks,
~vsergeev

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

Thanks!

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

Thanks,
~vsergeev

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()).

Thanks,
~vsergeev

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.

Thanks,
~vsergeev

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

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

Ben,

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.

Thanks,
~vsergeev

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

With tip

http://hg.savannah.gnu.org/hgweb/octave/rev/6fc2c61660f2

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:

Vanya,

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

http://hg.savannah.gnu.org/hgweb/octave/rev/6fc2c61660f2

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.

Thanks,
~vsergeev

(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:

http://hg.savannah.gnu.org/hgweb/octave/rev/22bc9ec80c2c

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.

http://hg.savannah.gnu.org/hgweb/octave/rev/0c86ae6f7c34

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

Thanks,
~vsergeev

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:

Jordi,

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:

Ben,

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?

Thanks,
~vsergeev

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.

Thanks,
~vsergeev

(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:

Jordi,

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

Thanks,
~vsergeev

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

Thanks,
~vsergeev

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.

Thanks,
~vsergeev

(file #23791)

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

TODOs:

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.

Thanks,
~vsergeev

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

Vanya,

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.

graphics.h.in:
"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

gl2ps-renderer.cc:
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.

graphics.cc:
text::properties::update_text_extent():
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:

Phi/others,

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"])

Ben

(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:

yields:
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:

Thanks,
~vsergeev

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"})
shows.)

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:

Philip,

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

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?


<QUOTE>
(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{:}];
endif

to the top of the axis_label function?
</QUOTE>

BTW, David also asked for Matlab behaviour:

<QUOTE>
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'})
</QUOTE>

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

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.

D.

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

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

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 File(s):
   
   
Comment:
   

Attached Files
file #23825:  pixels.rgba added by bpabbott (2kB - 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 (94kB - application/pdf)
file #23820:  demo4-patch.pdf added by bpabbott (100kB - application/pdf)
file #23812:  demo4.pdf added by bpabbott (94kB - application/pdf)
file #23810:  fltk_multiline_alignment.patch added by vsergeev (3kB - application/octet-stream)
file #23800:  extra-text-diffs.txt added by jwe (1kB - text/plain)
file #23799:  multiline_text_for_gnuplot.patch added by bpabbott (19kB - application/octet-stream - Third attampt)
file #23798:  test_text.pdf added by bpabbott (10kB - application/pdf)
file #23794:  fltk_multiline_render_experimental.patch added by vsergeev (6kB - application/octet-stream)
file #23793:  multiline_text_for_gnuplot.patch added by bpabbott (10kB - application/octet-stream - Using Vanya's rev2 patch)
file #23790:  multiline_text_for_gnuplot.patch added by bpabbott (10kB - application/octet-stream - Ben's second changetset)
file #23784:  multiline_text_for_gnuplot.diff added by bpabbott (3kB - application/octet-stream)
file #22669:  Changelog_31468 added by philipnienhuis (196B - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by vsergeev (Posted a comment)
  • -unavailable- added by philipnienhuis (Posted a comment)
  • -unavailable- added by bpabbott (Submitted the item)
  •  

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

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 25 Mar 2014 02:40:07 PM UTCrik5Dependencies-=>bugs #41954 is dependent
    Wed 28 Sep 2011 08:54:42 PM UTCrik5Summarymulti-line text objects=>Printing of multi-line text objects (FLTK)
    Wed 28 Sep 2011 07:14:29 PM UTCrik5CategoryNone=>Plotting with OpenGL
    Wed 17 Aug 2011 03:39:51 PM UTCbpabbottAttached File-=>Added pixels.rgba, #23825
      Attached File-=>Added pixels.png, #23826
    Wed 17 Aug 2011 03:22:23 AM UTCvsergeevAttached File-=>Added freetype_pixels_dump_test.patch, #23822
      Attached File-=>Added my_pixels_test.png, #23823
    Tue 16 Aug 2011 08:23:19 PM UTCbpabbottAttached File-=>Added demo4-tip.pdf, #23819
      Attached File-=>Added demo4-patch.pdf, #23820
    Tue 16 Aug 2011 02:17:28 PM UTCvsergeevAttached 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
    Mon 15 Aug 2011 10:48:31 PM UTCbpabbottAttached File-=>Added demo4.pdf, #23812
    Mon 15 Aug 2011 06:46:09 PM UTCvsergeevAttached File-=>Added fltk_multiline_alignment.patch, #23810
    Sun 14 Aug 2011 04:40:22 PM UTCjweAttached File-=>Added extra-text-diffs.txt, #23800
    Sat 13 Aug 2011 05:38:02 PM UTCbpabbottAttached File-=>Added multiline_text_for_gnuplot.patch, #23799
    Sat 13 Aug 2011 03:32:17 PM UTCbpabbottAttached File-=>Added test_text.pdf, #23798
    Fri 12 Aug 2011 09:24:46 PM UTCvsergeevAttached File-=>Added fltk_multiline_render_experimental.patch, #23794
      Attached File-=>Added fltk_multiline_test.png, #23795
    Fri 12 Aug 2011 09:17:37 PM UTCbpabbottAttached File-=>Added multiline_text_for_gnuplot.patch, #23793
    Fri 12 Aug 2011 06:04:06 PM UTCrik5Carbon-CopyRemoved 72865=>-
    Fri 12 Aug 2011 05:09:23 PM UTCNoneAttached File-=>Added experimental_any_property_string_rev2_octave-3.4.2.patch, #23791
    Fri 12 Aug 2011 04:33:50 PM UTCbpabbottAttached File-=>Added multiline_text_for_gnuplot.patch, #23790
    Fri 12 Aug 2011 12:05:41 AM UTCvsergeevAttached File-=>Added experimental_any_property_string_octave-3.4.2.patch, #23789
    Thu 11 Aug 2011 02:20:23 PM UTCbpabbottAttached File-=>Added multiline_text_for_gnuplot.diff, #23784

    Back to the top


    Powered by Savane 3.1-cleanup