[JW Lua] Finale crashes on Japanese fonts with FCFileInfoText:LoadComposer() ... revisited

[Robert Patterson]

I've done a lot of cleanup around text encoding. (I recently discovered
that syllable rawtext extraction fails if the lyrics contain non-ASCII
characters.)

But that doesn't mean I've found them all. Send me a text file that fails
and a .lua code snippet and I'll investigate. Looking at the code, the most
likely culprit is TrimEnigmaFontTags, but really it could be anything
including a Finale bug.

On Sun, Sep 24, 2023 at 5:14 AM Jan Angermüller <jan at angermueller.com>
wrote:

> Robert,
>
> I don't know if you have looked into this issue from May 2020.
> But I now had a client from Germany that ran into the same issue using
> German umlauts which I had always expected to be harmless.
>
> In Finale 27.3/macOS he used the following title in the "File Info"
> subtitle field:
> D´Mäerchen vum Liefkuchmeedchen
>
> Instead of the standard ä umlaut, it uses a unicode combination of an "a"
> followed by a ¨ which seems to lead to a memory problem which later on
> leads to a crash:
> D´Ma¨erchen vum Liefkuchmeedchen
>
> The crash is reproduceable.
> But: it occurs at anytime later during the plug-in processing. There is no
> specific line that leads to the crash.
> Sometimes the plug-in even finishes processing and crashes when it gives
> back the focus to Finale.
> At least on macOS - on Windows the subtitle line didn't cause any problem.
>
> As mentioned below, the crash can only be prevented by not calling this:
>     local fileinfo=finale.FCFileInfoText()
>     fileinfo:LoadSubtitle()
>     local text=fileinfo:CreateString()
>
> or by removing the a¨ from the subtitle and replacing it with a standard
> (one symbol) ä.
>
> While I assumed in the email from 2020 below that a multiple of a 0x0100
> symbol lead to the crash (which was the reason for a lot of crashes in the
> music font comparison), this crash occured with the unicode symbol 0x0308
> ("Combining Diaeresis").
>
> The problem is that I cannot detect this problem automatically.
> Because I need to have a look at the created string - but this is already
> leads to the crash.
> To solve this in 2020 I added an option to Perfect Layout that generally
> ignores all FCFileInfoTexts.
> But it's very difficult to tell for a user (and even for me as a support
> person) that this was actually the problem.
>
> Do you know if there is something specific in the FCFileInfoText()
> implementation that can lead to this unicode problem?
>
> Jan
>
>
> Am 10.05.2020 um 22:04 schrieb Jan Angermüller:
>
> Jari et al.,
>
> if I set the composer field in the Score manager to the following
> combination of Japanese and Western letters (with copy&paste), Finale
> crashes when calling  FCFileInfoText:LoadComposer() :
> 原 塁ABC
>
> Hope this text is sent correctly through the email, otherwise I'll post a
> Finale document with the text in a second email.
>
> Code snippet:
> local fileinfo=finale.FCFileInfoText()
> fileinfo:LoadComposer()
>
> The same crash occurs with the other FCFileInfoText objects (arranger,
> title etc.)
>
> I think it's caused because of the empty space which is symbol U-3000 in
> unicode (called "IDEOGRAPHIC SPACE").
> There was a JW Lua thread some years (resulting from the work on my music
> font comparison) where I noticed that some unicode symbols lead to crashes
> of JW Lua/Finale.
> I haven't found the email, but if I recall it correctly it was some
> multiples of 0x100 (though it didn't affect all multiples).
> If I change the second symbol to U-3001 it doesn't crash. This is the
> following snippet:
> 原、塁ABC
>
> Best,
> Jan
>
> _______________________________________________
> JWLua mailing listJWLua at jwmusic.nuhttp://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
>
> --
> Jan Angermüller
> Orchideenstieg 13
> 22297 Hamburg
> Tel. 040 - 28 94 84 82
> Mobil 0173 - 99 33 904www.elbsound.studio
>
> _______________________________________________
> JWLua mailing list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20230924/e2f66292/attachment.htm>