raphlinus / font-rs Goto Github PK

The Rust code has SIMD and non-SIMD versions of this conversion
(255.0 * y) as u8
from an f32 in the range [0.0, 1.0] to a u8 in the range [0, 255].

Due to rounding errors, this sometimes means that a pixel well inside a glyph ends up with an 0xfe value instead of 0xff, since its floating point value is slightly less than 1.

In my Go port, I embiggened the constant from 255.0 to 255.99998, or 0x437fffff as a float32 bit pattern, which eliminated these central "0xfe"s. See the comment at the bottom of google/font-go@7c31afd

I think that the Rust code should do the same.

It has been more or less often been stated that font-rs is capable of doing benchmarks, but still not production ready.
Many people are interested in font-rs and you called for participation.

What are the necessary steps to make font-rs production ready?

IIRC, there is rgb subpixeling and other issues to get around inadquate resolution on low-dpi displays. It would be nice if you could provide a Task List.

First thing i noticed is accessing the charmap of a font is not supported yet.

Would you be interested in testing font.rs through Unicode text rendering tests?

I’d volunteer to do the integration into the test suite on the Unicode side, if somebody familiar with Rust writes a command-line tool that can be called like this:

path/to/some-command --font=fonts/TestCMAP14.otf --testcase=Foo-5/6 --render=≩≩

writing an SVG file to stdout like this:

<?xml version="1.0" encoding="UTF-8"?>
<svg version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    viewBox="0 -120 1446 1200">
  <symbol id="Foo-5/6.uni2269" overflow="visible"><path d="M100,334 L623,563 L623,619 L100,880 L100,793 L518,594 L100,420 Z M100,208 L622,208 L622,287 L100,287 Z M100,38 L622,38 L622,117 L100,117 Z M282,-93 L508,379 L436,413 L211,-59 Z"/></symbol>
  <use xlink:href="#Foo-5/6.uni2269" x="0" y="0"/>
  <use xlink:href="#Foo-5/6.uni2269" x="723" y="0"/>
</svg>

For test cases on variable fonts, your tool would be called with an additional argument for the variation settings, such as --variation=wght:481.3;wdth:70. Initially, you could ignore this.

The test fonts are here. If you write a command-line tool that can be called as described, the generated test report will look like this, this, this, or this.

x0i can be -1 in this case, and casting it to usize will give usize max. The addition with linestart will cause an arithmetic overflow. Wrapping add should be used.

I've ported font-rs to the Go programming language.

Using fixed point math instead of floating sped up my rasterization benchmarks by between 1.2x and 1.4x.

Perhaps font-rs should do that too.

The font-go commit: google/font-go@4bf4d10

Hello,
I tried compiling the project in windows 10 with current non-beta rust and got an error when Cargo tried compiling accumulate_sse.c.
I put the code in VS 2015 and it takes issue with this line .
I found the fix on stackoverflow, it essentially amounts to replacing that line with
_mm_store_ss((float *)&out[i], _mm_castsi128_ps(z));
After making this change the project builds succesfully.

For well formed TrueType glyph data, the bounding box should contain all of the nodes. However, malicious data might lead to out-of-bounds nodes, so more bounds checking is necessary for a production quality rasterizer.

Even with well formed data, I suspect (based on my Go port) that the Rust version will panic at a line like

self.a[linestart + (x0i + 1) as usize]

when the glyph being rendered has an on-curve point at the bottom right corner of the rasterization buffer. You should be able to see this with the capital-'I' glyph from a sans-serif font.

In my Go port, I tightened this up in google/font-go@568cda6

When the CMap tests are run against Roboto-Regular.ttf from fuchsia/garnet/bin/fonts/third_party fails with the following message:

---- font::tests::test_cmap_format_4 stdout ----
thread 'font::tests::test_cmap_format_4' panicked at 'assertion failed: `(left == right)`
  left: `37`,
 right: `36`', src/font.rs:1073:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Ref: rust-lang/rfcs#1639

Stable Rust now has an is_x86_feature_detected macro, which should be used to switch between SSE and fallback implementations based on runtime detection of the SSE capability.

calibrili.ttf (md5 51991bce388163d3e30701ab1fdf6318) in Windows 10 has a space glyph that contains a singe point. This causes a panic at:

I'm getting a bug where the lookup_glyph_id function can't find a glyph even if it exists.
Here's a "trace" of the binary search it performs:

code point dec: 36196 hex: 8d64 char: 赤
size: 4247, index: 2123, end value: 29650
size: 2123, index: 4246, end value: 65509
size: 1061, index: 3185, end value: 34851
size: 530, index: 3715, end value: 37587
size: 265, index: 3450, end value: 36118
size: 132, index: 3582, end value: 36921
size: 66, index: 3516, end value: 36557
size: 33, index: 3483, end value: 36362
size: 16, index: 3467, end value: 36290
size: 8, index: 3459, end value: 36229
size: 4, index: 3455, end value: 36209
size: 2, index: 3453, end value: 36203
size: 1, index: 3452, end value: 36199
Error: StringError("Glyph doesn\'t exist")

The actual range that includes the glyph is in index 3451, so it's off by one. It's still in the range when the size is 33: 3483-33 = 3450, but drops from the range the next step: 3467-16 = 3451 (this is non-inclusive, as the size printed here was the size of the last step).

We can see that the the correrct result is excluded from the range because of a rounding error: Rust rounds always towards zero so 33/2 becomes 16, which makes it here lose enough of it's "jumping power" for it not to reach the correct range.

It seems to me that the correct thing to do is to ensure that the result is always rounded up.

What should I do with the output of cargo build --release? I only get a libfont_rs.rlib