πΎ Archived View for bbs.geminispace.org βΊ s βΊ Lagrange-Issues βΊ 16 captured on 2023-06-16 at 17:15:39. Gemini links have been rewritten to link to archived content
β¬ οΈ Previous capture (2023-06-14)
β‘οΈ Next capture (2024-02-05)
-=-=-=-=-=-=-
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.
Visual Gemtext Primer (scroll to the bottom)
The character not being correctly rendered is an alef, I've been told. Here a screenshot:
"This is an example." in RTL Arabic rendered in Noto Sans
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 Safari and Firefox, as you can test yourself on a simple demo page:
HTML RTL Test of "This is an example." in Arabic
Copy and pasting the Arabic sentence into the "Add text" dialog also results in mis-rendering of the alef.
Lagrange 1.15 (7) on iOS 16.5 with Inter and Lagrange 1.16 (B19) on Android 11 (CalyxOS) with Roboto display the alef correctly.
Lagrange 1.16.1 on Fedora 38 with Noto Sans and Roboto displays the alef correctly.
π Issue #16 in s/Lagrange-Issues
2023-05-24 Β· 3 weeks ago
Added info about behavior on iOS and Android
The text renderer is the same on all platforms, so the difference must come from the set of installed fonts.
If you go to "about:fonts" on your Mac, which fontpacks are enabled?
Added info about behavior on Linux
Yay, disabling every font except macos-system-fonts and notosans-set fixes the problem. I'll keep investigating.
The culprit is noto-emoji, which I installed from
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.
The culprit is noto-emoji
Hmm, something in there must be affecting the glyph lookup order.
