GNOME Bugzilla – Bug 651561
"EE" format doesn't produce superscripts in cells
Last modified: 2011-08-02 03:58:05 UTC
#EE0 appears to be accepted as a valid format code by the format selector. The preview shows: 4×10<sup>3</sup> If the format is chosen the cell shows only ######## but when the cell is selected the formula box shows 4×10<sup>3</sup> This bug is extracted from the comments to bug #417631 which is really a charting bug.
If you make the cell really wide you see in fact the literal 4×10<sup>3</sup> but this should be shown as superscript!
This is very close to be "as expected". At least by me.
Since we have already pangomarkup inthe cell we can get true superscripts quite easily: -------------------------------------------------- diff --git a/goffice/utils/go-format.c b/goffice/utils/go-format.c index 6c62419..263055e 100644 --- a/goffice/utils/go-format.c +++ b/goffice/utils/go-format.c @@ -2511,7 +2511,7 @@ SUFFIX(go_format_execute) (PangoLayout *layout, GString *dst, switch (op) { case OP_END: if (layout) - pango_layout_set_text (layout, dst->str, -1); + pango_layout_set_markup (layout, dst->str, -1); if (numtxt) g_string_free (numtxt, TRUE); if (oldlocale) { --------------------------------------------------- Unfortunately once we use pango_layout_set_markup we loose the ability to set pango attributes, ie. font, font size, styles. So this "fix" would not be acceptable.
As well as the ability to have "<sup>" (with quotes) in the format.
Created attachment 189036 [details] [review] proposed patch to goffice The only remaining problem I see with this patch is that the superscript is raised by a about 5 points, ie 5000 PangoUnits. This looks okay as a superscript in font sizes of about 10 to 12 point. This is not that different from what we are doing with super and subscripts in Gnumeric. That's where the 5000 came from. I would have preferred 8 x PANGO_SCALE currently about 8200.
Created attachment 189037 [details] [review] proposed patch to goffice Oops, the previous patch had my preferred 8*PANGO_SCALE, this one uses 5000.
pango-markup.c hardcodes 5000, but I suppose we could derive that value by creating (once) a layout containing "<sup>x</sup>" and looking at that. Does the patch work within goffice, i.e., do the graph uses still work?
hmm, apparently not. The superscripts in graphs now fail.
Created attachment 189059 [details] [review] proposed patch to goffice
Created attachment 189060 [details] [review] proposed patch to gnumeric This patch and the last patch to goffice are a slight improvement (but not ready for consumption) This seems to handle the in-sheet cells and the SUM= field correctly. [Note that this breaks the goffice API so is intended for after branching.]
Created attachment 189064 [details] [review] proposed patch to goffice
Created attachment 189065 [details] [review] proposed patch to gnumeric These new revisions also handle the preview in the format selector (+- a little issue in go_load_pango_attributes_into_buffer that pango uses bytes and the textbuffer characters)
Created attachment 189066 [details] [review] proposed patch to goffice This patch also fixes the misalignment between character and byte offset.
Created attachment 189138 [details] [review] proposed patch to goffice
Created attachment 189139 [details] [review] proposed patch to gnumeric The last two patches fix the problem that the cells did not showed the correct foreground colour (if one was set.)
In the Gnumeric case, wouldn't it be simpler to create a format_value_layout instead of adding an attribute return parameter to format_value_gstring? It seems to me that splitting the layout into text and attributes risks losing some setting of the layout.
Replacing the GoColor** argument with a PangoAttrList** argument seemed the smaller change (note that these can be NULL if we don't care about them.) The "format_value_layout" is sort of our gnm_format_value_gstring. (The GString passes info both ways, and it can be called with layout==NULL if we don't care about formatting.)
Created attachment 189200 [details] [review] proposed patch to gnumeric Updated patches with format_value_layout
Created attachment 189201 [details] [review] proposed patch to goffice
Created attachment 189247 [details] [review] extended patch for goffice to try to handle the ticks too I have tried to extend the attribute handling into goffice. The problem I encountered is that I can't see a way of getting an appropriate layout in gog-axis.c if I just have an axis and no gog-renderer.
I would not do that this way. I think we should attach a PangoAttrList to all goffice structures displaying a text, and change the GogRenderer API accordingly.
Jean, the patch attached to comment #19 started adding a PangoAttrList. In view of the second paragraph of comment #16, I was now trying to go the PangoLayout route.
OK, then I'll go this way for labels too. Just GOString uses an attribute list, not a layout.
Created attachment 189268 [details] [review] extended patch for goffice that also handles the ticks This patch to gofice typesets the ticks correctly. It attaches a layout to each tick _but_ I am not sure that is a good idea: I don't see how we get a correct cairo layout at that time. In the patch we are using a generic layout but later have to copy its information when we get the right layout. This seems to be not much better than attaching a string, attribute list and tab array.
We might use a GOString here.
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.