stb_truetype-rs issueshttps://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues2019-09-06T13:53:14Zhttps://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/25Version 0.2.7 has a breaking change2019-09-06T13:53:14ZAlice RyhlVersion 0.2.7 has a breaking changeOur jenkins builder suddenly started failing with:
```
error: You need to activate either the `std` or `libm` feature.
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/stb_truetype-0.2.7/src/lib.rs:18:1
|
18 | compile_erro...Our jenkins builder suddenly started failing with:
```
error: You need to activate either the `std` or `libm` feature.
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/stb_truetype-0.2.7/src/lib.rs:18:1
|
18 | compile_error!("You need to activate either the `std` or `libm` feature.");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
Please either use semver to mark it as a breaking change or enable the `std` feature by default.
We've been using 0.2.6 until now. Perhaps consider yanking the version and re-releasing it as 0.3.0https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/24Please make bumps in minimum rust version a breaking change.2019-07-29T18:49:18ZLokathorPlease make bumps in minimum rust version a breaking change.I've been trying to get folks to take minimum supported rust more seriously, which has lead me here. I saw https://gitlab.redox-os.org/redox-os/stb_truetype-rs/issues/20 and I'm wondering if you'd be willing to at least make any bump in ...I've been trying to get folks to take minimum supported rust more seriously, which has lead me here. I saw https://gitlab.redox-os.org/redox-os/stb_truetype-rs/issues/20 and I'm wondering if you'd be willing to at least make any bump in minimum supported rust version be a breaking change release?https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/23Fix FIXME in examples/fontname.rs2019-07-02T02:49:02ZFlávio J. SaraivaFix FIXME in examples/fontname.rsI noticed the FIXME in examples/fontname.rs.
name, a byte array, is being cast to a u16 array and read.
~~This will probably produce bad strings on machines with different endianess.~~
This can "blow up" on machines that can't read u16 ...I noticed the FIXME in examples/fontname.rs.
name, a byte array, is being cast to a u16 array and read.
~~This will probably produce bad strings on machines with different endianess.~~
This can "blow up" on machines that can't read u16 values on odd addresses.
To fix you just need to get the u16 values from the bytes, you already depend on the byteorder crate so here's a fix with it:
[fix_name16_alignment.txt](/uploads/566829e6d9cf1a42179421965b9f0152/fix_name16_alignment.txt)
EDIT - I misunderstood u16::from_be, it's only the alignmenthttps://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/22Can you provide the fonts/ directory in the crate?2019-03-19T20:10:55ZRobert-André MauchinCan you provide the fonts/ directory in the crate?It would be helpful in order to run the tests properly.It would be helpful in order to run the tests properly.https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/21Cannot compile the newest version2018-12-19T12:57:22ZOptimisticPeachCannot compile the newest versionWhen I tried to compile my project today, I went through a rabbit hole, and ended up here. I get an error on [line 9](https://gitlab.redox-os.org/redox-os/stb_truetype-rs/blob/master/src/lib.rs#L9), and it's because you never declared an...When I tried to compile my project today, I went through a rabbit hole, and ended up here. I get an error on [line 9](https://gitlab.redox-os.org/redox-os/stb_truetype-rs/blob/master/src/lib.rs#L9), and it's because you never declared an extern crate named `byteorder`, leading to a missing crate. [section until `use` statement](https://gitlab.redox-os.org/redox-os/stb_truetype-rs/blob/master/src/lib.rs#L1-9). Please fix this, as my current installation of cargo/cargo-apk can't seem to sort out using an older library.
PS, I'm looking at version "0.2.5"https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/20`0.2.4` changed the minimum Rust version required2019-07-29T04:50:22ZFrancesca Plebani`0.2.4` changed the minimum Rust version requiredThe recent release of version `0.2.4` silently broke [winit](https://github.com/tomaka/winit)'s guarantee of compatibility with Rust `1.24.1`, and in turn our CI: https://travis-ci.org/tomaka/winit/jobs/453350639#L482
I'd be curious to ...The recent release of version `0.2.4` silently broke [winit](https://github.com/tomaka/winit)'s guarantee of compatibility with Rust `1.24.1`, and in turn our CI: https://travis-ci.org/tomaka/winit/jobs/453350639#L482
I'd be curious to know if you'd be open to supporting a specific minimum version of Rust, and enforcing it via CI. Naturally, `1.24.1` would be my preference, but even if that's undesirable I still think it would be helpful to keep track of what version's required. Additionally, having increases to the minimum supported version requiring a minor version bump would be very nice.https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/19Panic when getting shape of BOM glyph from Windows' Consolas font2018-12-14T02:00:08ZMartin SuchaPanic when getting shape of BOM glyph from Windows' Consolas fontWhen getting shape of Byte Order Mark (`'\u{feff}'`) of Windows' Consolas font, a panic occurs:
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore\option.rs:345:21
[...]
11: core::option::Option<(usize,...When getting shape of Byte Order Mark (`'\u{feff}'`) of Windows' Consolas font, a panic occurs:
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore\option.rs:345:21
[...]
11: core::option::Option<(usize, stb_truetype::{{impl}}::glyph_shape_positive_contours::FlagData)*>::unwrap<(usize, stb_truetype::{{impl}}::glyph_shape_positive_contours::FlagData)*>
at C:\projects\rust\src\libcore\macros.rs:20
12: stb_truetype::FontInfo<rusttype::SharedBytes>::glyph_shape_positive_contours<rusttype::SharedBytes>
at C:\Users\Martin\.cargo\registry\src\github.com-1ecc6299db9ec823\stb_truetype-0.2.4\src\lib.rs:911
13: stb_truetype::FontInfo<rusttype::SharedBytes>::get_glyph_shape<rusttype::SharedBytes>
at C:\Users\Martin\.cargo\registry\src\github.com-1ecc6299db9ec823\stb_truetype-0.2.4\src\lib.rs:655
[...]
```
More context can be found at https://github.com/jwilm/alacritty/issues/1674
I've tried the following patch:
```diff
diff --git a/src/lib.rs b/src/lib.rs
index 384ef78..8462d3f 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -907,9 +907,9 @@ impl<Data: Deref<Target = [u8]>> FontInfo<Data> {
scx = x;
scy = y;
- let (next_flags, next_x, next_y) = {
- let peek = &iter.peek().unwrap().1;
- (peek.flags, peek.x, peek.y)
+ let (next_flags, next_x, next_y) = match &iter.peek() {
+ Some(peek) => (peek.1.flags, peek.1.x, peek.1.y)
+ None => break
};
if next_flags & 1 == 0 {
```
This obviously suppressed the panic, but I'm not sure it's the correct fix. If this is caused by invalid data in the font, maybe `glyph_shape_positive_contours` should return an Option or Result to indicate this instead of panicking?https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/18Incorrect interpretation of compound glyph component positions2018-09-05T13:16:03ZFredrik PIncorrect interpretation of compound glyph component positionsstb_truetype interprets positions of components of compound glyphs as signed bytes using the `ttCHAR` macro. [(source)](https://github.com/nothings/stb/blob/e6afb9cbae4064da8c3e69af3ff5c4629579c1d2/stb_truetype.h#L1781-L1782)
stb_truety...stb_truetype interprets positions of components of compound glyphs as signed bytes using the `ttCHAR` macro. [(source)](https://github.com/nothings/stb/blob/e6afb9cbae4064da8c3e69af3ff5c4629579c1d2/stb_truetype.h#L1781-L1782)
stb_truetype-rs interprets them as unsigned bytes. [(source)](https://gitlab.redox-os.org/redox-os/stb_truetype-rs/blob/d0c5dd41627ed00cac9bb5a53e318c4ec0191310/src/lib.rs#L678-681)
This causes for example the glyph `:` in Roboto-Regular to shift the lower one of the two dots to the right. See [Rusttype issue](https://gitlab.redox-os.org/redox-os/rusttype/issues/125).https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/17Release 0.2.32018-08-27T17:25:27ZAlex ButlerRelease 0.2.3Current master is ready for release as `0.2.3`. I'm not a crates.io owner, so this is one for @jackpot51.Current master is ready for release as `0.2.3`. I'm not a crates.io owner, so this is one for @jackpot51.Jeremy SollerJeremy Sollerhttps://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/16Rework get_glyph_shape2018-09-02T17:39:27ZAlex ButlerRework get_glyph_shapeThis method is a critical one for rusttype performance. It's currently a big & hard to read lump and probably could run much faster. It's benchmarked and regression tested by the `get_glyph_shape_*` benches in `benches/api.rs`.
See also...This method is a critical one for rusttype performance. It's currently a big & hard to read lump and probably could run much faster. It's benchmarked and regression tested by the `get_glyph_shape_*` benches in `benches/api.rs`.
See also #15https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/15Remove unsafe usage in get_glyph_shape2018-09-02T17:39:26ZAlex ButlerRemove unsafe usage in get_glyph_shapeOne unsafe block remains in `get_glyph_shape`
```rust
let mut vertices: Vec<Vertex> = Vec::with_capacity(m);
unsafe{ vertices.set_len(m) };
```
Ideally we can remove this unsafe usage without affecting the `get_glyph_shape_*` benchmark...One unsafe block remains in `get_glyph_shape`
```rust
let mut vertices: Vec<Vertex> = Vec::with_capacity(m);
unsafe{ vertices.set_len(m) };
```
Ideally we can remove this unsafe usage without affecting the `get_glyph_shape_*` benchmarks too much. Using `vec![dummy; m]` slows down these benchmarks.https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/14Add find_glyph_index benchmark regression test for `format=6` font2018-08-24T13:26:10ZAlex ButlerAdd find_glyph_index benchmark regression test for `format=6` fontWe have benchmark regression tests in benches/api.rs, that can be run with `cargo +nightly bench` & `cargo +nightly test --bench api`.
We're not currently testing format `6` `find_glyph_index` logic. We should add new one covering this ...We have benchmark regression tests in benches/api.rs, that can be run with `cargo +nightly bench` & `cargo +nightly test --bench api`.
We're not currently testing format `6` `find_glyph_index` logic. We should add new one covering this format, similar to how `find_glyph_index_gudea` covers format `4`.https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/13Add find_glyph_index benchmark regression test for `format=0` font2018-08-24T13:23:47ZAlex ButlerAdd find_glyph_index benchmark regression test for `format=0` fontWe have benchmark regression tests in benches/api.rs, that can be run with `cargo +nightly bench` & `cargo +nightly test --bench api`.
We're not currently testing format `0` `find_glyph_index` logic. We should add new one covering this ...We have benchmark regression tests in benches/api.rs, that can be run with `cargo +nightly bench` & `cargo +nightly test --bench api`.
We're not currently testing format `0` `find_glyph_index` logic. We should add new one covering this format, similar to how `find_glyph_index_gudea` covers format `4`.https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/12Transfer this repo as well2018-06-15T10:04:43ZJeremy SollerTransfer this repo as wellRelated to https://github.com/redox-os/rusttype/issues/55Related to https://github.com/redox-os/rusttype/issues/55https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/3arithmetic operation overflow2018-06-15T10:04:43ZJeremy Sollerarithmetic operation overflow*Created by: dylanede*
See https://github.com/dylanede/rusttype/issues/8
*Created by: dylanede*
See https://github.com/dylanede/rusttype/issues/8
https://gitlab.redox-os.org/redox-os/stb_truetype-rs/-/issues/2Incorrect handling of format 12 and 13 glyf tables2018-06-15T10:04:43ZJeremy SollerIncorrect handling of format 12 and 13 glyf tables*Created by: dylanede*
There's an `unreachable!()` where there should be a `return 0`, causing code points with no glyphs to panic. See https://github.com/dylanede/rusttype/issues/7
*Created by: dylanede*
There's an `unreachable!()` where there should be a `return 0`, causing code points with no glyphs to panic. See https://github.com/dylanede/rusttype/issues/7