Cross Platform Font Layout - current workarounds

Tue Aug 25 14:32:52 EDT 2020

Sean Cole wrote:

 > I assume (dangerously) from your reply that you do not have to make
 > real world applications for corporate branded customers. Where design
 > has been done by a branding team with a 12 - 120 page Production
 > guide). Someone like the BBC....

A good way to analyze a problem is to find existing examples of how 
successful organizations handle the problem we're facing.

With font rendering across platforms, we can look at how BBC themselves 
handle that.

In this image you'll find two screen shots of a lead story block from 
bbc.co.uk/news, where the top image is from macOS and the bottom from 
Windows.  Both had the latest OS versions, and both used the same 
browser version (freshly-downloaded Chrome, the world's most popular, so 
a good test case), where the browser window was set to the same width 
(1020px):

http://fourthworld.net/lc/Mac-Win-Fonts.png

Evident differences include:
- text weight
- kerning
- leading
- antialiasing

Indeed, the kerning differences are pronounced enough that even BBC's 
expert web team using a modern CSS spec designed by experts and rendered 
in a browser made by one of the most powerful corporations on earth is 
still so pronounced that both the story's title and summary wrap 
differently between the two platforms.

Operating systems matter, and even the best effort to reduce the effects 
of the differences between them cannot make them the same, as they are 
made by very different organizations with very different methodologies 
and priorities.

The article Jacque provided was useful, relevant, succinct, and 
apparently ignored, so it's worth including here again:

https://damieng.com/blog/2007/06/13/font-rendering-philosophies-of-windows-and-mac-os-x

Since everything we've ever seen in all of computing reminds us that 
different OSes behave differently, when we want a given font rendering 
to be identical on both platforms, as Richmond noted we can generate an 
image of the text we want and use the image instead of the text.

That is of course impractical and often undesirable for body text, which 
is why body text is frequently seen differently on different platforms. 
But for absolutely critical elements like logos, it's what most experts 
do.  Indeed, the BBC logo could have been implemented as a font, but for 
precision across platform apparently they chose to use an SVG file.

 > It is arse-umed that how it looks on Windows is how it should look on
 > any other platform we distribute to including the various output sizes
 > (1024x576SD, 960x540HHD, 1920x1080HD, 3840x2160 4k). Everything has to
 > match to the pixel. Thats how branding works.

Apparently for their most visible asset, their web site, BBC feels 
branding can be driven by other priorities according to the relevance of 
a given element to their brand: logos are images, article text is left 
to the OS.

--- On the inherent difficulty of the task:

 > We have no issue with that moving between platforms in editing and
 > graphics platforms, so post production facilities (mine included)
 > could not conceive or perceive that it would be any different in a
 > development environment. Design it in photoshop on a pc and send it
 > to your colleagues working in After Effects on a Mac and send it back
 > to an editor on a PC running Premiere and it looks the same end to
 > end. That is just the way it is!

That's "just the way it is" in highly specific circumstances in which 
you exercise great care with how the document is set up and limit what 
you're doing to a narrow subset of software that includes its own 
font-rendering subsystem.

You will not find this in word processors, or spreadsheets, or database 
front-ends, or the web, or most other software outside of specialized 
graphics productions tools.  Even in programs that allow custom kerning, 
like some word processors, will show differences in line wrap between OSes.

It would be nice if any single tool could do all things that all 
possible software can do.  But nothing in the universe works like that, 
and software is no exception.

Thankfully, with extensibility mechanisms like widgets, FFI, and 
externals, LiveCode can be a foundation to include things far beyond its 
out-of-the-box capabilities.  If you want to embed a custom font 
rendering subsystem, I'll be it would cost you no more than Adobe spent 
developing theirs (which, given the considerable time, expertise, and 
licensing required, I'd venture to guess would cost somewhere between 
US$100k 200k, possibly more).

While you ponder funding sources for that, you could just as easily do 
what other production companies like my friends here in Hollywoodland 
do, and as Richmond suggested earlier: if you want pixel-perfect 
identical rasterization across platforms, rasterize it yourself to your 
satisfaction and use the resulting image in production.

Rasterized output is how Photoshop is most commonly used in production.

--- On the larger issue of workflow pressure:

 > So, after developing at a stupid rate, 12 solid 14-18hr days, we have
 > the finished app layered out (dont get me back on the layering
 > embargo), animated with text & graphic moves and effects, ready for
 > deployment out to Mac and PC. Tick the boxes in the standalone
 > settings, build and open in their respective platforms.
 >
 > Only to find that everything you had laid out perfectly matching on PC
 > is totally screwed on the Mac. Opening up the stack on the Mac, its
 > the same thing. Now with only one day to go I am forced to work out
 > the fastest way to realign every text box...

This circumstance seems a common source of complaint:  you develop a 
system, do not test it in a production environment until close to 
production, discover differences between your development and deployment 
systems, and feel pressure to adjust for those differences in the small 
amount of time remaining.

To solve the issue, we can start by reviewing the problem constraints we 
know with certainty:

- We cannot control how operating systems are made.

- Given differing goals and needs, differences between development
   and deployment systems are inevitable.

- Motion picture and television production schedules require
   coordinating so many resources that it's nearly impossible
   to shift deadlines.

Given these constraints, the problem becomes solvable by tailoring your 
schedule and workflow to incorporate review on the delivery system 
earlier in the process, and ongoing throughout the work.

 > As I said in my very last post, I DID A PAINFUL AMOUNT OF RESEARCH
 > INTO THE BEST SOLUTIONS FOR HIM AND THE OTHERS. Saying 'I'm sure there
 > are...' doesn't make them suddenly spring up....

The absence of tools that meet your expectations suggests altering 
expectations.

Or finding suitable investment to build such a tool.

Either way, you are in control of the situation.

--- A tautology as purchasing guidance, with historical lesson learned:

 > Trust, I have done painful amounts of research into the best solutions
 > for him and the others. Then I ASKED LC to ensure they were committed
 > to fixing the issues and continue the HTML development...

At any given moment, with all things, what you have in hand is what you 
have in hand.

If you have a statement of intentions, then what you have is a statement 
of intentions.  They may be good intentions, and where intentions are 
what you're looking for go for it.

But if what you're looking for is finished software that fully meets 
your needs, anything other than finished software that fully meets your 
needs isn't what you're looking for.

Once upon a time I invested heavily in SuperCard for Windows.  It never 
shipped.  Good team, good funding, good intentions.  Things happen.

When I invested, what I had in my hands was not a version of SuperCard 
running on Windows.  What I had was a description of SuperCard running 
on Windows.  But it turns out that a description of software isn't software.

So this is helpful guidance, which I've written here many times over the 
years and will repeat again:

Only finished software you can evaluate firsthand is finished software 
you can evaluate firsthand.

--- On deploying to the Web:

I invested in the HTML fundraiser too.  But I consciously invested in a 
*description* of a system with a prototype. I did my research on what 
Emscripten is, and what it isn't. And after having done the due 
diligence I do with any investment, I adjusted my expectations and 
invested just the same.  But at no point did I believe I was investing 
in anything other than what it is: a scripting language translated into 
another scripting language with an object model rendered inside an alien 
object model. I understand the limits of such an attempt, and never 
imagined it could be finished for the proposed budget. I invested 
because I felt worthwhile things may be learned along the way.

My investment was made with eyes wide open, and I made it not because I 
needed it. If I truly needed it I would have waited until it exists so I 
could see if what exists might be what I need.

I do web deployments every day. Most of my clients are enjoying 
satisfying blends of native LC apps with all the benefits of web 
deployment: instant updates, shared data across devices, collaborative 
workflows, etc. Total freedom, total feature parity, with tailorable 
security giving me more options than browsers allow for desktop 
integration, or even more secure than most browsers, as any given 
project might need.

I've been doing this for 20 years.

I just don't limit my work to the confines of a browser window. I use 
the web protocol inside a standalone.

When I *must* run something in a browser window (fewer circumstances 
than some might think), I choose the with-the-grain way to do that, 
using browser-native methods (HTML/CSS/JS).

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com