RazrFalcon
Parse and Read data from file?
ttf_parser initialize face by raw data, do you have a plan to support init face by file through a path pass-in like freetype? This is very useful in Iot devices
Can you give an example?
In FreeType, FT_New_Face( FT_Library library, const char* filepathname, FT_Long face_index, FT_Face *aface ) pass in a 'filepathname'. During creating FTFace/TTFace, some tables are loaded into memory, some are not, etc 'glyf'. 'glyf' table is always the biggest table in truetype, can not be loaded into memory in Iot devices sometimes. So freetype read glyph data by FT_Stream_Seek and FT_Stream_Read.
Hi, let me join the discussion, because we also have a similar issue.
This is how ttf-parser works to begin with. It never allocates.
From our POV, it's not about allocating memory while parsing, it's about the requirement of having the whole font file stored in memory to begin with.
We use ttf-parser in Ruffle, and we have encountered this issue while implementing support for multiple fonts and scripts. I guess having one font file loaded into memory with latin script is fine, but if we want to cover Arabic, Hebrew, Chinese, Japanese, Korean, Emoji, etc. at the same time, the memory footprint is huge.
So we're now wondering what's the bigger performance hit: using a lot of RAM that is unneeded but loading glyphs fast, or keeping low memory footprint while wasting time on reading font files in their entirety when loading new glyphs.
According to my knowledge, FreeType uses the fact that it can seek inside files to solve this issue: the font file is never stored in memory in its entirety, but specific parts of the file are loaded on demand (e.g. when loading glyphs). We don't have to store the entire file in memory and we also don't have to read the entire file when loading glyphs. Sadly, that's something that would have to be implemented in ttf-parser, as memmapping in Rust is inherently unsafe.
Are there any plans to add such feature to ttf-parser? It would be enough to allow passing Read + Seek in addition to (or instead of) &[u8].
as memmapping in Rust is inherently unsafe
That's the only sane way to work with fonts and that's what all implementation do, afaik.
using a lot of RAM that is unneeded but loading glyphs fast
You're not suppose to load fonts into memory to begin with. There are fonts that take hundreds of MB.
It would be enough to allow passing Read + Seek in addition to (or instead of) &[u8].
TrueType cannot be parsed that way. It's an offset based format. Meaning the parser constantly jumps all over the file.
Also, glyphs are not the only thing that is stored in TrueType fonts. Often not even a half of the file size. The other half is layout information.
So yeah, memory mapping is the only way.