How does one create the mathTable for a new font?

[verybadcat]

In iosMath, they load the mathTable from a plist file. I've translated that into this project by converting their plist into a json file. For example, I took their plist file with the same name, and converted it to create

https://github.com/verybadcat/CSharpMath/blob/master/CSharpMath.Ios/Resources/latinmodern-math.json

That's great, but where does their plist file come from? How would I go about getting the information for a new font?

[Happypig375]

@verybadcat See LayoutFarm/Typography#113 (comment)

[charlesroddie]

@Happypig375 has extracted relevant font information for use with the CSharpMath SkiaSharp renderer. This could be reworked into a layer that can generate files containing this information (in json or xml or code) without having to work it out at runtime. This info could shared with the iOS CSharpMath renderer (@verybadcat ) and with WPFMath (@ForNeVeR @alexreg @gsomix) if that would be useful.

[Happypig375]

I am sorry but I will have to disagree on this.

Point 1: Embedding OTF files require less space than for example, XML and JSON.

First of all, OTF files are just like any other file storage format, e.g. JSON and XML.
It contains font information that would be the same no matter stored in what format.
Just that OTF specialises in storing font information.
However, JSON and XML formats would require more storage space because of their formats, e.g. excess curly brackets for JSON, excess angular brackets for XML.
In contrast, OTF files store information in binary tables instead of plain text, so for example the number 67 would only require 1 byte to store in OTF whereas it would require 2 bytes to store in XML or JSON.
See the typical layout of an OTF file

Point 2: Reading an OTF file is easier than reading a JSON or XML file.

Reading OTF files are similar to JSON and XML files except simpler. This is because JSON and XML files for example store numbers in a variable number of bytes as these formats are text formats, not binary formats. The offsets are constant so less calculations have to be done.

Point 3: The Typography.OpenFont library is not that heavyweight.

It only parses an OTF file into data types which are directly referenced by CSharpMath.Rendering. There are little calculations needed in between reading the OTF file and supplying the values to the CSharpMath typesetter.

Point 4: Customisation

Really, the user can swap in any OTF file he/she wants instead of having to go through all these pregeneration steps.

[charlesroddie]

@Happypig375 Thanks for the info. As far as the details go, that sounds fine. You have addressed the efficiency part. There is another part which is whether to put this extraction of information in its own layer (which could be shared with or used by wpfmath) vs using Typography directly at the points where the info is needed. Do you have an opinion on that?

[Happypig375]

Is it even possible to construct such a layer? The two project's type system seem to be very different. Unless the two projects were to be merged together into one (unifying the type systems), the layer will be so transparent that using Typography directly might be more beneficial.

[Happypig375]

Merged into #12