Control Typography memory usage

[charlesroddie]

CSharpMath uses a lot of memory via Typography:

Possible improvements would be some combination of loading glyphs lazily and storing them more efficiently.

Can this be improved from within CSharpMath or should this be an issue in https://github.com/LayoutFarm/Typography ?

[Happypig375]

Currently CSharpMath stores Typeface objects in memory which is basically an entire otf file parsed into table objects. latinmodern-math.otf weighs 717KiB, and AMS-Capital-Blackboard-Bold.otf weighs 8.51KiB. However, the inclusive size shown is an order of magnitude larger than the size of the source files.

[charlesroddie]

Presumably the issue involves:

1. Loading an entire font at a time rather than characters lazily
2. A memory-inefficient representation of a character

Are both of these issues for the typography repo, or is there anything that can be improved here?

[Happypig375]

@prepare Thoughts?

[prepare]

I think some objects could be unloaded/dispose
eg.

1. List<Type2Instruction> could be unload after you create a glyph outline from it.
2. Unload many openfont tables that are not need by user

but this I have to test it first

[prepare]

please visit and test 'Trimmable features' again, see=> LayoutFarm/Typography#187

[Happypig375]

So there are two ways forward with the Typography submodule:

• Drop Nullables!! LayoutFarm/Typography#192 and update
• Merge latest Typography into Nullables!! LayoutFarm/Typography#192 and resolve conflicts (and do them again for future updates)

@prepare @charlesroddie Thoughts?

[charlesroddie]

I don't believe CSharpMath is affected much by the NRT PR LayoutFarm/Typography#192. That PR makes it easier for Typography to control NRE bugs and to do further development without having to worry about NREs. However it's not worth forking Typography just for that. If the @prepare prefers to do more work to implement features safely that is up to him!

CSharpMath should depend on Typography master branch if possible, through the submodule for now, and through a nuget package when Typography stabilizes.

Note that it can't use the current state of Typography master as UWP support is broken by the netstandard2.1 change.

[prepare]

Hello

Note that it can't use the current state of Typography master as UWP support is broken by the netstandard2.1 change.

I move back to netstandard 2.0, please check again :)

LayoutFarm/Typography@0899ddf

[Happypig375]

@charlesroddie How the NRT PR affects CSharpMath can be seen through the difference between using null-oblivious and null-explicit APIs. By dropping the current submodule reference to LayoutFarm/Typography#192, all Typography APIs currently is use will start ignoring accidental nulls during compile-time, leaving bugs to be caught run-time.

[Happypig375]

@prepare @charlesroddie Seems that LayoutFarm/Typography#192 will never be merged. Should we drop it and update or should we resolve merge conflicts?

[charlesroddie]

That is a shame if true. @prepare it would be good to have your thoughts on that PR even if in an initial form. Maintaining a branch or fork of typography for use in CSharpMath would require a lot of work on @Happypig375 's part, and is unfeasible to maintain indefinitely IMO. So if it will really never be merged then dropping and accepting a less safe typography library for use in CSharpMath is inevitable.

[prepare]

@Happypig375 👍

I want to confirm that the LayoutFarm/Typography#192 is NOT your waste time.

But I can't merge it directly now because of this LayoutFarm/Typography#192 (comment) too.

---

By the way,
The Typography (TextServices, TextSpanPrinter etc.) is now under refactoring-code-arrangement phase again,

It will be released this week.