Bugs with Multiple Width Glyphs

[benoitlx]

Hi,

I’m trying to port a Ratatui project to the web using Ratzilla (see feat-ratzilla), but I’m seeing a weird display issue with Japanese Unicode characters.

As shown in the screenshot below, the problematic characters take more horizontal space than the others, which causes a visual glitch when the following character is printed. At first I suspected a variable‑width font issue (I’m using the default index.html from the Ratzilla README), but that doesn’t explain the second screenshot.

Home Page (ratzilla)

Home Page (ratatui)

Hiragana Page (ratzilla)

Hiragana Page (ratatui)

NOTE: The issue persists with CanvasBackend and WebGl2Backend. (though japanese char are not rendered with the last one)

I’d appreciate any pointers for debugging this visual issue (I have no experience with WASM or the web).

Also thank you for this awesome project !

[benoitlx]

Update: I will try to use a custom WebGl2Backend with a custom font atlas (using WebGl2BackendOptions and AtlasFontGenerator from beamterm-atlas)

[benoitlx]

The issue persists with WebGl2Backend.

For reference, I did the following to load japanese characters with WebGl2Backend:

• cargo install beamterm-atlas
• beamterm-atlas --check-missing --emoji-font "" -r 0x3042..0x30F4 "DejaVu Sans Mono"

static ATLAS_BYTES: &[u8] = include_bytes!("../bitmap_font.atlas");

fn main() -> io::Result<()> {
    let webgl2_options = WebGl2BackendOptions::new()
        .fallback_glyph("@")
        .font_atlas(FontAtlasData::from_binary(ATLAS_BYTES).unwrap());
    let backend = WebGl2Backend::new_with_options(webgl2_options)?;

[orhun]

Hello, thanks for the issue!

This is an interesting one. Glad you fixed the problem with a custom backend.
Not sure if there is anything that we can do on Ratzilla side 🤔

cc @junkdog

[benoitlx]

I haven’t solved the issue yet 🙃 — sorry for the confusion. For now I can only display halfwidth Japanese characters using a custom atlas font with WebGl2Backend.

I agree this may be unsolvable on ratzilla’s side, so I’ll continue debugging in beamterm for now.

I inspected beamterm's atlas_generator.rs and noticed something odd:
The code assume only emoji can occupy two cells, but fullwidth japanese characters like あ also occupy two cells.

(I tried replacing if glyph.is_emoji by if true but couldn't get it to work yet.)

That being said I will open an issue in beamterm and maybe create a PR to support fullwidth glyph rasterization if I have time, as I think it will solve my issue.

[benoitlx]

I think it would be useful (at least for me) to summarize the current status:

Screenshots

	Dom	WebGl2 (using a custom atlas font)	Canvas
Home
Hiragana

Dom

The observed issues aren't from upstream (I'll open a PR with the fixes):

• Missalignement
  This is resolved using the same approach as in fix(dom): ensure consistent width for braille characters #119 :
  I recommend adding something like this for every glyph in src/backend/utils.rs

use unicode_width::UnicodeWidthStr;
format!("width: {}ch", cell.symbol().width())

• Glitch following the next character
  This likely comes from an x bug in the draw implementation of Backend for DomBackend:
  When logging (x, y, cell.symbol()) in the browser console, we see:

76 4 ア
78 4

The cell at position 77 4 is not updated (which explains why the r from the "Home" menu appears in the "Hiragana" screenshot).
I have a yet to work fix for this also.

WebGl2

• Missalignement
  None
• Truncated Glyph
  Surely an upstream issue see comment above
• Glitch following the next character
  Might be the same problem as with Dom

Canvas

• Missalignement
  None
• Truncated Glyph and Glitch
  not explored yet

[benoitlx]

Quick question (maybe long answer):
Why does ratzilla use Vec<Vec<Cell>> as two additional buffers for DomBackend and CanvasBackend instead of ratatui_core::buffer::Buffer ?

If I'm correct, the CrosstermBackend in ratatui doesn't need those two additional buffers.

I suspect that using these two buffers in the draw and update_grid functions is introducing the bug.

PS — I'm remodifying the issue title as it's not an upstream issue for DomBackend and CanvasBackend

Sorry, if I'm making a lot of noise, I'm not used to navigate big codebase like ratzilla, ratatui and beamterm 😅

[orhun]

I haven't looked at it deeply but the reason for that is backends are a bit hacky and they need some intervention in the rendering pipeline. That's why we can't use conventional types (either because they are too limiting or not compatible with what we are trying to achieve).

I suspect that using these two buffers in the draw and update_grid functions is introducing the bug.

You mean prev_buffer and buffer?

[benoitlx]

Ok makes sense

You mean prev_buffer and buffer?

Yes

Anyways, I will try to look into it more next week.

[junkdog]

You mean prev_buffer and buffer?

yeah, these aren't needed since ratatui double buffers for us and only passes the diff.

Anyways, I will try to look into it more next week.

there are a couple of assumptions in the CanvasBackend relying on the local terminal buffer; the WebGl2Backend doesn't have a buffer of its own (though it does query beamterm for copy selection iirc, so you might have to keep one buffer or work around it).

[benoitlx]

Hi,

I made some progress and fixed the issue for the DomBackend (need to update example with fullwidth glyph and test hyperlinks and cursors though).
The caveats of removing the two buffers is that I can't get the resize to work (just having the new content is not sufficient to redraw the whole frame).

Would it be possible to have a redraw or a flush_all function in ratatui_core::terminal::Terminal, that outputs content of the buffer (like flush but without diffing) ?

If we have such a function we could do something like this in the try_draw function from ratatui:

// modify slightly autoresize by returning a Res<bool, ActualError> 
// the boolean being true if the resize actually happened
let resized = self.autoresize()?;

let mut frame = self.get_frame();

render_callback(&mut frame).map_err(Into::into)?;

// We can't change the cursor position right away because we have to flush the frame to
// stdout first. But we also can't keep the frame around, since it holds a &mut to
// Buffer. Thus, we're taking the important data out of the Frame and dropping it.
let cursor_position = frame.cursor_position;

// Draw to stdout
if resized {
  self.flush_all()?;
} else {
  self.flush()?;
}

This way all the resizing is done in ratatui and we just need to update the buffer size in our backend.

Let me know what you think !