Code re-usability improvements

[ceztko]

Hello, I recently integrated some afdko tx fragments into PoDoFo PDF manipulation library to implement an on-demand Type1 to CFF conversion. While I was successful in the task, and I take the opportunity to thank Adobe engineers for this hidden gem, I struggled a bit integrating the code into an external user library, which understandably it may not be the first intended target for code inclusion. While working I collected some ideas that could improve the code re-usability, which I wanted to report here. I'm not asking to implement any of the following ideas, because some would clearly require huge code refactor which I can't expect you to prioritize on unless there are valid agreed reasons. Some are small enough that could be implemented right away, though. The list:

• The open callback could not be based on a global registry of file/stream identifiers. Instead it could be accept a tx abstract context that generically allows to create file/stream types, so that any shared module (eg. t1read, cffwrite...) can require a specific stream without supplying a name/identifier. This is maybe the most complex suggestion, I'm not expecting it will be ever implemented;
• The seek callback offset argument could be of size_t, as negative offsets are ignored anyway as shown in stm_seek. This change could be made right away, and in general it's good to drop usage of long type in portable code, as it's scaling 32-64 bit in non MSVC/non MinGW and non scaling in MSCV (which is a confusing behavior);
• The read callback could be changed to implement a more classical fread semantics, where the caller declares the amount of bytes to read: this would make easier/less confusing how re-implement the I/O abstraction. This change would require all afdko modules to explicitly declare their buffers for caching (but buffers creation/handling could be centralized in a tx abstract context), which is probably a big work but would generally improve quality/readability of the afdko code, IMO;
• I didn't need to re-implement xml_read, but I would rather not implement it at all, even if I needed to: there should be some facilities to read a regular stream as XML using the abstract read callback and afdko modules should use them.

In conclusion I am adding one more unsolicited recommendation: I noticed some repeating fragments of code which I'm sure you are well aware of. Of course they have micro differences/different error codes but factorizing them with some shared methods and/or macros would generally improve the code quality.

[ceztko]

I just wanted to add that I was able to perform subsetting of CFF based fonts, with glyph width rewriting. It's remarkable how many things AFDKO can be used for, and the more I use it the more I appreciate it!