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

[Jan Angermüller]

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 list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu

-- 
Jan Angermüller
Orchideenstieg 13
22297 Hamburg
Tel. 040 - 28 94 84 82
Mobil 0173 - 99 33 904
www.elbsound.studio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20230924/6c326ec1/attachment.htm>