First, I would like to express my gratitude to all who are putting countless hours of work into this incredible site. Thank you so much.
I am used to studying the suttas in English translation. But, I am also a native German speaker, and I have noticed that the German Umlaut symbols are often not displayed at all, instead only the plain vowel is shown. For example, instead of “geprägt” it would say “gepragt”. I attach a screenshot of the beginning of the Dhammapda as an example, but the problem appears also in other German translations. Attached is a screenshot of SN 56. I have not checked all of the German translations as I prefer the English translations anyway. Perhaps it is just a technical glitch? I am using Safari 10.1.2
This seems to be a Safari glitch. Safari 11.0.3 also doesn’t show the umlauts even though I can see them in the HTML.
However, on Chrome for mac they’re there.
Side-by-side you can see that the font rendering isn’t the same (Safari- left, Chrome -right)
This inconsistency in font rendering seems to extend to English language pages too.
Yes, the Safari diacritical bug. It is still a complete mystery to us, so if anyone has a tip, we need some sleuthing! My suspicion is that it’s an interaction between Webkit and Shadow DOM, and will only be fixed on an upgrade of Safari.
Bhante @sujato ,
The fonts aren’t rendering anywhere near the same in safari as Chrome.
Take my two screenshots in English. You can see the rendering of ‘minor collection’ for example. One is rendering in an upper case serif and the other in a very circular sans-serif.
<h1> and <h3> is also noticeably different too. The words are being rendered in an uppercase blackletter in dropcaps with tall x-heights and wider letters (and kerning) whereas in Chrome it’s a narrower letter and kerning with standard titlecase.
Doing further comparisons using the German DHP in FireFox 58.0.2, Chrome 65.0.3325.181, and Safari 11.0.3 we can see many differences between the font rendering across the 3 browser on the same Mac OS 10.12.6.
Here is a composite align off of the x-heights of the first word in the paragraph.
Blue is FF
Red is Saf
The difference between FF and Saf’s rendering is not much, but FF does include diacritics. Firefox also renders a heavier bold.
and a side by side comparison with x-heights of the first line aligned.
This little investigation is a bit outside of the scope of the OP sorry.
I just checked Chrome on WIndows 10 and the font renders similarly to the above Firefox screenshot (I have screenshots if needed).
It seems that adding
font-feature-settings: 'calt' 0;
to the css makes the umlaut reappear in safari
Fix source and more info
The glitch in open-type seems to only effect the first diacritic on a line!
Oh, great, well that’s an easy fix. @vimala can we apply
font-feature-settings: 'calt' 0; . I believe we are not using this CSS property anywhere, so if that is correct, we can simply apply it universally. (Having said which, perhaps we should be using this, it would probably be good in some languages. But anyway, we can look at this at a later date.)
The problem here appears to be that Chrome on Mac is not using the site fonts via
@font-face but is using system fallbacks. I don’t know why that would be so; it is a recent Chrome, and
@font-face has been well-supported for many years. Might you have some plugin that is blocking them, like an ad-blocker or some such? Normally that wouldn’t affect fonts, but who knows!
Otherwise, can you confirm that
@font-face is working on other sites. For example, https://www.theguardian.com/ should look like this:
Chrome is not my default browser. I was just using it to get the functionality not available to Safari yet. I have no plugins/extension.
Chrome is spitting a lot of errors and warnings. Here’s a PasteBin
The Gaurdian looks fine but I have to now read First Dog.
font-feature-settings: ‘calt’ 0; to the fonts and will upload to development today.
I just cannot test it at all.