Here are some test screenshots to begin getting to the bottom (or baseline)
of the issue.

Mark claims that how they appear in WordPad and TextEdit are how it should
appear in LC. Lets test that. Here's WordPad in Windows (native). Arial
then the custom OTF font I was using both at 40pt

https://www.dropbox.com/s/ufmt8dt8c7wid6y/WordPad-Demo.png?dl=0
https://www.dropbox.com/s/sn3b1r54kpbwqyf/TextEdit-Demo.png?dl=0

Then both together:
https://www.dropbox.com/s/ujdngwrruk89u4o/WP_TE-Demo.png?dl=0
Pretty identical. Even these two basic programmes can get it right.

Now LC:
PC: https://www.dropbox.com/s/2da8juirgqsa4zd/PC-Demo.png?dl=0

then load the stack up in MacOS LC and put the screenshot of the PC-Demo
underneath it and fade to 50%:
https://www.dropbox.com/s/8vknqpptq71n4z2/Mac-Demo.png?dl=0

So what seems to be happening here is that the 'top' of the text box is not
referring to the same baseline height in relation to the text within it.

And I think THAT is the key here. However it is that LC calculates the
distance between the top of frame and the baseline is incorrect. In fact,
I'm not sure at all how they are working it out having done a bit of maths
derived from what I have found. Heres some other grabs that highlight the
differences, if you're interested. You can do your own maths (don't trust
mine):

https://www.dropbox.com/s/ezo1pny2dhouqy8/Windows-FontLayout.png?dl=0
https://www.dropbox.com/s/cskjaafbz32vbyj/Mac-FontLayout.png?dl=0
https://www.dropbox.com/s/m3wf2mj1h7dk1fl/Screenshot%202020-08-25%20at%2022.13.57.png?dl=0
https://www.dropbox.com/s/759z1rknopjts2a/Screenshot%202020-08-25%20at%2022.15.23.png?dl=0
https://www.dropbox.com/s/65njh5k0vkbfivz/Screenshot%202020-08-25%20at%2022.28.37.png?dl=0
https://www.dropbox.com/s/6k60neuxeolvi46/Screenshot%202020-08-25%20at%2022.34.42.png?dl=0
https://www.dropbox.com/s/3eugkbb7q05ydbo/Screenshot%202020-08-25%20at%2022.55.05.png?dl=0
https://www.dropbox.com/s/fj0pi087ss3hpbw/Screenshot%202020-08-25%20at%2022.57.35.png?dl=0
https://www.dropbox.com/s/d8cxd2bp9vigbsv/Screenshot%202020-08-25%20at%2022.59.12.png?dl=0
https://www.dropbox.com/s/q0bnf5lkmtss1sq/Screenshot%202020-08-25%20at%2023.02.29.png?dl=0
https://www.dropbox.com/s/ynerw1m77p0p745/Screenshot%202020-08-25%20at%2023.08.38.png?dl=0

That should be enough along with your own testing to work it out.

Sean Cole
*Pi Digital Productions Ltd*
www.pidigital.co.uk
+44(1634)402193
+44(7702)116447
'Don't try to think outside the box. Just remember the truth: There is no
box!'
'For then you realise it is not the box you are trying to look outside of,
but it is yourself!'

eMail Ts & Cs <http://pidigital.co.uk/emailTCs.rtf>   Pi Digital
Productions Ltd is a UK registered limited company, no. 5255609


On Wed, 26 Aug 2020 at 00:24, Sean Cole (Pi) <s...@pidigital.co.uk> wrote:

> Mark,
>
> thanks for the response although only partially addressing the issue. That
> article (the first one to come up on a google search, so well done on your
> 'research') is aimed at web layout in a browser. NOTHING to do with desktop
> platform rendering which is a wholly different subject. And the writers
> 'hack' is not universal and only works based on that particular font. A
> very makeshift workaround (which is what we are incumbent on because of all
> the bugs (below) not yet ironed out - AFTER MANY YEARS!)
>
> Heres a far more relevant article by, yep, Adobe.
> https://helpx.adobe.com/uk/photoshop/using/fonts.html Look at the
> OpenType fonts section. The fonts I use are ALWAYS otf. Without fail. As
> Adobe says, "OpenType fonts use a single font file for both Windows and
> Macintosh computers, so you can move files from one platform to another
> without worrying about font substitution and other problems that cause text
> to reflow". They are platform agnostic. There are some caveats, for sure,
> but within the constraints of LC with its own engine, these won't apply. An
> OTF installed on ANY platform (other than a browser) will render
> identically with regards size, shape, height, line height, kerning and so
> on. There's no variance. It's pure mathematics. That's the point! (
> https://en.wikipedia.org/wiki/OpenType)
>
> Spelling it out to you, here are all of the related bug reports. Confirmed
> bug reports. Confirmed they are bugs. Bugs that Can and Should be fixed. It
> won't take 10s of 1000s of $ as whatshisface Gaskin made it seem. I have
> and DO code workarounds for it all the sodding time. But CODE
> ONCE!!!!!!!!!!!!!!!!!!!! Pfft, CODE ONCE. I AM SICK OF ALL THIS BS BEING
> THROWN BACK AT ME as if it's me that caused the issue. SERIOUSLY!!!!!! YOU
> all MAKE ME WILD with all your apologist brushing off and glossing over.
> MAKE IT FLIPPIN WORK!!!!
>
> https://quality.livecode.com/show_bug.cgi?id=2707
> https://quality.livecode.com/show_bug.cgi?id=2081
> https://quality.livecode.com/show_bug.cgi?id=3076
> https://quality.livecode.com/show_bug.cgi?id=12176
> https://quality.livecode.com/show_bug.cgi?id=13551 (sideways related)
> https://quality.livecode.com/show_bug.cgi?id=18748 (Related and listed by
> none other than Whatshisface Gaskin himself!)
> https://quality.livecode.com/show_bug.cgi?id=19513
> https://quality.livecode.com/show_bug.cgi?id=21426
>
> Plus all of the 'Duplicate' references therein.
>
> If you are changing font or having to use different font between system I
> can FULLY understand why they would appear different. Even something like
> Arial in one system is bound to not be exactly the same font in both
> systems. I totally accept that fact and have to deal with it accordingly.
>
> BUT if the font is a custom, professionally made font or even a freebie
> crap font, installed on both systems they should appear the same size (the
> point size is not some arbitrary number) with the same fixed line height
> and formattedHeight (again, not arbitrary) with identical baselines
> calculated in exactly the same way. It's basic maths. It's an engine fault,
> not a system one. It requires a teeny bit of scientific testing with some
> custom fonts between platforms.
>
> --
>
> Based on the above reports and others like them, it's evident I'm not
> making this up, or being precious or getting worked up over NOTHING! We
> should get what we pay for and what LC advertise on their virtual box
> (landing page).   *I* didn't say it's CODE ONCE.    *THEY* put it like
> that! If it's not something LC can live up to they should change it. You
> can barely code once anything in lc that is cross-platform. Seriously,
> prove me wrong! But don't demonise me. I wasn't the one to make the claim.
> I'm pointing out how false it is and trying to get things working as they
> should. And certainly don't try to pull the wool over my eyes with
> incredibly badly thought out reasoning. I'm done with people fobbing me
> off.
>
> Sean Cole
> *Pi Digital *
>
> On Tue, 25 Aug 2020 at 19:51, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> On 2020-08-24 21:49, Sean Cole (Pi) via use-livecode wrote:
>> > My client provided the font they needed in line with their tv show
>> > brand.
>> > They need the app to work both PC and Mac. It seems I have to manually
>> > go
>> > through each field, button and widget and make sure they are laid out
>> > properly. The left, right, center alignments don't always match and the
>> > vertical position certainly never matches.
>> > https://www.dropbox.com/s/v50aj7uv06bh4d9/MacText.png?dl=0
>> > https://www.dropbox.com/s/pry5teqp89xzbun/PCText.png?dl=0
>>
>> I suspect the main issue with vertical alignment here is to do with the
>> font.
>>
>> This very readable article contains the relevant information here as
>> well as how the problem can be resolved:
>>
>> <
>> https://www.williamrchase.com/post/font-height-differences-between-windows-and-mac/
>> >
>>
>> TL;DR; version - the custom font probably does not have the correct
>> settings/tables for use in programs which use the system text engines on
>> *both* Mac and Windows.
>>
>> FWIW, LiveCode fields try to match the way the running platform displays
>> text in OS editable fields.
>>
>> Specifically, text in a field on macOS will look almost the same as that
>> in TextEdit; and text in a field on Windows will look almost the same as
>> that in WordPad (DPI differences taken into account - LC assumes 72dpi,
>> Win assumes 96dpi).
>>
>> Unfortunately this means you do need to do some work (i.e. scripting) if
>> you want to use LiveCode fields in more 'graphical' situations - e.g. as
>> the labels on custom buttons.
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> P.S. It is perfectly possible that fettling with the metrics detailed in
>> the article above would mean you could achieve identical vertical layout
>> on macOS and Windows but it isn't something I have actually tried.
>>
>> --
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create app
>>
>> _______________________________________________
>> 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
>>
>
_______________________________________________
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