Questions on CFF Table INDEX and DICT Implementation

[ln-north]

I've taken a look at the implementation of the CFF table in read-fonts an #520.
It appears that the CFF implementation in read-fonts is less advanced compared to glyf.
In #520, implementations such as Top DICT, FD Select seem to be incorporated as part of the Scaler in skrifa. It seems to me that some of those implementations could be defined in read-fonts/tables/cff or resources/codegen_inputs. Is my understanding correct?
Moreover, if this is the case, is there a future plan to migrate the INDEX and DICT implementation in the Scaler to the CFF?

[ln-north]

Having looked at the CFF table of fonttools and cffLib, the implementation seemed similar, which has resolved my question.

[rsheeter]

For context we anticipate most users engaged in typesetting will use skrifa. I'm curious, do you anticipate index and dict in their current location would cause problems?

[ln-north]

Thanks for comment.

I am using fontation for creating the read-fonts font-(editing | building) application. Therefore, I am paying more attention to read-fonts than skrifa. I think it would be more convenient if cff.top_dicts, like CffHeader, had a TopDict struct that could be accessed directly to each value. (Wouldn't this mean that Scaler doesn't have to interpose intermediate structures like ScalerTopDICT?)
Also, there is a postscript scaler that seems to be skrifa's code on the read-fonts side, which confuses me a bit. I feel that it would be more organized if the decoding of TopDict, FDSelect, and FDArray is completed on the cff side of read-fonts, and this can be used in skrifa's scaler.
However, I have not considered the complexity of the CFF table, performance, considerations with write-fonts, etc., so I cannot judge whether these are correct.

[dfrg]

The cff module in read-fonts could certainly expose more but I chose not to increase the scope of the API until we had actual use cases to inform design. Seems like we might have one now :)

I’d definitely be interested in more detail about your project if you’re willing/able to share. Are you just looking for deeper introspection for the cff table or is the intent to modify it?

[ln-north]

The overview of my project is as follows:

• UFO <=> CID-keyed Font Editor
• CID-keyed Font Inspector

Required specifications:

• Access to and editing of various information in Top DICT
• Acquisition and editing of CIDs (Access to Charsets)
• Configuration of FDArray / FDSelect
• Compilation and decompilation of Charstrings

To achieve these, I forked, and extending fontations. I was unsure whether to grow these APIs on skrifa or read-fonts when accessing CFF information (especially Top DICT).
I asked this question because I thought if these were clear, I might be able to contribute as a reference implementation for fontations.
I think it might be better to implement the TopDict structure in read-fonts. It's ok to try this first in a fork, as I am the one who needs it.

[dfrg]

Thanks for the additional context.

Since we’re talking about a mutable model of the table, the best place to put it would be in write-fonts. Capturing the structure should be fairly simple based on the primitives that already exist in read-fonts. For charstrings, decompiling can be done with some minor work but compilation is a different story. We intend to support it eventually but that work is not currently scheduled.

[ln-north]

Thank you for sharing directions and schedule.

For now, I implemented TopDict and Charsets in my fork as follows. It's good enough for my use, but there may still be things to consider for this repository.

main...ln-north:charsets

My question is resolved above, so I'll close it. thank you very much.