font-rs

So for sub-pixel accurate font rasterization in Rust there are [1], [2], [3] and now the one from Typist, [4]. Possibly there are more (I know Raph Linus stopped maintaining [5] so that one is out). All of these crates are actively maintained. Are people re-inventing the wheel? [1] https://gitlab.redox-os.org/redox-os/rusttype [2] https://github.com/alexheretic/ab-glyph [3] https://github.com/mooman219/fontdue [4] https://github.com/typst/pixglyph [5] https://github.com/raphlinus/font-rs

There's some cool things to note about Xi which make me more excited about it: * It's being written by Raph Levien, known for his work on Inconsolata, Ghostscript, and font-rs[1] among other things. * The design goals include incredibly high performance, beauty, reliability and developer friendliness[2]. * It's very fast at handling large files, though the editor is still missing a lot of functionality. Raph was also interviewed on the New Rustacean podcast[3] and talks a fair bit about Xi. [1]: https://github.com/google/font-rs [2]: https://github.com/google/xi-editor#a-modern-editor-with-a-backend-written-in-rust [3]: http://www.newrustacean.com/show_notes/interview/_2/part_1/index.html

Author: > The current state of the code is quite rough. The code isn't well organized, and it's basically not ready for prime time. From what I can see in https://github.com/google/font-rs/blob/master/src/font.rs, this is what is missing: * support of CFF-based fonts (that is "postscript-flavored outlines" (i.e. cubic) OTF files) * "Advanced Typographic Tables" (see Opentype spec: https://www.microsoft.com/typography/otspec/otff.htm), this is what is needed to render more complex non-latin languages like Arabic etc, because it defines context-specific replacements and positioning, but also opentype-level kerning * support for the kerning table * support for slightly more exotic TTF variations like EOT and WOFF for webfonts * hinting support for smaller rendering sizes Most of these things are supported by Freetype, and are probably a cons

> Those manual use/optimization of SIMD are done in C anyway. C seems to be used only for SSE intrinsics support. ~16 LoC of "C". This is all C in the whole project, if you really think you can call it as such: https://github.com/google/font-rs/blob/master/src/accumulate... void accumulate_sse(const float *in, uint8_t *out, uint32_t n) { __m128 offset = _mm_setzero_ps(); __m128i mask = _mm_set1_epi32(0x0c080400); __m128 sign_mask = _mm_set1_ps(-0.f); for (int i = 0; i < n; i += 4) { __m128 x = _mm_load_ps(&in[i]); x = _mm_add_ps(x, _mm_castsi128_ps(_mm_slli_si128(_mm_castps_si128(x), 4))); x = _mm_add_ps(x, _mm_shuffle_ps(_mm_setzero_ps(), x, 0x40)); x = _mm_add_ps(x, offset); __m128 y = _mm_andnot_ps(sign_mask, x); // fabs(x) y = _mm_min_ps(y, _mm_set1_ps(1.0f)); y = _mm_mul_ps