Offset the line to fit the glyph with negative side bearing

[w0rm]

Implements the logic that we discussed in #166.

This is how it works for MogeeFont (with justified text):

[bugadani]

Can we somehow avoid double-measuring here? I'd probably prefer modifying measure to return the offset along with the width.

[w0rm]

Done! Realised that having a more specialised function was nicer than changing the existing measure function, to avoid touching a lot of places where it is used.

[bugadani]

Thanks for working on this, this is an even smaller diff than I expected :)

[w0rm]

@bugadani I started with a much more complex solution and then realised that simply injecting unaccounted whitespace did the trick!

Will update the existing measure function to prevent from double measuring.

[bugadani]

Thank you, this is awesome. Two more things and I think we can ship this:

• could you please add a rendering test like

  embedded-text/src/rendering/mod.rs

  Line 337 in f49d524

  fn rendering_not_stopped_prematurely() {

  to make it obvious this PR does what you intended?
• could you please add this to the changelog? :)

[w0rm]

@bugadani rendering testing turned out to be quite involved, because I needed to implement a test font. The font I am working on is not released yet, and it might not be a good idea to depend on it.

[w0rm]

@bugadani please review but don’t merge this just yet. I want to run a few more tests next week!

[bugadani]

Apologies, I didn't intend the test to turn this hairy, not sure what went through my head with that. However, thanks for adding it!

If you'd like to prevent me from merging, just feel free to mark the PR as a draft (although... request noted even though the green button is tempting :) ), you can find the option top right, under the "Reviewers" box.

[w0rm]

@bugadani unfortunately I found another issue.. this time it is a panic caused by splitting long words in longest_fitting_substr.

A pixel width of a str is not equal to a sum of widths of individual characters. In my font, the space between a pair of characters depends on the characters themselves (this is called kerning), and also sometimes consecutive characters may be collapsed into a ligature.

In the test font that I added, the spacing between the characters is 1px that is not accounted into the char width. This makes the actual length of the string longer than the sum of widths of individual characters. I added a test that panics.

I can replace this with a function that iterates over the character indices and measures the str width until that, but it would certainly be slower than the current implementation.

[bugadani]

A pixel width of a str is not equal to a sum of widths of individual characters.

Yes, you are bringin in a whole new set of assumptions. e-t was built assuming fonts are monospaced, so in several places width = length * character_width.

At this point I can accept compromises in terms of speed, as some of the "optimisations" present were made without any instrumentation. We can tune things later if speed becomes an issue, although I'm quite sure nobody build an e-book reader with e-t :)

[w0rm]

@bugadani I've committed a possible fix for this issue and added tests for TestFont and MonoFont. Do you know any other place where this is assumed?

[bugadani]

I do not but that is mainly because I haven't read this code in a long time.

[w0rm]

I looked up all the calls to measure, and the only remaining place that I noticed is a place that assumes that the break character starts when the word ends.

Some(Token::Break(w)) => return Some(width + handler.measure(w)),

I am not relying on break characters in my text, we can tackle this issue separately when this becomes a problem. It renders a hyphen without a spacing, but that's not as bad as a panic.

[w0rm]

I don't see any obvious problems left, I think this PR is now ready.

[bugadani]

Thank you very much for working on this!