After I start using the font files I added a line to wait 10 ticks with
messages. Same thing. I came up with a workaround though. If I set the rect of
an object to it's current rect it forces a redraw. Curiously, if I set the rect
of the entire stack to it's current rect it does NOT force a redr
I'm going through my code and disabling the places where I check if a
standalone is being built. I put that in there to try and get around the
problem where I get alerted that stacks are in use, but that code doesn't work
anyway. I still have to build one platform at a time, quitting LC between
Bob Sneider wrote:
> The fonts do not get included in a MacOS standalone
embedding fonts in a Mac standalone worked fine for me. Have you checked that
the fonts are actually in /Contents/Resources/_MacOS/ and your file
path when loading is correct
On the IDE problem
> when I quit Livecode, t
I did some testing. It only happens when loading font files for the first time
in a Livecode session from a script on MacOS. Once the font files are loaded, I
can close and reopen the stack and the appearance is correct.
It does NOT happen on Windows, nor does it happen with any fonts that are
Sorry to drag this thread on, but it appears that using embedded fonts is worse
that I first imagined.
After I had set all my label fields to Acme, I repositioned them so that they
were contacting the field to the right of them, and I right aligned them all so
they had a consistent look.
I jus
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 o
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
Other tools that we use have implemented CSS to manage this, but that does
not make it easier.
fonts have been a menace since we first had x-platform dev tools and
meaningful WYSIWYG rendering (Win 95?). at the time, dpi differences made
the issue impossible to resolve for smaller fonts, especially
It seems like you have an approach that can work well, despite being more
work.
Mainly shipping the fonts, which cancels out most of the issues, but
requires handling each case.
I don't know if any multi-platform dev tool deals with fonts without any
extra hoops.
If I recall correctly, flutter did
