search

dvdhrm / kmscon

Linux KMS/DRM based virtual Console Emulator
http://www.freedesktop.org/wiki/Software/kmscon
Other
433 stars 81 forks source link

Vertical line advance is too short in freetype2 backend #23

Closed towolf closed 11 years ago

towolf commented 12 years ago

Using the freetype2 backend the horizontal advance looks better, but the line-spread i so short that descenders are clipped (e.g. lower bowl of a g)

dvdhrm commented 12 years ago

Could you give some setup so I can confirm this? Font, renderer etc? Or running kmscon with --fbdev and using fbgrab to get a bitmap of the display.

The freetype2 backend uses the ascender/descender as given in each font-description. I will not overwrite this, otherwise line-drawing characters like edges/lines or even mathematical multi-line integrals will look terrible.

towolf commented 12 years ago

So, it’s apparently highly dependent on the hinting mode used and the particular font.

Using the Pragmata font it’s particular egregious, which might be because it has strong TrueType instructions embedded. Unfortunately this font is not freely available.

I can see metric problems also with Ubuntu Mono and DejaVu Mono, where metrics are all inconsistent. Unfortunately it is hard to match font-size vis-a-vis my gold standard gnome-terminal. Apparently it uses points while you use pixels?

But you can tell that font rendering in Gnome Terminal is so much better, which is due to forced light hinting and FT_RENDER_MODE_LIGHT and RGBA LCD filtering.

Examples here: ftp.tuebingen.mpg.de/pub/kyb/towolf/kmscon

dvdhrm commented 12 years ago

Sorry, for non-free fonts I cannot really help you as I cannot debug this.

I use DejaVu-Mono, too and I think it looks pretty nice. Yes, I do not support sub-pixel rendering, yet, so the glyphs may look slightly different. However, gnome-terminal uses fixed DPI but kmscon will use the DPI as provided by the monitor (which is currently fixed to 72, gnome-terminal probably uses 96). So the sizes may differ between the applications. However, kmscon uses point-sizes, too.

Regarding your "dejavu-mono" examples: The pango backend looks right to me. I do not understand why you think vertical line-advance is too short? Could you be more specific what exactly is the problem with the kmscon-pango-dejavumono examples?

Sorry for the delay, I have been in San-Diego the last week for LinuxCon+LinuxPlumbers and now heading back to Tübingen.

And, regarding horizontal advance, I do the same as gnome-terminal does: Drawing all ASCII characters plus some more and measuring the maximum or average glyph-width and using this as fixed maximum width.

towolf commented 12 years ago

I have to admit I was perhaps too lazy to really look into it. When I find some time I’ll try to find out more. Maybe libvte conversely uses more advance than necessary, but I noticed immediately that the glyphs touch in some places.

The general point is that if it works with some gold standard, say libvte, it should work with kmscon too, I think.

With greetings from Schönblick.