GNOME Bugzilla – Bug 425685
Zoomed subscripts not displayed properly
Last modified: 2011-10-28 01:59:03 UTC
Please describe the problem: the subscript is very small and does not change size when zooming Steps to reproduce: 1. open the file I will attach 2. set zoom to 200% 3. Actual results: subscript size is illegibly small Expected results: the subscript would be the right size and change with zooming Does this happen every time? yes Other information:
Created attachment 85733 [details] cell A1 has a subscript
It looks to me like this is not an issue anymore in 1.8.3 or 1.9.x. Would you please confirm that this problem is gone?
Created attachment 118375 [details] screenshot of gnumeric and excel rendering the file Well, The problem isn't as I initially saw it, however subscript rendering in gnumeric still looks clumsy. The attached image shows gnumeric 1.9.1 and excel opening the same file side by side. it looks right in excel, not so good in gnumeric. Zooming in excel works smoothly, while in gnumeric, at low zooms the text seems to get the bottom chopped off, while at high zooms it looks better, but the subscript doesn't appear as a subscript.
Well that comparison is a touch inappropriate: In Gnumeric you are using a font that doesn't appear to be installed in the system while in Excel you are using an installed font. Plus the column width seems to be the default width which happens to be the right width for XL. Nevertheless, the subscript in Gnumeric seems to be of the specified font size rather than a reduced font size. (THat may be an import issue.) Also in enlargements the subscript appears not to be owered by an appropriate amount. If you change to an installed font the text is not cut off at the bottom unless to specify a fixed row height.
Created attachment 118391 [details] Update of previous screenshot i apologoze for the confusion. only cell A1 is font arial, all other cells being sans font. i had a cell other than A1 highlighted in my previous screenshot. I am pretty sure my system supports Arial font. Would it be possible for excel to have access to the font, and not gnumeric for some reason? You are right the problems seem to be that gnumeric doesnt use smaller characters to make subscripts, and that the subsript is not lowered when enlarged. The row height is gnumeric default, I do not see how to make it non-fixed. I also tried changing a font to a couple of the others in the font picker in gnumeric, and the cropping still happens on reduction in zoom, these fonts must be installed, or else I wouldn't be able to pick them right?
Sorry I missed that you were running Gnumeric under MSWindows. I was looking at what I am seeing with Gnumeric on Linux. If you see Arial in your font picker, it is probably available to Gnumeric. Under Linux the subscript is in fact lowered when enlarged (just not as much as I would expect.) Since there are clearly some issues with Subscripts under Linux (if possibly less than under MSWindows), I will leave teh OS selector on "All". Thank you
Regular subscripts should show properly now (in post 1.9.9). The zooming issue remains.
There are several issues: the file attached above does not import correctly. I have turned this into bug #662497. In Gnumeric subscripts and superscripts don't zoom properly: (a) subscripts in text created using the subscript buttons or the subscript key combinations, bot when applied to the whole cell or to parts of the text. (b) superscripts generated as part of scientific number notation Part (a) is now fixed in current git.
Part (b) has been fixed in goffice. This report remains open since the handling of sub- and superscript in a cell being edited is not quite correct yet.
I think we are doing it all the wrong way. The pango attributes are used both for rendering and to store the information in the first place. Of course rendering is zoom dependent. Since pango does not have a relative scale and a relative rise, this creates problems. Trying to fix the zoom under editing by itself isn't that difficult but then we save those attributes and they are of course wrong. So as a consequence we need to undo what we adjusted before saving. If we have to convert forth and back anyways we probably should just use our own subscript/superscript pango attributes.
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.