Playing around with this and I'm finding that the table access stuff is a bit of a headache, and I have a few thoughts for discussion:

Tags

Having tag be a typealias for [u8; 4] works pretty well, but it has the one annoyance that tags can't be printed, because we can't impl Display for a typealias.

There is also the secondary issue that it is possible to construct tags that contain characters that are not permitted (outside the range 0x20-0x7E) but I don't think this is a serious concern in practice.

If we want Display/Debug (which would be nice, lots of things are going to want to print tags) then we'll need a newtype, like:

struct Tag([u8; 4]);

but then we have the annoyance that every use of a tag will need to involve constructing one of these, like:

let GSUB = font.get_table(Tag::new("GSUB").unwrap());

and that's also annoying.

One alternative would be to have a bunch of consts for common tags, like:

pub mod tags {
    pub mod tables {
        const hhea: Tag = Tag(b"hhea");
        const head: Tag = Tag(b"head");
        // etc
    }
    pub mod features {
        // etc
    }
}

And then you might do things like,

let GPOS = font.get_table(tags::tables::GPOS);

and that feels kind of okay, but ultimately I don't love any of this.

Tables

Table access is a bit annoying, because of the big Table enum. This has been worked around a bit by the table_unchecked! macro, but I wonder if we can make this a bit easier?

my thinking here would be to add a new Tables struct, and give it a bunch of convenience methods for the common tables, e.g:

struct Tables(BTreeMap<Tag, Table>);

impl Tables {
    pub fn gpos(&mut self) -> Result<Option<&GPOS>, DeserializationError> { };
   // ... etc
}

And then there could be a fallback method for getting an unknown table, that would just return bytes.

Doing this would also mean we wouldn't need to interact with raw tags as often.

There aren't a lot of great reasons to require nightly rust anymore, and it will be a major barrier to the adoption of this crate elsewhere in the ecosystem. Unless there's a really compelling reason to require nightly, I think it probably makes sense to try and move off of it sooner rather than later, as it will become harder the more nightly features end up being used.

Any thoughts on this? Last I checked nightly was only being used to improve diagnostics in some derive macros, and there are reasonable workarounds there. Are there any other major motivations?

It's worth keeping in mind that we can still conditionally use nightly features, enabling them only when we're on a nightly compiler.

The ported version of fontcrunch is much slower than the original, particularly in glyphs which go down this O(n^2) loop:

https://github.com/simoncozens/fonttools-rs/blob/0400715da315aa783c57070da2897760694b1fc3/crates/fonttools-cli/src/bin/fontcrunch.rs#L322-L332

I'm sure it's because of this clone:

https://github.com/simoncozens/fonttools-rs/blob/0400715da315aa783c57070da2897760694b1fc3/crates/fonttools-cli/src/bin/fontcrunch.rs#L366

The clone is only there because I can't work out the lifetimes required for storing Statelets as references within a Statelet and moving them around. If I put what I think are the right lifetimes on the State and Statelet types, I get a confusing error like so:

431 |     states: &mut Vec<State>,
    |             --------------- these two types are declared with different lifetimes...
...
454 |         states[this].sts.push(sl);
    |                               ^^ ...but data from `states` flows into `states` here

Okay so I ended up just going and doing this with a proc macro.

I was reluctant to go this route because generally adding a proc macro for something this minor is bad, because normally you don't already have proc macros, and so you're bringing in a bunch of new dependencies, and it can significantly impact compile time. Since we're already building otspec_macros, however, adding one more doesn't feel that bad.

So this adds a Tag type (struct Tag([u8; 4])) and a tag! macro, that takes a &str literal, and verifies at compile time that it is a valid tag.

• 1-4 characters long (we add padding spaces if it's shorter, so tag!("URD") == b"URD ".
• all bytes in the range 0x20..=0x7E

If either of those things is false, then code won't compile.

The main advantage to this approach is that you can print a tag and know it's valid utf-8, and that all tags are generated statically at compile time. (If you need to create one at runtime you can do Tag::from_raw("hi").unwrap()).

Overall I think this is... okay? it works, and is clear. I'm annoyed that it ended up being so much code, especially since I would like to make it much easier to grab commonly used tables, which would let me delete a lot of these changes.

One note: there's currently a weird thing where the macro is re-exported from otspec::types, which is itself reexported at fonttools root. This means that if you use fonttools::types::!("hi") it will be a compiler error if otspec is not in your Cargo.toml. I'm not sure what the best solution is for this (probably just only exporting the macro via fonttools?) but I'm going to leave it as-is for now, because I want to go for a walk before the sun goes down.

cheers!

serde is really good, and really helpful. It's got us very far very quickly. But it has some significant frustrations, most notably the fact that it's not designed for random access.

Currently any structure that involves offsets (and now we're coming into handling layout, there are lots of them) requires a nasty process of reading the offset data, reading the rest of the structure, calculating how many bytes we've consumed so far in the structure, reading the rest of the available data into a vec, making a new slice starting of the available data from (offset - where we are), and passing that new slice to a separate deserializer. Serializing structs with offsets is even harder, and involves pulling together (possibly nested) serializations and computing their length, etc. The worse thing is that this all has to be done by hand for each structure. If we had true random access, most of the manual ser/de implementations would go away.

Realistically, we don't need the structure/data format abstraction that serde provides, as we are hardly likely to be serializing fonts to JSON or whatever. (I've tried it, it doesn't work...) So perhaps a custom ser/de would even be simpler.

Would be interested to hear opinions on this, particularly from @cmyr @raphlinus.

Currently this crate adopts the general position of naming things based as closely as possible on the OpenType spec. This means, for example, having a fonttools::GPOS module, within which there is a GPOS struct.

Rust has fairly clear naming conventions; for instance Rust modules are expected to be lowercase, and Rust structs are expected to be CamelCase.

I understand the rationale for the current choice, but I'm finding it awkward. In particular it can be hard to distinguish a module from a struct.

My preference would be to follow Rust's naming conventions, and to use namespaces where necessary, at least for tables. We know what the common table types are, and afaik there are no places where case normalization would cause a conflict.

Suggestion:

• moveall table modules into a newtable` module, and give them lowercase names
• give all table structs names like Base, Gpos etc, and reexport them from tables
• prefer to use these items with a qualified name, like table::Gpos.

This matches fontmake and it's also recommended in the ms spec

When building a Unicode font for Windows, the platform ID should be 3 and the encoding ID should be 1, and the referenced string data must be encoded in UTF-16BE.

https://docs.microsoft.com/en-us/typography/opentype/spec/name#platform-specific-encoding-and-language-ids-windows-platform-platform-id-3

This includes the commit from #54; if we don't want that PR (or want some alternative form) I'll rework this accordingly.

This is the impl of a new API for accessing tables.

I haven't fixed the various other projects & crates yet, because I thought it might be helpful to open this for discussion while I plod through getting CI to pass.

Highlights

• there's a new TableSet type that coordinates storing and loading tables.
• tables are lazily loaded on first access, and we use interior mutability so that table getters don't require &mut self.
• all tables are stored behind shared pointers, so you never need to hold on to a borrow of the TableSet or Font.
• tables have transparent copy-on-write semantics: after a table has been retrieved from a font, the first time it is mutated we do a deep clone of the source table. (this is maybe a bit controversial, it's a pattern I haven't seen before and is a bit 'magical')
• this means that you cannot mutate a table "in place"; you need to retrieve it, modify it, and then insert it back into the font.
• access to known tables is provided via methods on TableSet, with the signature,

  fn GPOS(&self) -> Result<Option<CowPtr<GPOS>>, DeserializationError> { .. }
  

• for unknown tables there is still a get method

There are a few rough edges.

• It's annoying that we need to always return Result<Option<T>>. I've been daydreaming about having two forms of Font, one which has been preloaded and one which hasn't; methods on the former would be infallible, and maybe we could also do things like guarantee that all of the required tables are present? I don't want to worry about this too much right now, but wanted to at least mention it.

• I'm also not totally sure about the process of mutating tables and mutating fonts; I can imagine a different API where there Font is read-only, and if you want to mutate you have to use an explicit FontBuilder method, and then there would be a to_builder() method on Font for constructing that; you would then add or remove tables as desired before calling a build() method that would give you a new font. This would be slightly more cumbersome but would also be clearer with regards to the fact that if you get a table and then mutate it you need to put it back in the font for anything to change?

Anyway, overall I think this should be quite a bit easier to use.

Simon if you'd like to chat about this at some point let me know!

This started out with trying to fix a warning about an invalid macro attribute, and then in the process I ended up confused that we were using 'serde' as our macro attribute keyword.

• Add Font::load and Font::from_bytes methods
• Change Font::save to take a path instead of a handle

This is hopefully a simpler API, not requiring the user to mess around with files directly.

I'm not sure if there are uses for font::load that are not covered by the new methods, so I have left it in place but marked it as deprecated; if it should be removed I'm happy to make that change.

Super wip. My implementation is loosely based on https://github.com/fonttools/fonttools/blob/main/Lib/fontTools/ttLib/tables/O_S_2f_2.py. The fonttools version uses python's built in bisect module in order to achieve a good run time. I don't think Rust has this so I've opted roll my own custom binary search instead.

Note this is still super wip. Before I plumb it together, I'll ask for a review. It should be ready for a first look tomorrow.

I compared crunching ZenOldMincho-Regular.ttf using:

• pycrunch i.e. font-crunch from pip
• runcrunch i.e. fontcrunch from this repo

Results: ZenOldMincho-pycrunch-rucrunch.zip

pycrunch

Updated maxp (important, perhaps) and head (modified date and checksum) entries, correct appearance:

rucrunch

Only updated head checksum, but the result has buggy appearance

Is there an overarching idea, here? Noticing that for head the table itself is declared in otspec, but in hhea it's declared in fonttools. I'd like to rebase the vhea branch but not sure where it should go.

Okay while investigating #62 (which turned out not to be a bug, I was just holding it wrong) I ended up down this rabbit hole.

My intention was for this to be a simplification: whether or not this has been successful is left up to the reader.

for instance in hhea, the version (major: 1, minor: 1) serializes to 0x00010001 instead of 0x00011000.

I was working on a simple F2DOT14 type since it's used elsewhere and all the crates I've seen are pretty heavyweight, so I can do this at the same time? it seems like the rules are slightly different.

It looks like currently we skip any feature params. From a quick skim it looks like there's something funny going on and you maybe punted on it initially? Want to make sure I'm not missing anything.