Merge consecutive ASCII and UTF8 strings

[rr-]

Should fix #9 but might regress things when it comes choosing font for different glyphs.

[rr-]

Best viewed with ?w=1: https://github.com/rr-/bar/commit/12aed99e76e415a8ba65b4321ded1b36208673b8?w=1

[krypt-n]

Did you test this with a %{Something} between the █s? I think that this doesnt fix the hinting problem if the █ are not consecutive in the lemonbar input.

[rr-]

It doesn't, but I think it's good enough as it is.
The other way to fix it would be to fiddle with xft settings, but I'm not familiar with it very much and I'm not sure it's going to lead us anywhere...

[krypt-n]

After reading through the Xft source, I think that there is no way for us to call a correct function, that renders a single char correctly since Xft just calls xrender.
And I'm with you that trying to find better fontconfig settings won't help us.

However the approach in this PR has two problems (the one mentioned above and when using automatic fallback fonts I think) and it'd be an additional change to the xcb code, making merging commits from lemonboy's version harder.

I propose a different approach:
We add a global (yes, yes I know) buffer of XftGlyphFontSpecs. Everytime we'd call XftDrawString in this version we push a new glyph + font into the buffer. If we change the color or reach the end of parse, we flush the buffer by drawing the glyphs.
This would result in correct rendering in the two edge cases mentioned above and wouldnt change the xcb drawing code.

[rr-]

It makes sense to me (including the part about global variables). Do you want me to implement it? (If I was to implement it, it'd have to wait till tomorrow.)

[krypt-n]

You could give it shot if you want to. I probably won't have time for it either until tomorrow.

[rr-]

Roger, will send another PR soonish

[rr-]

Actually... this seems like a lot of work and additional bookkeeping, even more than this PR introduces, due to the fact that draw_char renders some rectangles that end up covering text that is later drawn by aforementioned "flushing".

[rr-]

Additionally, X and Y don't seem to be computed only in X and Y variables. Looks like there are some corrections applied when copying bitmaps from backbuffer with regard to current text alignment.

IOTW doing things this way is nasty, IMO much nastier than the changes above.

[krypt-n]

due to the fact that draw_char renders some rectangles that end up covering text that is later drawn by aforementioned "flushing".

Do you mean the over/underlines? They shouldnt touch the font if the height is set correctly.

Additionally, X and Y don't seem to be computed only in X and Y variables. Looks like there are some corrections applied when copying bitmaps from backbuffer with regard to current text alignment.

Indeed, I didnt think about this one.

So this PR fixes the green lines everywhere in your bar or are there some left (like when changing fonts or color)?

[rr-]

Over/underlines

Hm, that must be probably it.

Green lines when changing fonts/color

There are such lines, but they look nice and probably should be there due to lcdfilter:

PNG zoomed to 300% with nearest neighbour, so no artifacts.

[rr-]

So what do we do?

[krypt-n]

I will merge this, maybe with some small changes, I just didnt have a lot of time to look at it today

[rr-]

Lost interest