Add tests that will match rendered words/paragraphs against reference
images.
Use env var `GENERATE_IMAGES` to write the initial reference images to
the repository.
The MSRV was scanned by cargo-msrv, the result shows src/buffer.rs uses let - else statements which requires rust 1.65.0.
This also reformat the Cargo.toml.
Try to ensure that using "the width computed during an unconstrained
layout" as the width constraint during a relayout produces the same
layout. This is useful for certain UI layout algorithms.
See https://github.com/pop-os/cosmic-text/issues/134
* Instead of computing the LayoutLine width from the positioned and
aligned glyphs, we pass through width computed during line wrapping
(unless justified alignment is used, in this case we use the old
approach because the use case for measuring the width isn't really
applicable to justified text since that will just expand to the
provided width). For the produced width to later give the same
wrapping results when passed in as the `line_width` it needs to use
the same exact float arithmatic that was used to compute the width
that is compared against `line_width` when making line wrapping
choices. Passing this width through as the LayoutLine width is the
most covenient option without making more major changse to the API.
Nevertheless, I am imagining that if we get a dedicated measurement
method (i.e. that doesn't do the final positioning and alignment of
glyphs and which caches `Vec<VisualLine>`), then this width can just
be exposed there instead of preservering it in LayoutLine.
* Incidentally, this fixes
https://github.com/pop-os/cosmic-text/issues/169.
* Switch substraction from `fit_x` to checking whether potential
addition to the current line width would exceed the `line_width`. This
avoids the float error being dependent on the provided `line_width`
value.
* When eliminating trailing space from the line width, we avoid
backtracking with subtraction (which would not give the same exact
value due to float error) and instead save the previous width and use
that.
* If the previous word did not exceed the line_width, we now include a
single blank word even if it would cross the width limit since its
width won't be counted. This is necessary to get the same wrapping
behavior when re-using the measured width (which doesn't count a
single trailing blank word). Note, this whitespace logic may be
reworked anyway if <https://github.com/pop-os/cosmic-text/issues/155>
is addressed.
* Change tests to use `opt-level=1` to keep test runtime down.
* Add `fonts` folder for fonts used in tests.
* Fix an issue where a non-breaking whitespace was assumed to be the
start of a section of spaces which included characters that weren't
even whitespace.
* Add some TODOs about incongruencies between `is_whitespace`,
justification, and line breaks.
This reduces compilation time by removing a dependency on syn and other
dependencies of ouroboros_macros. In addition it saves a lot of unused
codegened methods.
On my laptop (2 core + HT) this reduces compilation time by ~20%. On a
many core system this doesn't help much though as the critical path path
consists of both ttf-parser -> rustybuzz and swash. Further gains will
likely need to be made by reducing compilation time for these crates.
Benchmark 1: cargo build
Time (mean ± σ): 25.150 s ± 0.167 s [User: 84.414 s, System: 7.335 s]
Range (min … max): 24.909 s … 25.444 s 10 runs
Benchmark 1: cargo build
Time (mean ± σ): 19.819 s ± 0.226 s [User: 67.754 s, System: 5.592 s]
Range (min … max): 19.492 s … 20.140 s 10 runs
The code is based on an expansion of the ouroboros macro, cleaned up to
remove all unused methods and inline most functions that are only called
once.
There was a problem in the upstream `sys-locale` crate where it assumed
that every WebAssembly target can use `wasm-bindgen` just fine. This
however is not the case, as `wasm-bindgen` and the ecosystem around it
are specifically to target the web. In reality there however are at
least the following 4 "targets" (with possibly more in the future):
- WebAssembly on the web
- Freestanding WebAssembly
- WebAssembly with WASI
- WebAssembly with Emscripten
These are all supported properly through `sys-locale` 0.3.0 now. However
because "WebAssembly on the web" unfortunately is not its own target and
instead uses `wasm32-unknown-unknown`, just like freestanding
WebAssembly, the only way to differentiate between them is through a
feature. This is the best practice and is done throughout the ecosystem.
Here the feature `wasm-web` is introduced that properly forwards it to
`sys-locale` and possibly other crates in the future.
