GNOME Bugzilla – Bug 519146
Wrong vertical displacement in super- and subscript.
Last modified: 2013-09-25 19:51:34 UTC
Please describe the problem: The vertical displacement is independent on font size (whereas it should) and dependent on the unit of the print operation (whereas it should not). Steps to reproduce: 1. Compile and run the attached program. 2. Look at the vertical displacement in the 26pt text and the 12pt text: they are equal. This can be observed on screen, in PDF and in print, on Linux and Windows. 3. Comment-out line 92, gtk_print_operation_set_unit() and recompile. 4. Observe that there is virtually no displacement in the super- / subscript in print. Anything but GTK_UNIT_POINTS gives inproper scaling. Actual results: An inconsistent displacement relative to font size. Expected results: A consistent displacement relative to font size. Does this happen every time? Yes Other information:
Created attachment 106107 [details] Illustrating code.
Note regarding point 4 above first sentence: this observation was done on win32, where the unit defaults to a printing dot, which is tiny. Fact remains that the displacement is affected by cairo_scaling (as a result of ...set_unit()). Also note that the _font size_ of the super-/subscript is affected as well!
(In reply to comment #2) > Also note that the _font size_ of the super-/subscript is affected as well! Sorry, I have to take that back. Although the super-/subscripts are a bit large to my taste, the size is not affected by cairo_scaling.
Created attachment 106252 [details] Printer output generated by PDFCreator, GTK_UNITS_POINTS. The large font gets the same displacement as the small font.
Created attachment 106253 [details] Printer output created by PDFCreator, no ...set_unit() (default to GTK_UNIT_PIXELS) Too little displacement in super-/subscript.
Created attachment 243552 [details] GTK3 Linux printing/preview example I am also running into this problem with GTK+3. I made a small example so I attach it in case anyone prefers it to test or give advice about this problem. I don't know if this is a bug or we are misunderstanding something. Hope this helps and somebody gives us an advice.
I believe this is a duplicate. *** This bug has been marked as a duplicate of bug 692470 ***
Behdad, I love you and you rock, but I am sorry to inform you that this is not a duplicate :-/. The mentioned commit fixes a problem in Mac and Win32 backends but doesn't touch anything in Linux. This problem is reproducible in Linux. Please try the simple example/test in attachment 243552 [details] (https://bugzilla.gnome.org/attachment.cgi?id=243552). Beware, maybe I am doing something wrong or misunderstood something! Thanks a lot for looking into it!!! Have fun!
Ah, sorry, my bad. I'll take a look into this later.
I'm on OS X 10.8.4 using pango 1.34.1 and I too have problems with the superscript and subscript vertical displacement, which led me to this bug report. I have not tried the files attached here. My reproduction recipe is: pango-view --font="Times 14" --markup --text="Normal<sup>super</sup><sub>sub</sub>" Here the vertical displacement looks reasonable. pango-view --font="Times 140" --markup --text="Normal<sup>super</sup><sub>sub</sub>" Here the vertical displacement is far too small. pango-view --font="Times 4" --markup --text="Normal<sup>super</sup><sub>sub</sub>" Here the text is illegibly small but we can see that the vertical displacement is far too large. From these tests I concluded that the vertical displacement is not based on the font size, however it should be. Looking in the code, I see the vertical displacement is always ±SUPERSUB_RISE which is #define'd as 5000 pango units, or 5000/1024≈4.88 pixels (or whatever the unit is), regardless of font size.
*** This bug has been marked as a duplicate of bug 708780 ***