💾 Archived View for bbs.geminispace.org › u › michaelnordmeyer › 900 captured on 2024-05-26 at 17:23:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
Re: "RTL rendering broken with noto-emoji from skyjake.fi/fonts/..."
Added info about behavior on Linux
2023-05-24 · 1 year ago
🍵 michaelnordmeyer [OP] · 2023-05-24 at 16:16:
🍵 michaelnordmeyer [OP] · 2023-05-24 at 16:19:
Yay, disabling every font except macos-system-fonts and notosans-set fixes the problem. I'll keep investigating.
🍵 michaelnordmeyer [OP] · 2023-05-24 at 16:24:
The culprit is noto-emoji, which I installed from
🕹️ skyjake [mod...] · 2023-05-24 at 16:27:
If you disable everything except macos-system-fonts and notosans-set, and set your fonts to Roboto/Roboto, does the Arabic then render correctly?
It is rendering correctly on my Mac with Literata and notosans-set.
From your primer:
Consecutive whitespace like spaces, tabs, or blank lines wonʼt be compacted into one.
This is incorrect. The spec says only newlines should be preserved as-is. Other types of whitespace can be normalized as the client sees fit.
🕹️ skyjake [mod...] · 2023-05-24 at 16:30:
The culprit is noto-emoji
Hmm, something in there must be affecting the glyph lookup order.
I added some RTL text to my Gemini Visual Primer page, which doesn't render correctly, even though the fonts are able to do this. [gemini link] Visual Gemtext Primer (scroll to the bottom) The character not being correctly rendered is an alef, I've been told. Here a screenshot: Used environment: Lagrange 1.16.1 on macOS 13.4, rendered with either Inter or Noto Sans fonts. The Noto Sans font package is the large noto-sans-set (43.5 MB) provided by Lagrange. Noto Sans renders this correctly in...
"This is an example." in RTL Arabic rendered in Noto Sans
💬 michaelnordmeyer · 8 comments · 2023-05-24 · 1 year ago · #bug ✔︎
