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.

Reply via email to