dnkl changed the topic of #foot to: Foot - fast, lightweight and minimalistic Wayland terminal emulator || 1.22.0 || https://codeberg.org/dnkl/foot || channel logs: https://libera.irclog.whitequark.org/foot
raiguard has quit [Changing host]
raiguard has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
__jmcantrell__ has quit [Ping timeout: 260 seconds]
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
ubq323 has quit [Ping timeout: 276 seconds]
__jmcantrell__ has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
__jmcantrell__ has quit [Ping timeout: 248 seconds]
boomboxnation has joined #foot
an3223 has quit [Remote host closed the connection]
an3223 has joined #foot
trygveaa has quit [Ping timeout: 248 seconds]
__jmcantrell__ has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
krobelus has quit [Ping timeout: 272 seconds]
trygveaa has joined #foot
krobelus has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
dutchie has quit [Remote host closed the connection]
dutchie has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
azerov has quit [Quit: Gateway shutdown]
azerov has joined #foot
<dnkl> I'm considering disabling gamma-correct blending by default
<dnkl> it seems 8-bit surfaces don't provide enough precision
<dnkl> several users have reported colors being off, and I think this can mostly be traced to precision
<dnkl> since 10-bit surfaces are way too slow, I don't want to enable them by default
<dnkl> thus, the choice is between having gamma-correct blending, but wrong colors, or correct colors but no gamma-correct blending
<dnkl> thoughts?
<dnkl> (fwiw, even 10-bit isn't quite enough)
<dnkl> (and wayland SHM and pixman don't have any higher precision FP types in common)
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
__jmcantrell__ has quit [Ping timeout: 248 seconds]
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
dnkl has quit [Remote host closed the connection]
dnkl has joined #foot
<toast> if I had to pick between correct colors and gamma-correct blending I would tend to pick correct colors tbh
kode540 has joined #foot
kode54 has quit [Ping timeout: 244 seconds]
kode540 is now known as kode54
<dnkl> yeah... I'm guessing most people will. I'd pick gamma-correct blending myself.
cbb has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
jutty has quit [Ping timeout: 276 seconds]
ubq323 has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
jutty has joined #foot
boomboxnation has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
alexherbo2 has joined #foot
chimo has quit [Ping timeout: 260 seconds]
chimo has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
__jmcantrell__ has joined #foot
<dnkl> re. gamma-correct blending: https://codeberg.org/dnkl/foot/pulls/2041 changes the default to disabled
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
alexherbo2 has quit [Remote host closed the connection]
jmcantrell is now known as Guest2958
Guest2958 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
__jmcantrell__ is now known as jmcantrell
jmcantrell_ has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
an3223 has quit [Remote host closed the connection]
an3223 has joined #foot
Guest46 has joined #foot
<Guest46> Hi, I am looking into an issue I am having with foot:
<Guest46> Using the Commit Mono font (which maybe has narrow horizontal spacing?), the following standard unicode character gets cropped/clipped: ◯ (U+25EF, LARGE CIRCLE).
<Guest46> I have read through the FAQ troubleshooting (https://codeberg.org/dnkl/foot/wiki#cut-off-glyphs) but it seems to indicate that this issue should no longer be.
<Guest46> This does not happen with this font: `font=Hack Nerd Font Mono:size=15'. There the circle icon is much smaller and fits into the cell.
<Guest46> This is the config I use to reproduce this:
<Guest46> ```
<Guest46> [main]
<Guest46> dpi-aware=yes
<Guest46> font=CommitMono:size=9, Symbols Nerd Font Mono:size=8
<Guest46> [tweak]
<Guest46> overflowing-glyphs = true
<Guest46> ```
<Guest46> As said, this icon is not part of Nerd fonts and the reduced sizing in the config does not work.
<Guest46> If anyone has any advice or help to give I would be very grateful, I have been investigating this for a while but I cannot manage to fix it.
<Guest46> Could it be a problem with the font itself?
<dnkl> Guest46: I would guess that codepoint isn't part of either font
<Guest46> Oh, I see, so it falls back to a default font on my system? It must be part of the Hack Nerd font then as it displays it correctly?
<Guest46> Isn't that unusual for Commit Mono to not include it as its a standard unicode ? I have no experience with fonts tbh
<Guest46> Thanks for your help! I think I'll look into how Commit Mono does it itself, maybe its got nothing to do with foot in the end
<dnkl> Guest46: you can run foot with -d info, and it'll log which fonts it's loading
<dnkl> if you see it logging a new font when you paste that symbol, you'll know where it gets it from
<dnkl> otherwise it's in one of the already loaded fonts
<Guest46> Testing on https://www.programmingfonts.org the circle icon is very large (which makes me think it coming from `Commit Mono` in foot), but it gets displayed correctly by overflowing into the neighboring cells. Foot allows nerdfont icons to overflow, but maybe it doesn't allow it for standard unicode ?
<Guest46> Oh ok, I will try that
<Guest46> I am not getting any logs from pasting or running  with `foot -d info` or do you mean logging to a file, not stdout ?
<cbb> Guest46: the logs are the same either way
<cbb> FWIW, I saw '/usr/share/fonts/TTF/DejaVuSansMono.ttf' loaded when pasting "◯", before I installed Commit Mono
<cbb> and no log messages on paste, after installing it
<Guest46> Thanks for checking! Yes I am not getting any log on paste either with Commit mono.
<Guest46> Reading through this related PR from 1.8.2 : https://codeberg.org/dnkl/foot/pulls/592
<Guest46> The first message says:
<Guest46> " To keep things simple, bleeding into any other neighbor cell than the immediate right one is
<Guest46> not allowed"
<Guest46> The icon is being cropped into the left! Could it be that this is not covered by foot? I am not sure where the implementation stands now
<Guest46> cbb : do you also get the clipping with this font?
<cbb> Guest46: with that font, yes
<cbb> it has a glyph for U+25EF, FWIW
<cbb> according to font-manager
<dnkl> Guest46: correct, foot only supports left to right bleeding. Not right to left, and no vertical bleeding
<dnkl> you might find https://codeberg.org/dnkl/foot/issues/2015 interesting.
<Guest46> Ah I see! Thanks a lot for the info!
<Guest46> cbb: yes I found the glyph on their website but I cannot link to it directly sadly. It leaks to both sides by design! So the right bleeding is rendered in foot, but the left is getting cropped.
<aelius> The more I learn about font rendering, the crazier it seems
<aelius> the suggested solution of "treat codepoints as double width" is what leads alacritty to fail at rendering TUIs in certain contexts, iirc
<aelius> because double is too much, now rendering columns is borked
<Guest46> dnkl: ahah this Issue is perfectly fitting indeed!
<Guest46> Maybe I should give up this font then, as it ships with overflowing standard characters.. Sad as I was really starting to enjoy it.
<Guest46> From the Issue: "1 is better solved with the text-sizing protocol (by setting an explicit width)"
<Guest46> So is that potentially some metadata that could be added to the font and then foot could render it fully ?
<cbb> in Unicode's EastAsianWidth.txt, U+25EF is marked as "A" (ambiguous width)
<cbb> the codepoint mentioned in that comment is also ambiguous width
<cbb> the text-size protocol is a recent Kitty innovation that allows the client to specify dimensions for the terminal to use
<Guest46> Wow there is so much details to it aha! Thanks a lot for the links, I think I understand better where all that comes from now
<Guest46> But with text-size protocol, one double width glyph will space out all characters currently displayed to maintain alignment ?
<cbb> it depends what you mean by "alignment"
<cbb> if you mean alignment as in the client and the terminal having the same notion of where the cursor is, that's not a problem
<cbb> because the client requests a specific width and the terminal adheres to it
<Guest46> Like if I have a Markdown table, the column glyphs should not be broken by a double width glyph, so characters of other lines get spaced out too ? Which does make sense, I was just wondering
<Guest46> (The column alignment over multiple lines should not be broken)*
<cbb> I guess that aspect would vary by editor
<Guest46> Ok I see, thanks!
<Guest46> All that makes me want to use a font that is respectful and strictly not overflowing.. I like compliant and simple things :)
<Guest46> Although I understand why the designers made those choices ofc
<Guest46> Do you know any font that does not overflow ?
<cbb> as mentioned in that last comment I linked, both monospace fonts and the Unicode standard kind of disregard the terminal model of things
<cbb> there's a comment somewhere in the Unicode spec to that effect
<Guest46> Ohh ok, so there's really no easy solution to this. Is there no font that guarantees no overflowing even for glyphs that are specced to be variable width ?
<Guest46> In that the case I will just continue to use Commit mono and replace overflowings glyphs manually when they come up.
<aelius> where I observed the problem with alacritty was in terminal irc clients- emoji are commonplace in bridged channels (even in nicks), and scrolling the backlog resulted in pretty unpredictable mangling of the tui in general
<cbb> I use Inconsolata personally, but it does have issues with the ambiguous width codepoint
<cbb> codepoints*
<cbb> I don't think there's a good solution to that, outside of apps using explicit text sizing
<Guest46> I see, thanks! I will look into that
<cbb> Inconsolata seems fine for other codepoints though
<Guest46> In theory it should be possible to take a font and scale all overflowing glyphs down to generate a nice and compliant font right? (I really should not go deeper into that rabbithole aha)
<Guest46> Maybe only for the standard chars, but in theory even for all nerdfont icons etc ?
<cbb> hmm, seems like Inconsolata has quite limited coverage, so I think the ambigous width issues I've seen were actually in a fallback font (Noto Sans Mono)
<cbb> Guest46: yeah, the idea of scaling popped into my head too... haven't given it much thought though
<cbb> can't remember if dnkl mentioned it in any of those old issues, but he's the person to ask about that subject
<Guest46> IMO Its nicer to have a small smiley instead of a cropped one, or mixed up columns
<cbb> there's still the issue of cursor sync. between client and terminal though, regardless of what the terminal does by default
<cbb> ambigous width can be interpretted as either 1 or 2 columns
<cbb> and if they aren't in agreement, the cursor can get out of sync
<cbb> that's the difficult part to solve
<cbb> does the client query the terminal for every codepoint?
<cbb> the Kitty text sizing protocol takes the pragmatic approach of letting the client decide
<cbb> so there's a single source of truth
<cbb> and no request/reply overhead
<Guest46> Hmm I see, I don't know much about the programming model of terminals
<Guest46> But if the font is pre-scaled to one cell, the client and terminal can just always interpret an ambiguous as a single cell ?
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
<cbb> https://www.unicode.org/reports/tr11/#:~:text=without%20appropriate%20tailoring
<cbb> "The East_Asian_Width property is not intended for use by modern terminal emulators without appropriate tailoring on a case-by-case basis"
<cbb> "Their default width property is considered ambiguous and needs to be resolved into an actual width property based on context"
<cbb> assuming single or double width might be viable for U+25EF, if everyone agrees to do the same thing
<cbb> but I think some of the other codepoints aren't so straight forward
<Guest46> Ok, complexities. Do you know if foot resolves it dynamically or always crops to one cell ?
<cbb> oh I forgot to mention before, foot already supports the width part of kitty's text sizing protocol
<cbb> I'm not sure exactly how it's handled in foot tbh
<cbb> double width: 🌲 ambigous width: ◯
<cbb> the ambiguous one is a single column when selected
<Guest46> Hmm I see
<Guest46> So the scaling would only be needed for ambiguous width chars
<cbb> for single codepoints, yeah
<cbb> there are some other Unicode horrors though, haha
<cbb> like zero-width zoiner sequences
<cbb> and to a lesser extent, variation selectors
jmcantrell has quit [Ping timeout: 248 seconds]
jmcantrell_ is now known as jmcantrell
<cbb> those are the 3 things that come to mind, where explicit text sizing is of most benefit
<cbb> FWIW, Unicode has a definition for what it means by "context": https://www.unicode.org/reports/tr11/#Ambiguous
<cbb> "The term context as used here includes extra information such as explicit markup, knowledge of the source code page, font information, or language and script identification"
<cbb> which explains why there's no easy solution
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
<Guest46> wow ok, that must open the door to many edge cases
<Guest46> I have to go, but it was nice chatting and thanks for the help!
<cbb> Guest46: no worries
<cbb> printf 'Def: \u25EF\nw=1: \e]66;w=1;\u25EF\e\\\nw=2: \e]66;w=2;\u25EF\e\\\nw=3: \e]66;w=3;\u25EF\e\\\n'
cbb has quit [Quit: cbb]
chiselfuse has quit [Ping timeout: 264 seconds]
chiselfuse has joined #foot
orahcio has joined #foot
Guest46 has quit [Quit: Client closed]
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
__jmcantrell__ has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
__jmcantrell__ has quit [Ping timeout: 248 seconds]
hexa- has quit [Quit: WeeChat 4.4.3]
hexa- has joined #foot
boomboxnation has quit [Read error: Connection reset by peer]
boomboxnation has joined #foot
rcf has quit [Quit: WeeChat 4.4.2]
rcf has joined #foot