In Firefox, you can the advanced font settings and uncheck “Allow pages to choose their own fonts, instead of your selections above” to force websites to use the default font.
An icon font ligature is just an entry in the font file that says to display a particular sequence of characters as a single glyph. In the absence of the font the browser doesn't know that the page designer (or the font designer) intended a ligature. If you force an alternative font the browser will just display the sequence of characters that made up the ligature.
A few ligatures do have their own unicode code points, e.g. ffi, so the browser knows what is intended independent of the font. The ligatures used by icon fonts do not have their own code points.
> An icon font ligature is just an entry in the font file that says to display a particular sequence of characters as a single glyph.
Most icon fonts use private-use codepoints, not ligatures. These codepoints have no standard glyph, so disabling site-specific fonts will make those characters fail to render at all or display placeholder characters (e.g. �).
Thankfully, icon fonts are declining rapidly in usage - SVG icons are superior for most use cases.
> A few ligatures do have their own unicode code points, e.g. ffi, so the browser knows what is intended.
The precomposed ligature codepoints (e.g. U+FB00-FB06) only exist for compatibility with legacy encodings which included similar characters. They shouldn't be used in new documents. If you want text on a web page to use ligatures, use the CSS font-variant-ligatures property to control which ones are used. (And make sure to disable them on monospaced text!)
Its interesting that Firefox would offer a feature that disables all custom fonts rather than simply prioritizing the user's preferred font.
It does add a bit of performance gain not loading the fonts, and it may be a small security improvement, but if the goal was usability/readability that seems like a huge miss.
A preference based system would be almost impossible to maintain considering the literal infinite number of type faces out there (thousands plus more built every week).
Add to that, this feature also needs to be understandable for non-technical people who might never have view a page source in their lives.
Much as a granular system would be more powerful and preferable for the HN community, having a dumb toggle makes a lot more sense from Firefox’s perspective.
I wasn't thinking granular control. It could work exactly like the existing preference with users picking a preferred font. That font is always set as the highest priority font and used for any characters it supports, but the page's custom fonts are still fallbacks and kept in the font stack for any characters missing from the user font.
This would be helpful for icon fonts, but also for user preferred fonts that don't cover all language character sets.
No, using this setting in Firefox blocks all fonts site by a website, which means if a site uses an icon font the website UI will look very broken. I am not a fan of icon fonts.
No problem at all! I haven't been by my desktop the last couple days but I do want to test it. I hope that's already how it works, that would make more sense to me than blocking all custom font loading (though that does have its purposes).
I have one project using them, mainly because SVGs can be a bit of a pain to use in XSLT.
edit: it may not be SVGs themselves. The icons on that site are repeated and I would reach for an SVG sprite that can be reused, I ran into issues with that working cross browser in XSLT - Firefox was actually the problem if I'm not mistaken.
It's not that weird considering LazyLock has only been in stable Rust since 1.80.0, which is only ~6 weeks old!
It's a great tip though. As an out of the loop/casual Rust programmer who has internalized using `lazy_static!` for this purpose, I probably never would have noticed this update short of lazy_static throwing compiler warnings directing me to use the std lib equivalents (so...maybe never?).
Another possible solution for this use case: let each capacity graph store a “dummy” `HashMap<N,(u128, u128)>` for the case where the key is missing. Then, return an iterator over the empty dummy to get an iterator of the same type.
I will however note that simply using an option in the return value is probably the best choice both API- and performance-wise. The consumer may want to do different things if the key doesn’t exist versus if the key has no neighbors. Additionally, returning an Option means there’s only one check for whether the retrieval was correct, rather than checking at every call to `next`.
I would argue the opposite: the problem is that our languages give us only rudimentary tools to represent data in SoA styles, which makes them difficult to apply for efficient processing. In other words, it's not SIMD's fault but rather the C-like approach to data structures. In fact, SoA is also great for non-SIMD parallel implementations because it yields improvements to memory density and cache performance.
This is much nicer in functional languages that have tuples. Then an array of tuples (if normalized or flattened) is both stored efficiently and ready for vectorization. You really don't want to model mathematical objects like vectors as mutable, heap-allocated objects. OO isn't the right fit here.
funny to see this surface again! I previously posted this article in December, but it moved with me when I moved domains, so it’s at a different URL this time.
Some pretty damning results. Excerpts from the main findings below:
While NASA requires its aerospace contractors to have quality assurance programs that comply with SAE International’s AS9100D standards on quality management systems, we found Boeing’s quality management system at Michoud does not adhere to these standards or NASA requirements.
The lack of a trained and qualified workforce increases the risk that Boeing will continue to manufacture parts and components that do not adhere to NASA requirements and industry standards.
Boeing’s delivery of the EUS to NASA has also been delayed from February 2021 to April 2027, and when combined with other factors, suggests the September 2028 Artemis IV launch date could be delayed as well.
This is really excellent work, and a great write-up. I think it would definitely be possible to speed up a lot of the algorithms with some tricks. Replacing hashmaps with bitmaps and byte-index arrays for character painting and ascii-to-variants seems like a lead, based on what I've read. Of course, that doesn't really matter for this code since it's already fast enough.
Glad you brought this up, because it's absolutely true! All the code is not on the site, but I actually allocate and clone a lot of strings and data structures as well. I did optimal code where it was obvious (bitmap copying, easily parallelizable things), and it was SO instant that I didn't even bother trying to optimize the other things. But it could be done!
It's easy to forget how fast on-the-ground languages like Rust and C++ and Go are, not to mention when you use their multi-threading primitives and worker queues/etc.
note - "chess" is not a Germanic word (deriving from the Arabic شَاه (shah), meaning king). Ironically enough, it comes to English via the Old French eschés, meaning that "lichess" is arguably made from entirely French roots.
Hm, I guess the "libre" is French, but "live", "light", and most importantly "lich" are all German.
If we look for relatives of "libre", they include "leed"(song) and the first half of Leopold (adding "bold") and Luther (adding "army"). The common meaning is "people".
It would be convenient to use async, but the other requirement is that we don’t want to change the outwardly-observable API of the software under test. Since async is “infectious,” we have to use sync implementations for sync APIs.
Why does stackfulness not color functions? So long as preemption/parallelism boundaries are manually annotated, I don’t think stackful coroutines save you anything here.
For now, you may want to use VSCodium [1], which is a variant of VSCode which doesn't ship any non-free components (and also doesn't include Microsoft telemetry and such).
> Even though we do not pass the telemetry build flags (and go out of our way to cripple the baked-in telemetry), Microsoft will still track usage by default.
