Thanks Neville, for doing this research, noting your results in public and
putting together the library of corresponding font names.
Your effort will make it easier for livecode to fix things up.
I have some plans for doing some more advanced font work, so I'm sure down
the road it will help me also.
Thanks again,
Tom
On Fri, Oct 28, 2022 at 8:00 AM Neville Smythe via use-livecode <
use-livecode@lists.runrev.com> wrote:
> In my last post I alluded to an elusive problem on Windows 10 with the
> fontnames function. I think I have identified at least one circumstance
> where fontNames() causes a crash on Windows 10.
>
> If in a Windows standalone you call
>
> stop using font file foo.ttf
>
> and then try to get fontNames() without first calling
>
> start using font file bar.ttf
>
> for some font bar.ttf
>
> I get a crash (or, if I use a try wrapper or errorDialog handler, "error
> in statement get the fontNames”. Thereafter any call to fontNames will
> fail, so something is fatally corrupted). In the IDE the code works as if
> there had been no error but the list of fonts returned may be corrupted,
> it may for example contain foo.tff. The same code works without error on a
> Mac.
>
> Most apps will probably just start using some custom fonts when they
> launch, and then stop using them when cleaning up, so will not be affected
> by this bug. In my case I am examining a sequence of custom fonts, adding
> one at a time and removing it before processing the next.
>
> As it turns out I didn’t need to call fontNames() directly after stop
> using one font and before adding the next font. When this nugatory bit of
> code was rewritten it all worked happily - well, almost: in processing 4000
> font files I still got that “error in statement” error 16 times, seemingly
> randomly and not fatally. Running the code again on just those 16 fonts had
> no problems, so it is not a case of corrupted fonts. Which means there is
> still a problem lurking there, my guess being that stop using font file can
> leave some font library in a fragile state. The Windows 10 system font
> cache is evidently well-known for being easily corrupted and perhaps that
> is what is going on here, but somehow I feel this is an LC problem because
> the font rendering itself seems to be OK.
>
> Anyway I have my data so I can ignore the problem for now: for those who
> came in late I am compiling a database of fonts to provide the different
> fontnames used by the 3 platforms for each font, and the lengths of
> rendered strings and their ascent and descent for cross-platform layout and
> vertical alignment. When that is done I shall put together a bug report for
> Quality Control.
>
>
> Neville Smythe
>
>
> ___
> 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
