[Interest] cross-language matching of QStrings: partial success only?

[René J.V. Bertin]

On Monday May 11 2015 23:00:36 Till Oliver Knoll wrote:

Hi,

Didn't see your message before sending my previous reply.

> Each name record is associated with an Encoding ID and Language ID. It would be no fun if those IDs would be interpreted the same across platforms (that's why we have cross-platform toolkits such as Qt to deal with that mess ;)):

I don't think Qt is dealing directly with TTF or OTF files, but rather uses whatever the OS gives it. Did I miss something?

> It goes without saying that Language Tags may or may not be supported on a given platform. The same goes for "platform specific" Language IDs: so a Windows platform may or may not understand the Macintosh Language IDs and vice versa.

Yeah, that's probably why that Segoe UI font (copied from a -French- MS Win7 machine) showed me weights like Negrita and styles like Cursiva on OS X (set to UK English) until I removed all translations.

And I realise now that where font tweakers like FontForge show strings there may indeed be some numerical ID that's stored in the font file.

> All said, I don't even know how Qt deals with that: e.g. does QFontInfo::family return the english name, if available? Or the "localised name" depending on the system language? Or "first found, first returned" (aka "undefined behaviour")?

I haven't been looking at all at the family names, partly because there at least I never got a different family than the one I asked for, but also because I cannot recall ever having seen a font with a translated name. But that's probably because I never set my system to Chinese, Hebrew or Hindi.
For weight and style names, certain functions at least seem to return translated versions. But it's quite easy to get lost very quickly trying to figure out where the data comes from, at least if you're basically reverse-engineering as I am.


> But IF you have that, you could do a heuristic matching by:
> 
> - always compare english values
> - if not, translate into english values first by
> - having a predefined set of "supported languages" for typical font names and styles: "bold", "fett", "gras" etc

That exists (translate("QFontDatabase","Bold")) but only for a limited subset of font styles and weights.
> - Have fun!
> 
> ;)

Right :)

Which leads to a bit of a dilemma: how do you handle a situation where you can improve a feature but in the end only for users who use English?

R