[JW Lua] SMuFL constants in JW Lua

[Thomas Weber]

Am 22.08.2015 um 22:16 schrieb Jari Williamsson:
> On 2015-08-22 17:09, Thomas Weber wrote:
>
>> I understand those "global" constants are so to say inherited from C++,
>> but as you're explicitly saying you'd like to include SMuFL support in
>> JW Lua, I'd suggest doing it the Lua way.
>
> The global "finale" namespace was a decision based on many factors, but the C++ namespaces were not one of them. The constants in C++ are contained in various class namespaces. But I agree that for some types of data, separate namespaces are indeed superior, and it would make much sense to me to move the FFUUID_ constants to their own namespace, since these are a separate entity compared to conventional PDK constants.
>


I see a major advantage of storing each enum constant type in a dedicated table.  It's possible to sensibly iterate over this data to find out what's available (no need to hard-code this into a script) and also make it easier to find out/display a human readable name given an ID.


> Your suggestion to base the SMuFL support on the .json files is good, specially since Lua is very well suited for the json file format. There are a couple of considerations:
> * Ease of use. It must be very easy and transparent for an end user of a script to get an script environment that works correctly with the fonts the user has on the computer.
>
> * Speed. The loading of the .json files must be fast. I think json table caches in JW Lua could be an approach.
>
> * Script convenience. The script programmer must be able to find the information in the tables in a predictable and secure way, with a syntax that is easy to use.
>


Makes a lot of sense to me.  What about developing the specifications for a SMuFL module collaboratively and implementing it afterwards?  The Wiki would be a nice place to start such an effort


> * To me, the most important json data to provide dynamically in tables are the font-specific metadata, such as the metadata in bravura_metadata.json. The 3 json files that are part of the SMuFL standard seems much more unlikely to change over time than the font-specific data.
>


While I can't say this for sure because Daniel Spreadbury doesn't seem to have made the "historic" JSON files available at smufl.org, I think that codepoints were added frequently, i.e. the JSON files *do* change from release to release.

But indeed, the most important files will be the font specific metadata files.  Those could be supplied for non SMuFL compliant fonts as well (one would however have to write them oneself).  The optionalGlyphs structure could be used to associate non-standard codepoints with proper SMuFL glyph names.  The user could then juggle glyphs by name, no matter whether the codepoint is SMuFL compliant or not.  (This use of the optionalGlyphs structure is arguably not precisely SMuFL compliant as the spec assumes optional glyphs to be in the range between U+F400-FFFF, but why invent an entirely different scheme for non-SMuFL fonts?)


>
> BTW, do you know if there are any guidelines for applications on how the SMuFL json files are to be installed/accessed in a notation program? For the Bravura font for example, the real benefits of the font and the SMuFL standard only becomes available if bravura_metadata.json file is available to the notation application.


I'm not aware of any such recommendations.  We could bring this topic up on the W3C community group.  As use cases are pretty divers (desktop, mobile, server, browser, different OSes), I doubt there'll be a definitive answer, but at least one would hear some opinions.  As this is mostly about Finale, it would be interesting to know how MakeMusic is planning to handle this.  Maybe the JSON files have potential to replace the .fan files?

In any case, on Windows I think such data should go somewhere in to the %APPDATA% folder.  No idea how to do it on the Mac.


Viele Grüße
Thomas Weber