Playing around with the editor-libcosmic example I encountered a crash when using word wrapping, because the first word was larger than the line. This is caused by this line https://github.com/pop-os/cosmic-text/blob/1bc198fd6306923e797dcf022439faf44c343af0/src/shape.rs#L782, because i is 0.

~After fixing that I also noticed that if a word is larger than the line, it will cause an overflow. I think almost everywhere word wrapping implies wrapping at the glyph level, if the word does not fit the line, so I believe users will expect that when using Wrap::Word.~

~Therefore I changed the ShapeLine::layout method to wrap at the glyph level (Edit: see https://github.com/pop-os/cosmic-text/pull/98#issuecomment-1456340645 and other comments in this PR), if the wrapped word does not fit the new line~.

I noticed some more issues with the current implementation:

• https://github.com/pop-os/cosmic-text/blob/1bc198fd6306923e797dcf022439faf44c343af0/src/shape.rs#L707 In the incongruent directions case this must be i + 1.
• https://github.com/pop-os/cosmic-text/blob/1bc198fd6306923e797dcf022439faf44c343af0/src/shape.rs#L782 In both direction cases this ignores the fact that the current word could be the first in the line. However, it could be that this might work regardless, but that doesn't seem obvious.
• https://github.com/pop-os/cosmic-text/blob/1bc198fd6306923e797dcf022439faf44c343af0/src/shape.rs#L738 This should be (i, 0).

~My implementation works by moving the Wrap::Glyph wrapping part behind the Wrap::Word case and executing it unless continue is used to skip it. Because the Wrap::None case is handled before the loop, we only have to deal with Wrap::Word and Wrap::Glyph so that should work.~

I've also renamed the local word_size variable to word_width for more consistency and because I think it's a more precise name.

I replaced the fetching of the previous word with a local trailing_space_width variable, which keeps track of the width of the last processed word in the current line. It is only Some(_) if we already processed a word in the current line and that word was blank.

Running the editor-libcosmic example, I get this:

There is no text rendered anywhere. Clicking on the big textfield and typing does nothing. Opening a file changes nothing. The pulldown menus and toggle buttons respond, but do nothing.

I'm on macOS 13.2.1, with M1. When I run the editor-libcosmic example, the text looks blurry compared to native text. Some time ago I head this issue with nuklear. It was related to antialiasing. (Notice also on the screenshot some symbols aren't rendered, but I'm not sure whether it's related to cosmic-text.)

This makes the std implementation of FontSystem not self-referencing, which in turn allows defining a db_mut method for mutable access to the underlying fontdb::Database (requested in #75).

The high level changes are:

• Adds a new FontKey struct that stores the fontdb::ID and (if the swash feature is enabled) the swash key data (u32, swash::CacheKey).
  • A FontKey can be obtained via the new FontSystem::get_font_key(id).
  • FontKeys are cached instead of caching Fonts.
• FontSystem::get_font now takes a FontKey instead of fontdb::ID and creates a Font on the fly, reusing the key data.
• Removes FontMatches.
  • FontSystem::get_font_matches now returns a Arc<Vec<FontKey>> instead of Arc<FontMatches<'a>>.
  • FontFallbackIter borrows fontdb::Database and creates the font on the fly using Font::from_key(db, key).

Originally I found this issue in the advanced text branch for iced. My system reports that 96.8MB is used when running. It seems like a bit much to use that much memory for just displaying some text. Iced gave memory usage of around 100MB for the checkbox example on the advanced-text branch.

I ran dhat from valgrind for iced and it seems that some parts of rustybuzz appears to be the cause of 12MB of memory usage.

I am running on Linux on aarch64.

On my system (Xubuntu), running FontSystem::new() takes a significant amount of time. On release, it takes around a second to run. On debug, it takes up to ten seconds.

There should probably be some measures taken to make sure FontSystem runs quickly. However, it should also be noted somewhere that FontSystem takes a while to load.

This allows users to use logical coordinates instead of physical ones.

These changes seem to fit naturally since fewer conversions are necessary during layouting. I left the editor module largely unchanged because I am not familiar with it, but I imagine it can be ported to logical units as well.

Previously we were calling unicode_bidi::bidi_info::visual_run to reorder the embedded bidi text. This was working well for texts on one line, but wrapping text would break the algorithm.

I had to move the reordering algorithm into cosmic_text to be able to adapt it. Also I had to change the ShapeLine::layout function to create the LayoutLine at the end, after reordering.

Currently I can not do wrap_simple because I am using a Vec<span_index, word_range> to represent a line. But to be able to do wrap_simple I need to know where in a word the line break happens.

More detail: So with this PR, if we have a big chunk of LTR text that needs multiple visual lines. It would become one single Span with index 0 and the visual lines would be [ [(0, 0..15)], [(0, 15..34)], ..] (which is a Vec<Vec<usize, Range>>). Now if we have two small chunks of text, one 5 words LTR, one 4 words RTL and it would fit on one line. It would generate two Spans (indices 0,1) and the Visual line would be [[(0, 0..5), (1, 0..4)]].

TODO:

• [x] Correct BiDi ordering per visual line
• [x] wrap_simple
• [x] Skip first space on a new line
• [x] A long sequence of whitespaces is considered a word and causes issues with wrapping
• [x] Words longer than the line_width break the layout (in the main branch too).

While testing #98 I noticed a few layouting issues. These issues are in the main branch too.

One issue was in BiDi text, sometimes there was an overflow like the word "Left" in this picture:

This issue sometimes causes the last word to repeat or to disappear.

Another issue was in the LTR-only lines (or RTL-only), the space before the last word would disappear if the linewidth was a specific size. Like in the image below:

In this PR I fix these issues by changing the layout algorithm a little. Previously we used to create word_ranges and later put them together in a visual_line but now the visual_line is created while iterating over the words. This simplifies the algorithm and fixes the issue mentioned above.

This PR supersedes #98. I tried to apply these changes to @geieredgar 's PR, but the algorithm they used for detecting trailing spaces would not work in specific situations in BiDi. So, I decided to open a new PR.

I am currently developing a cosmic-text-based implementation of the piet text API, see here. The only bits from piet that are currently unimplemented are variable font sizes (already raised in #64) and text justification.

piet expects there to be utilities for text justification, with start (default), right, center and justified alignments. See this enum for more information.

Are there any plans to add text alignment to cosmic-text?

This PR introduces a w field to LayoutLine and a line_w to LayoutRun.

These are useful to avoid iterating through all the glyphs just to figure out the line width (e.g. for alignment purposes).

I try to utilize cosmic-text to draw text to a bitmap and to obtain a tight bounding box around the result. Right now, I am confused by the calculation of the vertical offset of the text. To elaborate further, let us assume that we draw a single glyph, i.e. the letter "g", using a Buffer. For the sake of simplicity, we set line_height == font_size == 72.0 (i.e. we do not apply leading aka additional distance between the lines). When we call Buffer::draw(), the code first creates a LayoutRunIter whose line_y property is initialized as follows:

https://github.com/pop-os/cosmic-text/blob/bfb5eefbfa869915e47824877af68a5307cf301c/src/buffer.rs#L215

In our case, y_offset() evaluates to 0.0 (no leading, see above) and therefore, our run starts at a vertical offset of 0.0. Now, we call next() on the iterator to draw the first run and observe that line_y is incremented by the line height which is equal to the font size (aka 72.0):

https://github.com/pop-os/cosmic-text/blob/bfb5eefbfa869915e47824877af68a5307cf301c/src/buffer.rs#L241

Finally, we obtain the glyph image from `swash' and draw it to the given offset:

https://github.com/pop-os/cosmic-text/blob/bfb5eefbfa869915e47824877af68a5307cf301c/src/buffer.rs#L718-L720

run.line_y still evaluates to 72.0 in our example. However, if I understand correctly, the swash image is positioned relatively to the baseline of the glyph. I did not find explicit confirmation for this assumption in the swash documentation, but the swash_demo repo provides an extensive sample for this. When drawing its layout, it incorporates the baseline into the vertical offset as seen here:

https://github.com/dfrg/swash_demo/blob/55aedbc8604201f1b4925e2b986db59b838dc062/src/main.rs#L493

In opposition, cosmic-text effectively places the baseline at the bottom of the line. When I try to draw my "g" glyph to the top-left corner of a bitmap and set my bounding box height to 72 pix, I end up with the following result:

How to fix this? I am not adept in typography, but for my understanding, the vertical offset must be corrected by the descent of the font as displayed here:

Indeed, to draw my glyphs to the bitmap, I tried to calculate the baseline of the font by myself to apply this correction. This approach works, but cosmic-text makes it pretty hard to implement it. Basically, I have to layout my line, obtain the FontID from the glyphs, query the Font from the FontSystem and do something like this:

let metrics = font.as_swash().metrics(&[]);
let total_height = metrics.ascent + metrics.descent;
let baseline = font_size * metrics.ascent / total_height;

In fact, this is about the same calculation that is done in the swash demo, see here:

https://github.com/dfrg/swash_demo/blob/d08ced5f1e92b62cd637415c1f66c440d737b31b/src/layout/line_breaker.rs#L324-L326

By using baseline instead of font_size (resp. the total line height) as vertical offset, I finally get the correct result. I can live with this approach, but it would be nice if cosmic-text made it easier for me to access the baseline offsets of the layout lines.

Sorry for the long explanation. I hope the issue has been made clear - and thanks for your awesome work on this crate!

This PR introduces a Shaping enum that allows users to control the shaping strategy used.

A new Basic shaping strategy is also added which naively positions glyphs and skips rustybuzz completely.

Modifying editor-test

    let text = if let Some(arg) = env::args().nth(1) {
        fs::read_to_string(&arg).expect("failed to open file")
    } else {
        #[cfg(feature = "mono")]
        let default_text = include_str!("../../../sample/a.txt");
        #[cfg(not(feature = "mono"))]
        let default_text = include_str!("../../../sample/a.txt");
        default_text.to_string()
    };

and putting to sample file - ss.txt.zip

crash app with info

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Cursor { line: 0, index: 11747, affinity: After }`,
 right: `Cursor { line: 0, index: 11743, affinity: After }`', examples/editor-test/src/main.rs:99:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It seems like font fallback generally works pretty well, but if a certain property, such as italics are not available for the fallback font, the font is not chosen at all and tofus are rendered instead.

Here's an example where Calibri is the main font. Calibri by itself does not support Hangul, so it falls back to a different font (seems to be Malgun Gothic). This works fine until you choose Calibri Italic, at which point it can't find an italic version of Malgun Gothic and shows tofus.

This may or may not be related to #58. I'm surprised the fallback is rejected if found in the first place though, so it may not actually be related.

Depending on whether it's a mixed layout or not, the arabic characters are either reversed or not:

This is with the latest master.

Here you see a debugger view of just the arabic characters:

This may or may not be intended, but is super weird to deal with. To properly handle this I need to properly mix the shape line's BIDI level with the shape span's BIDI level and then depending on what combination it is, iterate the glyphs in reverse or not.

I don't even understand why cosmic-text (sometimes) reverses what rustybuzz spits out in the first place, as I need to unreverse it to draw the glyphs in the proper order. That seems like a lot of wasted work that cosmic-text does.