You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
With --engine=FreeStack, the tests are run on the free/libre open-source text rendering stack with FreeType, HarfBuzz, FriBidi, and Raqm. These libraries are used by Linux, Android, ChromeOS, and many other systems. — Test report for FreeStack.
I think font-rs would be best to focus only on the FreeType part of this stack. To handle this, we would need to add the proper FriBidi and HarfBuzz plumbing to get these tests to work.
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:
writing an SVG file to stdout like this:
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.
The text was updated successfully, but these errors were encountered: