First, you say thanks for reporting the issue: On Mon, Mar 09, 2015 at 11:17:23PM +0100, Christoph Lohmann wrote: > Thanks for reporting this. > > Sincerely, > Christoph Lohmann
Then you complain that I should send a patch with the bug: On Tue, Mar 10, 2015 at 06:39:49AM +0100, Christoph Lohmann wrote: > Why are you throwing half‐baked bug reports at me without doing any > debugging on your own? First of all, this is suckless: Bug reports > have to be opened with a patch attached. Second: Don’t reply to > yourself if you don’t have any new information in it. **Then** you say you'll look into the issue once you find some way to reproduce it: > When I find some way to reproduce the problem I will debug it as > needed. First off, the last email I sent with the xxd output included all the information you needed to debug the problem. The fact the Connor had no problem figuring out with the issue was supports this. Second, if you're going to complain about things, at least be consistent in your complaints (do you want bug reports or not?) and take the time to carefully read what's sent before saying there's not enough information. I can sympathize with misreading or misunderstanding things, just not when you insist on throwing a fit with unfounded statements. And speaking of mis(read|under)standing, I think you also misunderstood what the line issue is in the second bug I reported. It has nothing to do with Xft or the line characters in particular. The problem is that those gaps are not always there; they come and go. I'm assuming that the line-height st calculates changes in some situations when it should be constant; in other words, xw.ch(?) varies when it shouldn't. It just only happens to be noticeable with glyphs that have pixels at the very top and very bottom of the cell. The gaps would also be present if the screenshot contained "█" stacked on top of each other provided the font that displays the square completely filled the ascent+descent pixels. Eric