<div dir="ltr"><div>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.)</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 24, 2023 at 5:14 AM Jan Angermüller <<a href="mailto:jan@angermueller.com">jan@angermueller.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    Robert,<br>
    <br>
    I don't know if you have looked into this issue from May 2020.<br>
    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.<br>
    <br>
    In Finale 27.3/macOS he used the following title in the "File Info"
    subtitle field:<br>
    D´Mäerchen vum Liefkuchmeedchen<br>
    <br>
    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:<br>
    D´Ma¨erchen vum Liefkuchmeedchen<br>
    <br>
    The crash is reproduceable. <br>
    But: it occurs at anytime later during the plug-in processing. There
    is no specific line that leads to the crash. <br>
    Sometimes the plug-in even finishes processing and crashes when it
    gives back the focus to Finale.<br>
    At least on macOS - on Windows the subtitle line didn't cause any
    problem.<br>
    <br>
    As mentioned below, the crash can only be prevented by not calling
    this:<br>
        local fileinfo=finale.FCFileInfoText() <br>
        fileinfo:LoadSubtitle() <br>
        local text=fileinfo:CreateString()<br>
    <br>
    or by removing the a¨ from the subtitle and replacing it with a
    standard (one symbol) ä.<br>
    <br>
    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").<br>
    <br>
    The problem is that I cannot detect this problem automatically.<br>
    Because I need to have a look at the created string - but this is
    already leads to the crash.<br>
    To solve this in 2020 I added an option to Perfect Layout that
    generally ignores all FCFileInfoTexts.<br>
    But it's very difficult to tell for a user (and even for me as a
    support person) that this was actually the problem.<br>
    <br>
    Do you know if there is something specific in the FCFileInfoText()
    implementation that can lead to this unicode problem?<br>
    <br>
    Jan <br>
    <br>
    <br>
    <div>Am 10.05.2020 um 22:04 schrieb Jan
      Angermüller:<br>
    </div>
    <blockquote type="cite">
      
      Jari et al.,<br>
      <br>
      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() :<br>
      原 塁ABC<br>
      <br>
      Hope this text is sent correctly through the email, otherwise I'll
      post a Finale document with the text in a second email.<br>
      <br>
      Code snippet:<br>
      local fileinfo=finale.FCFileInfoText() <br>
      fileinfo:LoadComposer()<br>
      <br>
      The same crash occurs with the other FCFileInfoText objects
      (arranger, title etc.)<br>
      <br>
      I think it's caused because of the empty space which is symbol
      U-3000 in unicode (called "IDEOGRAPHIC SPACE").<br>
      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.<br>
      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).<br>
      If I change the second symbol to U-3001 it doesn't crash. This is
      the following snippet:<br>
      原、塁ABC<br>
      <br>
      Best,<br>
      Jan<br>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
JWLua mailing list
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a>
</pre>
    </blockquote>
    <br>
    <pre cols="72">-- 
Jan Angermüller
Orchideenstieg 13
22297 Hamburg
Tel. 040 - 28 94 84 82
Mobil 0173 - 99 33 904
<a href="http://www.elbsound.studio" target="_blank">www.elbsound.studio</a></pre>
  </div>

_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a><br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>