Use `f64` instead of `usize` for fragment widths #421

This changes the type used for internal width computations in the wrap algorithms. Before, we used `usize` to represent the fragment widths and for the line widths. This could make the optimal-fit wrapping algorithm overflow when it tries to compute the optimal wrapping cost. The problem is that the algorithm computes a cost using integer values formed by (line_width - target_width)**2 When `line_width` is near `usize::MAX`, this computation can easily overflow. By using an `f64` for the cost computation, we achieve two things: * A much larger range for the cost computation: `f64::MAX` is about 1.8e308 whereas `u64::MAX` is only 1.8e19. Computing the cost with a fragment width in the range of `u64`, will thus not exceed 3e38, something which is easily represented with a `f64`. This means that wrapping fragments derived from a `&str` cannot overflow. Overflows can still be triggered when fragments with extreme proportions are formed directly. The boundary seems to be around 1e170 with fragment widths above this limit triggering overflows. * Applications which wrap text using proportional fonts will already be operating with widths measured in floating point units. Using such units internally makes life easier for such applications, as shown by the changes in the Wasm demo. Fixes #247 Fixes #416

This tests the wrapping using fragments with widths which could come from a &str.

This changes the panics in `wrap_optimal_fit` to a `Result` type, allowing clients to catch them.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use `f64` instead of `usize` for fragment widths #421

Use `f64` instead of `usize` for fragment widths #421

Commits on Jan 9, 2022

Use f64 instead of usize for fragment widths #421

Use f64 instead of usize for fragment widths #421

Commits on Jan 9, 2022

Use `f64` instead of `usize` for fragment widths #421

Use `f64` instead of `usize` for fragment widths #421