Extra line on notifications of certain length

[gergesh]

Can be seen here

My configuration:

[global]
    font = "Droid Sans 8"
    allow_markup = yes
    format = "<b>%s</b>\n%b"
    sort = yes
    indicate_hidden = yes
    alignment = center
    bounce_freq = 0
    show_age_threshold = 60
    word_wrap = yes
    ignore_newline = no
    geometry = "200x5-6+52"
    transparency = 0
    idle_threshold = 120
    monitor = 0
    follow = mouse
    sticky_history = yes
    line_height = 0
    separator_height = 2
    padding = 8
    horizontal_padding = 8
    separator_color = "#585858"
    startup_notification = false

Installation info

• Version: 1.4.0 (2019-03-30)
• Install type: Package
• Distro and version: Arch

[tsipinakis]

This looks like #620 but not quite as you're not using dynamic width.

As with #620 I couldn't reproduce this neither in Debian nor in an Arch VM.

The the same questions I asked there apply:

• Does reverting to 1.3 fix this?

• Can you run a git bisect to determine the commit that broke it?

[gergesh]

I reverted to v1.3, v1.2.0-173-g0c8d3a4 and v0.5.0-105-ga1374ff, all of them have this issue.

Edit: I tried some more stuff and it's possible (probable) that my setup was broken, however properly downgrading to 1.2.0 and 1.3.1-1 via the archive did not solve the issue.

Edit 2: I tried again, when I disable horizontal_padding the issue goes away.

Edit 3: No, mistaken once again. The only way I was able to make it go away is by using the default font. A config of

[global]
    font = "Droid Sans 8"
    geometry = "200x5-6+52"

fails with notify-send "Test" "Let's all have a swig and do a hot"

[tsipinakis]

Reproduced on Arch with DPI set to 114.

I traced the code for a bit and my assumption is that this is something to do with pangocairo pango_layout_is_wrapped() returns true which most likely means pango is thinking that another line is needed when it isn't

I can't reproduce this on Debian but can in Arch, even if I downgrade Arch to pango 1.42.4 which is the version that's also in debian the problem is still there, weird.

Did this start happening recently with some update or was this that probably existed before?

I'll try to dig more and write something to reproduce this effectively before reporting it to pangocairo.

[gergesh]

I'm pretty sure it was always there (well, at least for the couple of years I've been using dunst)

[stefanhusmann]

I think this problam appeared in version 1.4.0, falling back to 1.3.2 solves it for me.

[tsipinakis]

@stefanhusmann Between 1.3 and 1.4 we changed to dynamically calculate DPI instead of assuming it's 96. Does running

echo "Xft.dpi: 96" | xrdb - merge

And restarting dunst fix this for you?

See also #620 I'm still trying to find out if these 2 are related.

[stefanhusmann]

No, setting Xft.dpi to 96 does not change anything.

I know #620, maybe I should have left my comment there?

[stefanhusmann]

Edit: my xrdb does not understand the parameter "merge", but without it, the problem goes away.

[fwsmit]

Is this issue still reproducible in the latest version of dunst.