background color and centering, how to?

[x37v]

I'm drawing to a display that doesn't seem to perfectly match any of the font size options you've provided so I get some extra borders around my terminal that are drawn white. I have a few questions regarding that.

1. is there a way to make this area black instead of white
2. is there a way to adjust the centering of the drawn area, it looks like if i shifted everything up and right 1 pixel it would be centered better.

Maybe I'm just configuring something incorrectly?

here is how i'm drawing (copied from your examples)

let text = "Ratatui on embedded devices!";
let paragraph = Paragraph::new(text.white()).wrap(Wrap { trim: true }).on_black();
let bordered_block = Block::bordered()
	.border_style(Style::new().white())
	.title("Mousefood");
frame.render_widget(paragraph.block(bordered_block), frame.area());

here is how i setup my terminal

let config = EmbeddedBackendConfig {
	flush_callback: Box::new(move |d: &mut MoveDisplay| { 
          draw_tx.send(DrawCommand { data: d.framebuffer().clone() }).unwrap();
	}),
	font_regular: mousefood::fonts::MONO_5X8,
	font_bold: mousefood::fonts::MONO_5X8,
	..Default::default()
};

let backend = EmbeddedBackend::new(&mut display, config);
let mut terminal = ratatui::Terminal::new(backend).expect("to create terminal");

[x37v]

a follow up, is the drawing area completely determined by the font size and display size?

for instance, my display is 64 pixels high and 128 wide, so does that mean that my 5x8 font should actually cover the vertical area and then have 3 extra pixels on one side because 64 % 8 = 0 and 128 % 5 = 3

[j-g00da]

Thanks for interest in mousefood!

is there a way to make this area black instead of white

You can clear the display before initializing the backend:

// (change Rgb565, to the color your display uses)
display.clear(Rgb565::BLACK)?;

is there a way to adjust the centering of the drawn area, it looks like if i shifted everything up and right 1 pixel it would be centered better.

This is not currently supported directly, but you may be able to hack it a little depending on what driver crate you use. For example with mipidsi, you can use .display_offset(x, y) when building the display, to shift all pixels.

a follow up, is the drawing area completely determined by the font size and display size?

Exactly, it just draws as many characters as it can fit.

By the way, are you running it on Korg Monologue? That display looks familiar. :)

[j-g00da]

You can also use ibm437 font, which is exactly 8x8 (but it supports much less characters).

[x37v]

Exactly, it just draws as many characters as it can fit.

By the way, are you running it on Korg Monologue? That display looks familiar. :)

hmm, i wonder what accounts for the white area i'm seeing at the top of the display?

It isn't a Monologue though maybe the device (not naming just yet) uses that same display?

[x37v]

This is not currently supported directly, but you may be able to hack it a little depending on what driver crate you use. For example with mipidsi, you can use .display_offset(x, y) when building the display, to shift all pixels.

i wrote my own custom driver for this display, it has a bespoke SPI protocol so, i can hack the offset as needed

[j-g00da]

hmm, i wonder what accounts for the white area i'm seeing at the top of the display?

i wrote my own custom driver for this display, it has a bespoke SPI protocol so, i can hack the offset as needed

Maybe your origin is off, try to draw a single pixel at (0,0) using embedded-graphics directly and check where it is. If it's shifted, you just have to hardcode some offset.

It isn't a Monologue though maybe the device (not naming just yet) uses that same display?

I think Prologue used exactly the same screen as Monologue. Now I'm curious what it is. :)

[x37v]

I am able to render to the top left corner (0,0) using embedded_graphics directly and I'm still getting the white bar even if I draw black to the display before giving it to the backend, so I assume this is a bug? The font here is 5x8 and my display is 64 pixels high..

[x37v]

it is worth noting that i'm using the latest release on crates.io, 0.2.1

[j-g00da]

Yes this is indeed a bug then, thanks for reporting that!

[x37v]

Yes this is indeed a bug then, thanks for reporting that!

I've resolved it against 0.2.1, at least for this very simple drawing.. just have to figure out how to build against the main branch and then I can do a PR

[j-g00da]

Thanks! The main thing that changes will be the fact that ratatui is not re-exported, so you will have to add a dependency on ratatui 0.30.0-alpha.4 in your project and disable default features for it.

[x37v]

Thanks! The main thing that changes will be the fact that ratatui is not re-exported, so you will have to add a dependency on ratatui 0.30.0-alpha.4 in your project and disable default features for it.

great! RE the background color, it looks like the backend likely clears via this:

    fn clear(&mut self) -> Result<()> {
        self.buffer
            .clear(TermColor(style::Color::Reset, TermColorType::Background).into())
            .map_err(|_| crate::error::Error::DrawError)
    }

is there some way to set the Reset color for the terminal? it looks like if no.. the fallback goes to white for binary

impl From<TermColor> for BinaryColor {
    fn from(color: TermColor) -> Self {
        match color.0 {
            Color::Black => BinaryColor::Off,
            Color::White => BinaryColor::On,
            // Fallback
            _ => match color.1 {
                TermColorType::Foreground => BinaryColor::Off,
                TermColorType::Background => BinaryColor::On,
            },
        }
    }
}

[j-g00da]

You are right, Reset should resolve to On for foreground and Off for background.