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. That’s 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 (don’t 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, it’s
> 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
 ____________________________________________________________________
 ambassa...@fourthworld.com                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to