On Fri, Feb 5, 2021 at 8:56 PM Sebastien Binet <s...@sbinet.org> wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, February 5th, 2021 at 2:10 AM, Nigel Tao <nigel...@golang.org> > wrote: > > Two []byte values aren't double the memory if the slices share the same > backing array. > > sure, I was thinking more of the memory taken up by the []byte and its > "equivalent" as a sfnt.Font. > Ah. A sfnt.Font isn't really an "equivalent". It's more like an in-memory cache or index of small but frequently-used parts of the underlying []byte (or io.ReaderAt), but it's not comprehensive. It doesn't have any in-memory representation of the not-frequently-used parts, including the actual glyph vectors. You could only marshal it to a complete TTF/OTF if you had the original bytes lying around too. But if you have that, you don't need to marshal anything. > What's your proposed API? > > package sfnt > > // Marshal returns the OTF encoding of f. > func Marshal(f Font) ([]byte, error) > func MarshalWriter(w io.Writer, f Font) error > I suppose we could rename "type source" to "type Source" and have: // Source returns the []byte or io.ReaderAt passed to Parse or ParseReaderAt. func (f *Font) Source() Source or maybe: // Source returns the []byte or io.ReaderAt passed to Parse or ParseReaderAt. // // fileLength is the largest file offset referred to by f's tables. An // io.ReaderAt doesn't necessarily know its own 'file length'. func (f *Font) Source() (s Source, fileLength int64) Tangentially, using a TTF/OTF font needs random access to the underlying data, unlike e.g. decoding a JPEG using a 'one and done' sequential read. Package sfnt was designed to work with either a []byte or an io.ReaderAt, but the code paths are more complicated for io.ReaderAt. I'm curious if anyone actually uses the io.ReaderAt support or whether, in hindsight, it was unnecessary complexity. For example, on many systems it's possible to mmap a file as a []byte, instead of going through an *os.File, but I don't have a good sense if "on many systems" is "on all systems (in practice)"... -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOeFMNVA9cXSDMkp6wLEyS9YPQi5HsLTmSZw_7shRVfo%2BOVuzA%40mail.gmail.com.