Cross-platform font handling, and why you don't want to do it

Mon Sep 5 20:02:31 EDT 2022

Well, I am not aiming for *exact* visual match. What I WOULD expect is that if Livecode thinks the name of a font on the MacOS is “Aclonica Regular” then it would think the same thing on a Windows system. I’m talking about an embedded font file here. That “Aclonica” without the “regular” works on both platforms raises an eyebrow. Is LC for MacOS getting it wrong, or is Windows? 

Sent from my iPhone

> On Sep 5, 2022, at 16:23, Ralph DiMola via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Solutions before I tell my tales of woe.
> 
> Measuretext is a great high speed tool using a field's properties to calculate the width in pixels that the string will occupy when rendered. This can solve many kerning issues. The font size can be adjusted as needed to fit the text into a field without clipping.
> Measuretext is much faster than doing the measuring directly on the field(formattedWidth) if it has many lines.
> 
> Baseline and vertical position/size issues are different problems. Mac and Windows use their own font metrics tables for ascent and decent. Android uses Windows table. I don't know but I would assume that iOS uses the Mac(HHead) version. Don't know what Linux uses. 
> Doing height calculations and adjusting the top/bottom field margins gets you there.
> OR
> If you have an open source font and font editor, one can diddle the ascent/decent values for Windows and HHead(Mac). This can get you 99%+ identical rendering on Win/Mac. A lot of work for sure.
> 
> Browsers are another challenge I've seen the need for media calls for specific browsers in the css to make sure text will fit as intended. If you just check Chrome you get 65% of the market. Add Safari you get to 83%. Edge and FireFox get you to 90%. So to get to 90% you need to test 4 browsers, some on at least 5 platforms.
> 
> 
> <rant>
> I've had headaches and sketchy workarounds for font issues since I got into composition in 1994 with win 3.1, ATM and TT/Type 1 fonts.
> 
> I had the version problem with I believe Helvetica. Customer used the Adobe v1 version we had the latest vX version. We used their version of the font day one but then bought the entire Adobe font library. Our new users went to the library and suddenly one composer's text for this product flowed differently. WHAT??? After looking at everything else we discovered the version number was different(it was the file date that finally clued us in). The 2 versions(both from Adobe) did indeed kern slightly different.
> 
> We used InDesign and Word. One displayed the font family name and the other displayed the true font name on their respective font choosers. One would be "Bodini Heavy" the other was "Bodini 55". Confusing for sure.
> 
> Word will silently substitute a font for a close match on your system if you don’t have the exact font called for. If that person saves the file then when opened on a system with the proper font... the proper font is displayed on the screen but when creating a PDF the wrong font is used. The difference between screen and printed rendering might have been only on type 1 fonts? Don’t remember. The composer and I both try to forget that 10 hours we will never get back trying to figure that one out.
> 
> Roman Fonts with identical names is a constant issue.
> 
> Have a TT font and a font with the same name in another format(Type 1/OpenType) on your system(even if they are from the same foundry) and see how that works out. Not good...
> </rant>
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdimola at evergreeninfo.net
> 
> -----Original Message-----
> From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Quentin Long via use-livecode
> Sent: Monday, September 05, 2022 3:02 AM
> To: use-livecode at lists.runrev.com
> Cc: Quentin Long
> Subject: Cross-platform font handling, and why you don't want to do it
> 
> Cross-platform font compatibility is a hellacious rat's nest of mismatches. It may or may not be worse than handling time (Daylight Savings Time? leap years? leap *seconds*? etc, ad nauseum), but it's plenty bad enough on its own merits, or lack thereof.
> * You can't be 100% confident that your user will have the same font(s) you do installed on their system.
> * If your user has a font *of the same name* as your font installed on their system, you can't be 100% confident that *their* font came from the same font foundry as *your* font. Yes, font names are legally protected, but... Helvetica, anyone?
> * If your user has a font *of the same name* as your font installed on their system, you can't be 100% confident that it's the *same* font you have. Again: Font names are legally protected. But what if you have version 15.0 of RandomFontFoundry's WhateverFont on your system, but your user only has version 1.0 of RandomFontFoundry's WhateverFont? Who *knows* what tweaks RandomFontFoundry may have made to WhateverFont in between those two version numbers?
> * Can you be 100% confident that version 15.0 of RandomFontFoundry's WhateverFont *for Mac* is going to render *exactly the same* as version 15.0 of RandomFontFoundry's WhateverFont *for Windows* or *for Linux*? No. You cannot. Different type rendering engines on different OSes *ensure* that rendering compatibility will be problematic at best.
> * Assuming your user has exactly the same version of exactly the same font on exactly the same OS you do, you can't be 100% confident that your user has installed the font metrics data (kerning, sidebearings, etc)—which means you have no idea if the damn thing will look the same on your user's system as on your system.
> If you want to *ensure* that some piece of text looks *exactly the same* cross-platform, the only way to get there is to format the text the way you want it on one platform, take a screenshot, and use that graphic. But even then, can you be 100% confident that your user *hasn't* tweaked some setting on their system which messes with graphics..?
> 
> The "take a screenshot" solution is not well-suited for any use-case involving text which varies from time to time, and largely impractical for any use-case involving text which is input by the user. In principle, it should be possible to create a library of glyph-images of all glyphs in a font, and import those glyph-images as necessary—no, mass quantities of "set the imageSource of char X to $GlyphImage" commands ain't gonna fly, cuz letterspacing will look crappy—but that "solution" is tantamount to building your own, redundant, set of text-handling routines. Yuck!
> If "take a screenshot" doesn't work for you, I suspect the next-best route to achieving Absolute Cross-Platform Font Fidelity may be this:
> 1) Open up your font in your font-editing utility of choice (Fontographer, Glyphs, FontLab, whatever)
> 2) Export your font N times, once for each of the *other* OSes you need font compatibility with—WhateverFontMac, WhateverFontWindows, WhateverFontLinux, etc
> 3) Open up your stack within each of the OSes you're working with, always using the appropriate OS-specific version of your font, and see how different your stack looks on the other OSes
> 4) Tweak the font metrics on the other-OS versions of your font until your stack looks the same on all OSes
> 5) When it's time to distribute your stack, be sure to bundle *all* the hand-tuned OS-versions of your font with your stack This procedure is, of course, a royal pain in the arse. Hellacious rat's nest of mismatches, yada yada yada. But regardless of how painful it is? If you need absolute visual fidelity cross-platform, *and* total flexibility in the *content* of text, this procedure may be your least-bad option.
> As a perhaps-preferable option:
> 1) Open up your stack on each of the OSes you're striving for font compatibility on
> 2) Tweak the appearance-relevant text properties (textFont, textHeight, textShift, etc) on each OS until you get an acceptable approximation of identical appearance
> 3) Make note of the values of all these text properties for each OS
> 4) Assuming you have however-many fonts specified by fontName, be sure you bundle all those fonts with your stack when you distribute it
> 5) Include in your stack's preOpenStack handler a switch which includes "case = WhateverOS" for each OS you want font compatibility for
> 6) Within each OS's "case", set all the appearance-relevant text properties for that OS This procedure is not going to achieve anywhere near the degree of cross-platform font fidelity as the "roll your own" solution above. On the plus side, it's *significantly* less nitpicky/picayune/painful. You puts in your money, and you takes your chances...
> 
> "Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length" Read the webcomic at [ http://www.atarmslength.net ]! If you like "At Arm's Length", support it at [ http://www.patreon.com/DarkwingDude ]. 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode