Letter spacing in slideshow

[David Christiansen]

I'm in the process of learning slideshow, and it's tons of fun! I vastly
prefer Racket to LaTeX for algorithmically generating slides :-)

However, I'm encountering a pretty major issue with font rendering. I'm
running Racket 6.3 under GNOME 3.16 on Linux.

I have noticed that, with a number of fonts, lowercase letters following
a capital T are drawn very close to the T. My understanding is that
Racket uses GTK, Pango, and Cairo to draw, so I tested it out in gedit
with the same font, as well as XeTeX.

At https://imgur.com/a/BVi2r, you can see the results. The first
screenshot is from slideshow, where the word "Types" looks very odd
compared to the other two, which have roughly the same layouts. Some
other letter spacings are also a bit compressed, but none as radically
as "Ty".

Is this a misconfiguration on my part? A bug in Racket somewhere? Can
anyone suggest a work-around?

Thanks in advance!

/David

[Matthew Flatt]

Letter spacing there certainly does look wrong. While "Ty" is the most
obvious problem, "Pr" and "Re" look too closely spaced, also. It
appears that spacing is going wrong for kerning pairs, and not for
other pairs of letters.

You're correct that Racket defers to Pango and Cairo to kern and draw
text. One possibility is that something is going wrong with using a
font at size N with a drawing scale of M (as opposed to using a font of
size N*M and a drawing scale of 1). Slideshow is likely using a value
of M other than 1, and other programs seem unlikely to be using a
drawing scale. In particular, as I recall, you have a high-resolution
display, which means that Slideshow will render to a bitmap with a
backing scale of 2, and likely an additional drawing scale to stretch
the 1024x768 slide dimensions to fit your screen.

To help diagnose the problem, could you perform experiments along those
lines at the level of a `bitmap%` and `bitmap-dc%`? The key is to call
`draw-text` with #t as the fourth argument, which enables kerning. You
could create a bitmap with different backing scales and also use
different drawing scales (as set by the `scale` method of `dc<%>`, for
example).

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Christiansen]

I seem to have clicked "Reply" rather than "Reply list" - sorry for the
duplicate email, Matthew!

--------------------------

Thanks so much for a quick answer! Sorry it took me a bit to get back, I
had to go read up on the relevant APIs.

I've managed to cause the problem at the REPL, and it does seem to be
dependent on the backing scale.

Here's my test program:

#lang racket

(require racket/gui)

(define (get-bitmap backing-scale) (make-object bitmap% 500 300 #f #f
backing-scale))

(define (test backing-scale kern?)
(let* ((bitmap (get-bitmap backing-scale))
(dc (new bitmap-dc% [bitmap bitmap])))
(send dc set-font (make-object font% 100 "PT Sans Narrow" 'default))
(send dc draw-text "Types" 0 0 kern?)
bitmap))

And here's what I get when I evaluate the following at the REPL:
(for*/list ([scale (list 1.0 2.0)] [combine (list #f #t)]) (list scale
combine (test scale combine)))

https://imgur.com/Sj2qhOp

It seems that the problem occurs with kerning enabled, but a backing
scale of 2.0.

Any ideas on how I can work around this?

Thanks again!

/David

[Matthew Butterick]

A clue, perhaps, to tracking down the problem: It appears that the pairs that are being compressed — Pr, Re, Ty — are all pairs that have kerns applied (i.e., pair-specific spacing). Moreover, it looks like a systemic error in rendering the kerning (e.g., kern is being doubled) — notice how the pair with the biggest kern, Ty, also has the biggest collision.

[Matthew Butterick]

Whoops sorry, didn't see MFlatt's diagnosis.

[Matthew Flatt]

The problem appears to be fixed in Pango 1.37:

https://bugzilla.gnome.org/show_bug.cgi?id=700592

Is upgrading your Pango installation a possibility?

Otherwise, `racket/draw` could can probably work around this problem,
much the same as

https://mail.gnome.org/archives/commits-list/2014-May/msg06383.html

but it would be a little complicated, since scaling can come from
different layers.

[David Christiansen]

On 17/12/15 17:52, Matthew Flatt wrote:
> The problem appears to be fixed in Pango 1.37:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=700592
>
> Is upgrading your Pango installation a possibility?

That would be a pretty major disturbance for my machine - I'm a bit
hesitant to change distros right now, as the talk I'm preparing is
intended as a PhD defense!

> Otherwise, `racket/draw` could can probably work around this problem,
> much the same as
>
> https://mail.gnome.org/archives/commits-list/2014-May/msg06383.html
>
> but it would be a little complicated, since scaling can come from
> different layers.

What about working around it by making slideshow's instances of
racket/gui think that I'm not on a high-res display, so that it uses 1.0
as the backing scale? I've tried setting GDK_SCALE=1 and
GDK_DPI_SCALE=1, but I still see the issue.

Is there some other setting, or command line option, or even some
variable that I can set! to change the backing scale?

Thanks for the help!

/David

[Matthew Flatt]

At Thu, 17 Dec 2015 18:30:51 +0100, David Christiansen wrote:
> On 17/12/15 17:52, Matthew Flatt wrote:
> > The problem appears to be fixed in Pango 1.37:
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=700592
> >
> > Is upgrading your Pango installation a possibility?
>
> That would be a pretty major disturbance for my machine - I'm a bit
> hesitant to change distros right now, as the talk I'm preparing is
> intended as a PhD defense!

It might work to drop a repaired "libpangocairo.so" into the "lib"
directory of your Racket installation. I'll see if I can build one,
just to see how hard that is. :)

> What about working around it by making slideshow's instances of
> racket/gui think that I'm not on a high-res display, so that it uses 1.0
> as the backing scale? I've tried setting GDK_SCALE=1 and
> GDK_DPI_SCALE=1, but I still see the issue.

You could set PLT_DISPLAY_BACKING_SCALE=1, but I think that won't help,
because Slideshow will still scale the content to match the screen size
(so it should arrive at the same overall scale factor).

Can you set your laptop's screen to 1024x768 resolution? Then there
would be no scaling. It seems like that might happen anyway when
connecting to a projector, but I don't know well enough how changing
the display works with Unix/X.


In another direction, you could disable kerning by adjusting your font
description to include 'no-combine:

(parameterize ([current-main-font (cons 'no-combine (current-main-font))])
(slide
(para "Types")))

[Matthew Flatt]

At Thu, 17 Dec 2015 10:52:02 -0700, Matthew Flatt wrote:
> At Thu, 17 Dec 2015 18:30:51 +0100, David Christiansen wrote:
> > On 17/12/15 17:52, Matthew Flatt wrote:
> > > The problem appears to be fixed in Pango 1.37:
> > >
> > > https://bugzilla.gnome.org/show_bug.cgi?id=700592
> > >
> > > Is upgrading your Pango installation a possibility?
> >
> > That would be a pretty major disturbance for my machine - I'm a bit
> > hesitant to change distros right now, as the talk I'm preparing is
> > intended as a PhD defense!
>
> It might work to drop a repaired "libpangocairo.so" into the "lib"
> directory of your Racket installation. I'll see if I can build one,
> just to see how hard that is. :)

Assuming that you're on 64-bit Linux, here is a set of libraries to
try:

http://www.cs.utah.edu/~mflatt/tmp/pango-1-37-libs.tgz

Unpack in some directory <dir>, and run

env LD_LIBRARY_PATH=<dir> racket ....

To avoid setting `LD_LIBRARY_PATH`, you could probably adjust rpaths in
the ".so" files an install into Racket's library search path, but I
didn't try that.

[David Christiansen]

> It might work to drop a repaired "libpangocairo.so" into the "lib"
> directory of your Racket installation. I'll see if I can build one,
> just to see how hard that is. :)

I made the problem go away by building libpango from source and putting
the just-built libpango, libpangocairo, libpangoxft, and libpangoft
libraries into LD_PRELOAD. I can definitely make a shell script that
does this before launching slideshow as a temporary workaround.

Building libpango from scratch was really easy - download, extract,
./configure, make.

This looks like it will work! Thanks!

>> What about working around it by making slideshow's instances of
>> racket/gui think that I'm not on a high-res display, so that it uses 1.0
>> as the backing scale? I've tried setting GDK_SCALE=1 and
>> GDK_DPI_SCALE=1, but I still see the issue.
>
> You could set PLT_DISPLAY_BACKING_SCALE=1, but I think that won't help,
> because Slideshow will still scale the content to match the screen size
> (so it should arrive at the same overall scale factor).

This doesn't fix it, unfortunately, as you predicted.

> Can you set your laptop's screen to 1024x768 resolution? Then there
> would be no scaling. It seems like that might happen anyway when
> connecting to a projector, but I don't know well enough how changing
> the display works with Unix/X.

Setting it to 1024x768 fixes the text display, consistent with
expectations. I'm not confident that I can run our projectors at
precisely that resolution, however, so I don't want to rely on that
specifically! But I think the LD_PRELOAD hack is good enough for what I
need it to do, and I'll test extensively beforehand for stability.

> In another direction, you could disable kerning by adjusting your font
> description to include 'no-combine:
>
> (parameterize ([current-main-font (cons 'no-combine (current-main-font))])
> (slide
> (para "Types")))

That makes it ugly, but not quite as ugly as the over-the-top kerning.
I'll keep it in mind in case the LD_PRELOADed libpango causes some other
issue, as a potential last-minute fix if I've invested all my prep time
into an interactive Racket-Idris-slideshow thing that I don't have time
to replace at the last minute, and my other machine running stretch
doesn't work for some reason.

Thanks so much for fast and effective support turn-around! I really
appreciate it, and the sinking feeling in my gut has left.

/David

[David Christiansen]

> Assuming that you're on 64-bit Linux, here is a set of libraries to
> try:
>
> http://www.cs.utah.edu/~mflatt/tmp/pango-1-37-libs.tgz
>
> Unpack in some directory <dir>, and run
>
> env LD_LIBRARY_PATH=<dir> racket ....
>
> To avoid setting `LD_LIBRARY_PATH`, you could probably adjust rpaths in
> the ".so" files an install into Racket's library search path, but I
> didn't try that.

I can confirm that this works just as well as my own build of
libpango-1.38, including that LD_LIBRARY_PATH works instead of
LD_PRELOAD, as one would expect.

Thanks again!

/David