#1469 [GTK] Rounding issue in font ascent and descent can truncate lines vertically

Bug
open
nobody
patch (5) GTK (3)
5
2013-05-01
2013-04-29
No

The font ascent and descent is currently rounded down, which results in vertically truncated lines if the values aren't integers. To fix this, round the values up.

This doesn't change anything on screen, probably because the screen resolution is set up on pixels, but this fixes drawing on e.g. a scaled print surface.

On a technical point of view, I'm not sure why simply making SurfaceImple::Ascent() and SurfaceImpl::Descent() properly internally work on XYPOSITIONs (which IIUC are floats) doesn't fix the issue, but I guess that some code uses their return values as integers or something.

1 Attachments

Related

Bugs: #1536

Discussion

<< < 1 2 (Page 2 of 2)
  • Its worth trying some different settings to see what happens.

    What do you suggest? I can run whatever appropriate tests on a few Linux machines, maybe even a Windows one.

    BTW, I ran the exact same code on another machine, with GTK 2.20 -- the previous tests were made with GTK 3.4. The results are really similar:

    • Monospace 8:
      • Pango context resolution from screen (depends on the screen DPI): 85.103516
      • Pango context resolution from GtkPrintOperation: 72
      • Pango context font ascent/descent from screen: 9.0/3.0
      • Pango context font ascent/descent from print: 7.421875/1.890625
      • Scintilla font ascent/descent from screen: 9.0/3.0
      • Scintilla font ascent/descent from print: 9.0/2.363281
    • Monospace 10:
      • Pango context resolution from screen (depends on the screen DPI): 85.103516
      • Pango context resolution from GtkPrintOperation: 72
      • Pango context font ascent/descent from screen: 11.0/3.0
      • Pango context font ascent/descent from print: 9.281250/2.359375
      • Scintilla font ascent/descent from screen: 11.0/3.0
      • Scintilla font ascent/descent from print: 11.0/3.545898
    • Monospace 12:
      • Pango context resolution from screen (depends on the screen DPI): 85.103516
      • Pango context resolution from GtkPrintOperation: 72
      • Pango context font ascent/descent from screen: 14.0/4.0
      • Pango context font ascent/descent from print: 11.140625/2.828125
      • Scintilla font ascent/descent from screen: 14.0/4.0
      • Scintilla font ascent/descent from print: 14.0/3.545898
    • Monospace 16:
      • Pango context resolution from screen (depends on the screen DPI): 85.103516
      • Pango context resolution from GtkPrintOperation: 72
      • Pango context font ascent/descent from screen: 18.0/5.0
      • Pango context font ascent/descent from print: 14.859375/3.781250
      • Scintilla font ascent/descent from screen: 18.0/5.0
      • Scintilla font ascent/descent from print: 18.0/4.727539

    Again, Pango print context line height vs. Scintilla line height scaled by print_resolution/widget_resolution:

    • 9.3125 vs 9.613659
    • 11.640625 vs 12.306244
    • 13.96875 vs 14.844329
    • 18.640625 vs 19.228145

    Your measurements show some .99s (for the combined height) which are classic rounding errors.

    Indeed, but note that these were manual additions of the number above, so with only 6 fractional digits. But yeah, this could perhaps be a problem, but it probably could be solved easily by giving room for error, like floor(val + 0.9) or something.

    Fractional line heights are problematic for displaying code. '-' and '=' are often composed of single pixel lines and having a line pitch of x.5 makes these appear as alternating grey blobs and distinct images.

    It's only a problem if hitting sub-pixels of the rendering device. On a screen it is a problem, but on a printer it's just fine. And I'd argue that apparently Pango gives meaningful ascent and descent for the device: the screen values seems always full pixels, but the printer values are more arbitrary (probably more exact for the font/resolution).

    Though, I indeed don't know for sure if Pango gives me round pixel values for screen because it knows it should or if it's some kinda luck -- although I'm pretty confident it knows it and it's nothing like luck. And of course, I have no idea what other platform would give.

     
    • Neil Hodgson
      Neil Hodgson
      2013-05-04

      See if various rounding calculations like roundf() or floor(v+0.9) produce OK results. And try with proportional fonts since monospaced fonts are more likely to want to tile well both horizontally and vertically.

      I wouldn't want to assume that integral ascent and descent are always the case for the screen due to the diversity of Linux distributions. Most distributions ship with very conservative FreeType configurations (partly because of the patent issue) and there is some variance between distributions: Fedora and Ubuntu have different text appearances.

      Various patch sets improve font rendering and are more likely to result in fractional pixel positioning: Infinality, for example, makes a big difference to Fedora.
      http://www.infinality.net/blog/infinality-freetype-patches/
      Its difficult enough to provoke horizontal fractional positions under Pango - kerned pairs like "Te" (in a proportional font) are a simple way.

       
<< < 1 2 (Page 2 of 2)