iOS smallcaps bug

I came over a font bug (I think) in iOS, as follows:

We use the font Amiri on a web site where we, in good classical tradition, set authors’ names in references in Sᴍᴀʟʟᴄᴀᴘs (in the css). Amiri doesn’t have smallcaps, so the browser simply downscales the font instead. This works fine under both MacOS and Windows as well as on Android platforms—but not on iOS (12.1). There, the lower ASCII characters are displayed correctly, but letters containing additional diacritics, such as Ā, Ḍ, Ḫ, etc., end up as being represented by <! > (exclamation mark followed by a space).
Has anyone else come across a similar problem, and could give me a clue as to why this happens, what could be a possible workaround (other than using another font, which unfortunately is not really an option), and/or who else I could contact with this issue?

Thank you,
Albrecht Hofheinz

What is the url of your site?

User name: visitex
PW: a1yAm#6102


Is there any Arabic on the site that requires the Amiri font?

Yes, the site uses both Arabic characters and transliterated Arabic; that’s why we chose Amiri.

Can you use Amiri as a web font, so all browsers will temporarily download and use it to display the page?

That’s what we do. The font is not included on the site but referenced from Google Fonts. I’m aware of the fact that Google doesn’t host the latest version of the font; but also the latest version does not include smallcaps.

I can’t seem to find a page on the site that shows the problem. Can you post a specific url

I’ve found CSS font substitutions to be problematic, and they tend not to scale or render properly, if at all. Amiri is a beautiful font in English as well as Arabic, but it looks like it is a TrueType font. If I remember correctly, CSS font substitution works best with Web OpenType. Plain old regular OpenType doesn’t work as well across browsers. And a Google Font that renders beautifully in Chrome or on an Android might need to be specially designed so it would also work on Safari or iOS. Since Arabic fonts tend to have a lot more ligatures and ascenders/descenders, swash and stroke variants than English, this could also cause rendering problems. Sticking to common fonts might make your life a whole lot easier.

PS: I hate web typography.

It might work better if you include the whole font on the site, less approximation is a good thing. It’s worth a try.

See, for example, the array Baby Milk. If you scroll down to References, the second one should be ʿAfīfī, Hiba – with the first word set in smallcaps. A bit further down, you should get Dāliyā ʿUthmān, with both words in smallcaps. But on iOS, I only see <ʿAf! A ī> for the first case, and <A ! LIYā ʿUTHM! n> for the second.

The only ‘common’ serif font that is left if we want both diacritics and Arabic is Times New Roman; correct me if I’m wrong. I was trying to avoid TNR since I wanted something more beautiful… in the end, I may need to familiarise myself with how to include a font on the site as you suggest (I’m an amateur at this, and referencing the font from Google fonts was easier).

Why not use css to set a different font which has the small cap forms you need just for those reference names?

@tom3 : Amiri’s Latin character set is based on Crimson, so I had thought myself of using Google’s Crimson Text for the smallcaps. Unfortunately, however, the Crimson Text font provided by Google Fonts does not contain the needed diacritics. Using TNR, which does have the diacritics, would give ugly results.

Though I’ve never self hosted a font and hate coding, which I am not good at all, it doesn’t seem as confusing and time consuming as I thought it would be:

If you’ve got Dreamweaver or another web design application, it should make it easier.

Thank you @MMTalker, I have made a note to go through the w3schools tutorial so I can try if hosting the font on our website will help. But I’m wondering: currently, the font is being dowloaded from Google; what difference would it make to the end user if it was from Google or from our website they download the font? iOS might have exactly the same problem with not being able properly to downscale the diacritics… or am I wrong?

The font files on the Google site are sometimes different from the version you download and may not scale and/or render the same. Weighting can be quite different between the versions; compression is usually different, which can also create problems. And Google does update font files without notifying anyone, which can cause a big mess you won’t have anticipated.

Visitors on intranets that block certain types of downloads can cause visitors to be out of luck if they try to reach your site; many offices have them. And ad blockers have been known to sometimes have problems with Google fonts, esp. if the files are large or if there are many of them. I don’t know if this is still a problem; it was an issue a few years ago.

Maybe I’m wrong about this personal preference, but Google isn’t hosting fonts for free because they such a benevolent institution. They do because they want to track everyone every which way and as much as they can.

Thanks for your input @MMTalker. I keep my fingers crossed that hosting the font ourselves will help!

Just an update to let everyone know that hosting the font on our server did solve the problem :slight_smile: