Representing variable-sized chunks

[liquid-metal]

Hi

I have a binary file with a constant header section, and a variable number of differently sized chunks after that. Specifically, I have a TTF file, with the following (relevant) structure:

# Offset Subtable (at the beginning of the file)
<number of tables>: xxx
[...]

# Table Directory, one entry per table
<tag>
<offset>
<length>
[...]

# one table after the other, each starting at offset from the table
# directory above. no more visible tags or separators down here.
# all tables have vastly differing structure and size
...

Coming up with a pattern for the Offset Subtable and a variably-sized array for the table directory went smoothly:

struct OffsetSubtable {
    ScalerType scalerType;
    u16 numTables;
    u16 searchRange;
    u16 entrySelector;
    u16 rangeShift;
};

struct TableDirectoryEntry {
    char tag[4];
    u32 checksum;
    u32 offset;
    u32 length;
};

struct ttf {
    OffsetSubtable offsetSubtable;
    TableDirectoryEntry tableDirectory[this.offsetSubtable.numTables];
};

Though here I start to struggle. I considered:

• looping on the tableDirectory array within the struct, but loops in structs are not supported
• throwing all table types into a union and have an array on that in ttf, but that will not work because tables are not equal in size
• looping through the tableDirectory array outside of the struct (global scope/other function) and mapping the correct table type at the correct offset. That works, but due to the Pattern view feature I am unable to define the output patterns in the function/loop. Further, even if that worked, they would be hierarchically next to ttf instead of below, which is suboptimal.

Is there a way to achieve what I want?

[paxcut]

check the ttf pattern in the library.

[paxcut]

The biggest problem with true type font format is all the scattered variables that are used everywhere but defined only in small places. I have my own implementation of ttf format which expands greatly from the one in the repository but is still wip and what i ended up doing is creating global hidden versions of the table entries that are used to access the values.

[liquid-metal]

Thank you for the library hint, definitely an interesting start
But from a first glance, that looks relatively non-intuitive. Do you think there is a missing language feature worth proposing that would make writing the pattern for TTF more convenient and expressive?

[paxcut]

there are lots parts missing to the current ttf format. For example, I have written code that parses and prints all the contour points and I am working on adding the ability to view and edit them in a gui. Being open source, pull requests for enhancements and additions are always welcome.

[liquid-metal]

Sorry for the question being a little unspecific - my thoughts actually went to that direction. Just if there would have been a non-specific idea for a language feature, that might have been worth investigating and starting a discussion about. I would never file a pull request for a new language feature without prior discussion
For the moment I will probably stick with the base in the library for TTF