Weird hinting problem for block characters

[rr-]

I try to display a progressbar using █ characters like this: ███(change color)███.

However, it's rendered weird no matter what font or size I use:

Note how it works in urxvt properly, while it's rendered with blue tint in lemonbar. Here's my font config:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match target="font" >
        <edit mode="assign" name="rgba" >
            <const>rgb</const>
        </edit>
    </match>
    <match target="font" >
        <edit mode="assign" name="hinting" >
            <bool>true</bool>
        </edit>
    </match>
    <match target="font" >
        <edit mode="assign" name="hintstyle" >
            <const>hintslight</const>
        </edit>
    </match>
    <match target="font" >
        <edit mode="assign" name="antialias" >
            <bool>true</bool>
        </edit>
    </match>
    <match target="font">
        <edit mode="assign" name="lcdfilter">
            <const>lcddefault</const>
        </edit>
    </match>

    <!-- Reject bitmap fonts -->
    <selectfont>
        <rejectfont>
            <pattern>
                <patelt name="scalable"><bool>false</bool></patelt>
            </pattern>
        </rejectfont>
    </selectfont>
</fontconfig>

[rr-]

Trying to do specify fonts like this:

Literation Mono Powerline:pixelsize=13:hintstyle=hintnone:antialias=false:rgb=none:hinting=none

doesn't seem to help. (I believe these options don't work in this context...)

[rr-]

Confirmed that disabling antialias in font config removes this issue. However, it screws ups every other font and every other character. Is it possible to specify antialias settings in lemonbar's -f?

[krypt-n]

I was able to reproduce it using lcdfilter. Top is lcdfilter = lcdnone Bottom is lcdfilter = lcddefault

Is it possible to specify antialias settings in lemonbar's -f?

I dont think so.

[rr-]

Yeah, but after disabling it system-wide, everything looks like this:

Making an exception using <test/> in font config for one font isn't greatest either.

[krypt-n]

I will look into how urxvt handles that

[rr-]

Please note that urxvt uses .Xresources which is separate from font config. However, I can see the blocks render just fine also in Firefox, and Firefox does use font config - otherwise I wouldn't be able to obtain the screenshot above (which happened after changing font config).

[rr-]

If I change the call to XftDrawString16 to draw more than just one character at a time, it works fine. Perhaps there's something wrong with "gluing" the characters? Anyway, a quick fix would be to change draw_char and ifs before to a while that collects all consecutive UTF8/ASCII characters that do not belong to any %{Command}, and then pass whole such string to XftDrawString16.

[easysid]

Is there a fix coming for this?

FWIW, a workaround for this is to use a bitmap font to draw the box characters, using %{T}. Bitmap fonts seem to render fine.

[krypt-n]

Well #12 fixes this. I would really like to integrate it and the ucs branch into the main branch, however I am not using lemombar anymore and did not invest much time into it over the last year.

Do you think people use the xft-fork to render bitmap fonts? Would be a huge simplification to just remove the bitmap code.

[easysid]

12 would probably suffice for my use case, which is just generating simple blocks.