Update Font Awesome #790
Labels
Comments
Open
notriddle
added a commit
to notriddle/docs.rs
that referenced
this issue
Sep 3, 2020
notriddle
added a commit
to notriddle/docs.rs
that referenced
this issue
Sep 3, 2020
notriddle
added a commit
to notriddle/docs.rs
that referenced
this issue
Sep 3, 2020
notriddle
added a commit
to notriddle/docs.rs
that referenced
this issue
Sep 3, 2020
notriddle
added a commit
to notriddle/docs.rs
that referenced
this issue
Sep 14, 2020
Fixes rust-lang#790 The rationale for embedding the SVG files directly in the binary: * avoid file I/O occurring in your Tera Filter, which would likely have complex knock-on effects when combined with `async` * avoid complex error handling in your Tera Filter, which is the inevitable outcome of file I/O * avoid having to carefully construct filesystem paths, with all the terrible possible outcomes and failure modes that come with that (using the infrastructure that the existing static file server uses is not an option, because it's not an HTTP request) * I'm guessing it's faster to pull a string out of the binary's text section than it is to open a file for every request, though I have done no benchmarking to justify this wild speculation The rationale for doing it in its own crate: * we're not using any of docs.rs's file handling infrastructure anyway, so all the other stuff in its build.rs was just getting in the way while I coded up its codegen script * it should be useful in other Rust web projects, regardless of the web framework they're using * let's not force rustc to parse a 1.3MiB source file every time you change docs.rs; this seems like prime "separate translation unit" material
jyn514
pushed a commit
that referenced
this issue
Sep 14, 2020
Fixes #790 The rationale for embedding the SVG files directly in the binary: * avoid file I/O occurring in your Tera Filter, which would likely have complex knock-on effects when combined with `async` * avoid complex error handling in your Tera Filter, which is the inevitable outcome of file I/O * avoid having to carefully construct filesystem paths, with all the terrible possible outcomes and failure modes that come with that (using the infrastructure that the existing static file server uses is not an option, because it's not an HTTP request) * I'm guessing it's faster to pull a string out of the binary's text section than it is to open a file for every request, though I have done no benchmarking to justify this wild speculation The rationale for doing it in its own crate: * we're not using any of docs.rs's file handling infrastructure anyway, so all the other stuff in its build.rs was just getting in the way while I coded up its codegen script * it should be useful in other Rust web projects, regardless of the web framework they're using * let's not force rustc to parse a 1.3MiB source file every time you change docs.rs; this seems like prime "separate translation unit" material
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We currently use Font Awesome 4 which was replaced in 2017ish by Font Awesome 5 which has 1500+ icons (opposed to the ~300 of our version). v5 also uses SVGs, which would help with some of the aliasing problems that the current icons can have on screens with larger resolution. There's also some icon-related stuff I'd like to do which is only possible with some of the extended icons that v5 offers
The text was updated successfully, but these errors were encountered: