GNOME Bugzilla – Bug 417631
Rich chart text (labels, titles etc.)
Last modified: 2011-08-06 12:48:41 UTC
It would be great if charts could include formatted text, whether in the form of HTML tags entered into the chart properties dialog, or a reference to a cell containing formatted text. It is often important to be able to add italics, superscript/subscript etc. to graph labels/titles in scientific publications. Right now the only way to get this is to export the charts and edit them in Inkscape.
*** Bug 425160 has been marked as a duplicate of this bug. ***
*** Bug 524029 has been marked as a duplicate of this bug. ***
Formatting in gnumeric is inconsistent now. Some of formats available in a plot are not available for cells, though mostly the problem is how cell contents are shown in charts. I want to collect here the problems I have encountered. 1. X-Axis1 of XY plot properties has no Format tab, while Y-Axis1 has. (It also differs by the names of ticks and lack of Type, but that is not about rich text ;-) 2. Custom format #EE0 for Y-Axis1, corresponding to Scientific with Use superscript is recognized by format for a cell, but leads to wrong rendering both in the cell and in the edit pane. They change to the value when F2 is pressed... 3. Meaning of + and - is different in different places of format strings for a cell and for Y-Axis1. One cannot use e.g. #0E00 for a cell, but it's OK for the axis. For a cell #0E-00 should be used instead, but this will show a dash before exponential (with possible sign) for axes. Look also at -0.00E+0 and +0.00E+0. 4. One cannot use small e as exponential sign (as in 0.0e+0), although corresponding numbers are recognized all right. 5. I could not find a format for a number been shown as 0.345E3 or .345E3 (pre-exponent between 0.1 and 1). ".000E-0" shows .450E2 instead. Notice a lost digit! My bet was on "#.0##E-0", but that gives 3.45E2. My tests were done with 1.10.14 in FreeBSD, some checked in 1.10.15 Win7. Wait! "#.0##E-0" gives .345E0 in 1.10.15, Win7. It changes behind the scene the format string to "#\.0##E-0" and then uses that... Agrh... That's just difference of locales, comma is the floating point in that Win7... But still, silent change of . to \. is very surprising. Why not only . as the floating point indicator, likewise to 0 used for all digits? Well, you might have a reason, of course. I do not know what is XL-style format, anyway.
Vladimir, you wrote in comment #3: "Some of formats available in a plot are not available for cells". Could you give an example of such a format?
I guess #0E00 is one such example.
No, that doesn't seem right. The format of the y-axis can be set to the format string #0E00 but it is still an invalid format and the y axis labels all become #####.
(In reply to comment #4) > Vladimir, you wrote in comment #3: "Some of formats available in a plot are not > available for cells". Could you give an example of such a format? They all are similar to 0EE0 - the superscripts in numbers. That's what relates to rich text...
For #EE0 in cells I have opened bug #651561 (since the cell rendering has nothing to do with charting.)
(In reply to comment #6) > No, that doesn't seem right. The format of the y-axis can be set to the format > string #0E00 but it is still an invalid format and the y axis labels all become > #####. Yeah, it's only about for #EE0 in axis and #E-0 in cell format..
#E-0 seems to work fine for me in-cell as well as on-axis.
Oh, which '-' is that? It should be U+002D HYPHEN-MINUS. Any other minus will be read as a literal symbol.
I was talking about normal -. In #E-0 for cells it has the same meaning as nothing (neither - nor +) in #EE0 for axis. But + or - is obligatory for cells. I do not even remember now how to insert unicode symbols. I did use them, both in X and in Win, when needed often during some short period of time, but now cannot recall... Well, I know where to look for it or how to find symbols in system programs ;) My vote would be on using normal '-' in format strings. And '.' for the floating point in all locales, even where ',' is used.
I don't understand. What did you mean with the second clause in "For a cell #0E-00 should be used instead, but this will show a dash before exponential (with possible sign) for axes." Which "dash before exponential" do you see with respect to axes?
(In reply to comment #13) > I don't understand. What did you mean with the second clause in "For a cell > #0E-00 should be used instead, but this will show a dash before exponential > (with possible sign) for axes." Which "dash before exponential" do you see with > respect to axes? I'm talking about consistency. In a cell format, a sign is mandatory (either + or -), while in axis format no sign means same as '-' in cell format, and '-' in axis format stands for itself. Actually, I was using formats with E for cells, and formats with EE for axis, in this test. And I use normal minus sign, not some unicode special minus symbol.
Created attachment 193196 [details] [review] tentative patch This patch has a lot of drawbacks, it uses the markup from the cell and: - this overrides the style; - when the markup changes but not the text, the labels are not updated until a redraw is forced; - it looks a bit hacky.
Created attachment 193240 [details] [review] first patch. A much better solution, already commited so that things start working.
With latest development code, we now have rich text support for both scalar and vector data which makes things work with all sorts of labels we have, provided the data are cells refs. It doesn't work if the text is directly typed in the graph data editor. It would probably be possible to make it work, but not easy, even for scalar data. I don't imagine implement that for vector data at all. Any comment, or might I close this bug?
Labels also accept rich text entered as markup (html like defined at http://developer.gnome.org/pango/stable/PangoMarkupFormat.html). Probably not for the average user though. I'm considering it fixed now.This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.