-
Notifications
You must be signed in to change notification settings - Fork 562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix software renderer line breaker without the unicode feature #1606
Conversation
This change makes the test pass without the unicode feature. Note that it is not possible to run the test without the unicode feature unless one changes the Cargo.toml, so I did that locally to run the tests
if let Some(opportunity) = maybe_opportunity { | ||
return Some((byte_offset, opportunity)); | ||
return Some((byte_offset + 1, opportunity)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worries me a tiny little bit, as this could return a byte offset that's out of the string bounds, if the last character is a break opportunity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"one past the end" is ok, not? otherwise i can change that to not return that if this is the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would be good, yes.
This is a test that passes with unicode and should pass with both (but doesn't!):
#[test]
fn test_linebreak_opportunity_at_eot() {
let mut it = LineBreakIterator::new("Hello World\n\n");
assert_eq!(it.next(), Some((6, BreakOpportunity::Allowed)));
assert_eq!(it.next(), Some((12, BreakOpportunity::Mandatory)));
assert_eq!(it.next(), None);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a test that should cover this use case, does it?. The use of this function in fragments.rs seems to anyway create a break at the end if there isn't one (but the difference is that trailing_mandatory_break will be set.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's fine as well. The above is a little more localised, but I think your change is good as well :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
your test will indeed not pass with this change. But should it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that now the linebreak_simple and linebreak_unicode will behave differently with trailing \n, but checking for the last codepoint is a bit of work which i think is unnessery since the consumer won't bother.
Unless i'm missing something
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now the consumer doesn't bother. But as the issue as shown, subtle differences between the two line break iterators are difficult to spot and may cause bugs that are hard to find.
So I see three options:
- We ignore this difference for now, because the current consumers doesn't care.
- We avoid this known difference now (but there may be more, apart from the unicode line break algorithm of course).
- We switch to always using unicode line break algorithm, at the expense of code size.
I'm fine with either. What's your take?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'll go with 1. :-)
This change makes the test pass without the unicode feature.
Note that it is not possible to run the test without the unicode feature unless one changes the Cargo.toml, so I did that locally to run the tests