leading newline makes Text disappear

[ethanpailes]

Bug Description

When a string with a leading newline is passed to the Text widget, the text below that newline does not show up. It appears that this leading newline is not being included in some height computation because if there are multiple lines of text after a single leading newline, only the last line of text gets swallowed.

What did I Expect to Happen?

I would expect that leading newlines get included in the text that is displayed as well as all of the following text.

Minimal Example

use iced::{Element, Sandbox, Settings, Text};

pub fn main() {
    Bug::run(Settings::default())
}

struct Bug;

impl Sandbox for Bug {
    type Message = ();

    fn new() -> Bug {
        Bug
    }

    fn title(&self) -> String {
        String::from("A minimal repro")
    }

    fn update(&mut self, _message: Self::Message) {
    }

    fn view(&mut self) -> Element<Self::Message> {
        Text::new("\nmissing").into()
    }
}

Screenshot

Multi-line Example

use iced::{Element, Sandbox, Settings, Text};

pub fn main() {
    Bug::run(Settings::default())
}

struct Bug;

impl Sandbox for Bug {
    type Message = ();

    fn new() -> Bug {
        Bug
    }

    fn title(&self) -> String {
        String::from("A minimal repro")
    }

    fn update(&mut self, _message: Self::Message) {
    }

    fn view(&mut self) -> Element<Self::Message> {
        Text::new("\nnow it shows up\nthis guy is missing though").into()
    }
}

Screenshot

More details about my system

$ uname -a
Darwin ethanpailesmac 18.7.0 Darwin Kernel Version 18.7.0: Mon Feb 10 21:08:45 PST 2020; root:xnu-4903.278.28~1/RELEASE_X86_64 x86_64

[ethanpailes]

I think I've traced this issue to the glyph_bounds routine from the glyph_brush crate (called here). The docs for that routine say "Invisible glyphs, like spaces, are discarded during layout", so it sounds like this is working as intended upstream which suggests that this won't be fixed upstream.

It seems like there are a couple of routes forward:

1. Manually detect leading spaces and fix up the return value of glyph_bounds. Probably not ideal.
2. Strip leading and trailing whitespace from input to the Text widget so that the text that gets displayed matches up with the text we have computed the bounds for.

I'm in favor of (2), but I think I've reached the point where I need to maintainer to make the final call on a design question.

I can try to put a patch together for this once you've made a decision (or you can just go ahead and patch it yourself, I bet the fix will be pretty trivial if you decide to go with door number 2).

[hecrj]

Thanks for the detailed report and the SSCCEs! This is a really great bug report :D

The current text rendering pipeline is relatively broken (see #33 and #243 (comment)), it has many similar issues, and it will need a full rewrite/replacement in the near future.

Because of this, I believe it's better to tackle all the issues at once instead of investing time in trying to patch a broken model.