GNOME Bugzilla – Bug 584380
Fraction format alignment
Last modified: 2011-08-02 06:32:23 UTC
The alignment of fractions seems to depend on the font and so does not work coirrectly for variable width fonts. The screen shot on the next page shows two column of the same values, the second column formatted as "# ?/2". I would expec tthe "3" to line up. (The fact that the "3" is not on the right of the cell seems to indicate that it is intended to line up.)
Created attachment 135680 [details] screen shot showing the misalignment
Correct. All alignment we do -- including the fill operator -- depends on the font. I don't think there is much we can do in terms of a proper fix with a reasonable amount of work. PangoLayouts just aren't meant for this. In this case there is one think we ought to check: if we're formatting to a PangoLayout (as opposed to a string) we could probably use different kinds of whitespace characters to get a better match.
If we are going directly into a PangoLayout, then we also have tab stops available and we might be able to use them.
> I don't think there is much we can do in terms of a proper fix > with a reasonable amount of work. PangoLayouts just aren't meant for this. This is not correct, at least not anymore. We can set the exact width of a space (or any other character if we wish) using an attribute from pango_attr_shape_new.
Created attachment 189285 [details] [review] proposed patch to goffice This patch would fix this issue by using one or more appropriately sized spaces. (In most scripts it will be a single space). This patch requires the patches from bug #651561.
Created attachment 189286 [details] [review] proposed patch to goffice We need to avoid trying to use this for graph ticks since their layouts have no fontmap yet.
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.
Created attachment 193026 [details] screenshot Well the fix committed works fine for single digit denominators but it doesn't cover the case of multiple digit denominators when the numerators could be 1, 2, ... digits. See the attached screenshot.
hopefully really fixed now. (If a font is used where the digits have different width this may still be incorrect but we'll address that when we get there.) 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.