inconsistent width on some symbols

[octoshrimpy]

The readme states the chars are 6px wide, but I found a few that are 7px wide. I'm trying to create a png without spacing for lvllvl and the inconsistency makes it difficult.

[octoshrimpy]

likewise, I found a few characters in the charmap that appear to be out of place?

[slavfox]

The readme states that the bounding box for all characters is 6x13px; some glyphs go outside the bounding box and cut into the 1px spacing between characters, and double-wide glyphs will make use of the full 13x13px.

The charmap issue is unrelated to this and is an unfortunate consequence of how combining marks are rendered and I've found no good workaround for it; combining codepoints "eat" the space before them, so they effectively render as "halfwidth".

[slavfox]

The charmap issue is resolved in 1.19.1; the bounding box is a deliberate design decision (some glyphs are just unrepresentable with only 6px of width, and some other glyphs, like line drawing characters, rely on extending past the bounding box to look correct), so I'm closing this.

[octoshrimpy]

sounds good to me, and it all makes sense. does that mean then that the font is not monospace?

[fluix-dev]

No, it does not.

[slavfox]

The bounding box is constant - 6px width (+ 1px space) means a new glyph gets drawn every 7px; this is what makes the font monospace. The width of the glyph is irrelevant - a . or i are only 1px wide, a 🐍 is 13px wide, etc; but the bounding boxes are what matters.

In a monospace font with a 4px wide bounding box where - is eight pixels wide and _ is four pixels, the sequence -_ would look like -_. It would still be a monospace font.

[octoshrimpy]

I see. I'm trying to import Cozette into aseprite to generate a png I can import into lvllvl. if I set my grid to be 7px by 13px I should be alright then. I'll post it as well for others when I get it figured out haha