Interesting possible #Harfbuzz bug affecting kerning of U+0315 to a following superscript modifier. The sequence t̕ᶿ is a unit of the hən̓q̓əmin̓əm̓ alphabet.
https://github.com/microsoft/Skeena-Indigenous-Typeface/issues/10#issuecomment-2798958550

Interesting possible #Harfbuzz bug affecting kerning of U+0315 to a following superscript modifier. The sequence t̕ᶿ is a unit of the hən̓q̓əmin̓əm̓ alphabet.
https://github.com/microsoft/Skeena-Indigenous-Typeface/issues/10#issuecomment-2798958550
#HarfBuzz 11.0.1 is out with a few but important bug fixes. Please update.
"2025Q1 Fonts Quarterly" is out: what I worked on in font technology (mostly #HarfBuzz) land this past quarter:
https://docs.google.com/document/d/1RUZ0QDwSQVxlz1-pYJdUan7hoRzmoLz2cVmtCHUoqUI/view
Typesetting a font specimen for a #VariableFont with #TeXLaTeX is one of the last adventures apparently ;)
But I got it working now. luaotfload seems to be buggy, but set to render the fonts with #HarfBuzz it seems to work.
Oh, look! #Harfbuzz just dropped version #11.0.0, and the internet can't handle the excitement!
Apparently, more "features" are here to make you realize that your font rendering woes have only just begun.
Remember, folks, more numbers after the dot mean it's definitely better!
https://github.com/harfbuzz/harfbuzz/releases/tag/11.0.0 #fontRendering #excitement #features #update #HackerNews #ngated
#HarfBuzz 11.0.0 is out with lots of goodies. Among them is integration with the Fontations / Skrifa Rust font library, lots of optimizations, and new APIs:
working on my #threejs geometry built on #harfbuzz and this tiny (<5UPM) gylph-to-glyph overlap issue is the only rendering bug left that I'm aware of. it's not the font's fault (Oi! by @kosbarts - love it) and is totally reproducible, but zero luck debugging it so far. it should be a precision issue, or something about how I set paths up for triangulation... I'm not sure. maybe I'll publish an alpha version sooner rather than later to solicit some feedback on my approaches
#Harfbuzz GitHub Pull Requests: Open: 4; Closed: 2,879. Pretty cool!
After years of procrastinating, I finally wrote some Rust code. Or rather, I asked Copilot and it wrote it for me.
Please welcome `hb-fontations`: Rust-based Fontations-based font-funcs for #HarfBuzz. Mostly for (performance) testing.
https://github.com/harfbuzz/harfbuzz/blob/main/src/fontations/lib.rs
I'm working on a high quality text renderer for #threejs that can simply read a regular font via #harfbuzz (js/wasm version). and I'm finding that three.js shapes are very annoying. harfbuzz gives you a sequence of paths and winding directions - perfect - while three.js wants a hierarchy of shapes where each outer path explicitly knows its "holes." so afaict I still have to deal with path winding / testing containment / even-odd stuff, even though harfbuzz already solved it for saner formats
#HarfBuzz 10.3.0 is out. Performance highlights:
- “AAT” shaping: LucidaGrande before: 14.6ms after: 5.9ms.
- OpenType shaping: Roboto-Regular before: 10.3ms after: 9.4ms.
- “COLRv1” painting before: 7.85ms after 4.85ms.
Full release notes:
https://github.com/harfbuzz/harfbuzz/releases/tag/10.3.0
It occurred to me that "harfbuzz-ng", my rewrite of the shaper code that became known as current #HarfBuzz turned 18 years old on December 21st last year.
How it all started:
https://github.com/harfbuzz/harfbuzz/commit/f78e70c301311ffcfb007c7fc4125d71cbcff1e2
I wrote a graph traversal cycle detector based on Floyd's tortoise-and-hare algorithm. It's linear-time and constant-memory like its inspiration, and fully wiped-up cycle-detection from our graph traversals in #harfbuzz
Can #harfbuzz be used to find out if a Burmese string uses Zawgyi encoding?
Feeling drunk after writing this:
`total_transform.transform (transform.to_transform ());`
I posted some notes about what we have been doing this quarter re font technology at https://behdad.org/fonts2024q4 #OpenType #HarfBuzz #FontTools
I'm having some #harfbuzz / #freetype issues.
It would appear as though the offsets for the individual characters are always 0, which would be incorrect. This is causing all of the characters to be aligned to the top of the line instead of being in a nice line.
My code is based off of this documentation:
https://freetype.org/freetype2/docs/tutorial/step1.html
https://harfbuzz.github.io/a-simple-shaping-example.html
https://harfbuzz.github.io/integration-freetype.html
Code (an absolute mess):
https://gist.github.com/gudenau/b59baf006fee0de2b4fdd13033f5710b