Need support for sanitized font stream

[raprasad3986]

Currently there is provision of making local font information available via font tables. In addition to this, it will be helpful if there is provision of making complete font stream available.

We already have an existing solution for the fonts available on web where we download the font and create a memory buffer out of the stream. Later, a module which is already in place takes care of processing the font information and rendering it.

With table based approach, there is an extra burden of assembling the tables and creating the font stream in the manner it is expected by the module above.

In order to get rid of this extra step, making this request for sanitized font stream.

I am not saying that the table based approach has any issue as such. Its about flexibility for handling different use cases. Later we may need the font table access as well if there is any difficulty from memory management perspective for large fonts.

[alshamma]

I will second that. Our codebase assumes that we have access to the entire font file. It is cumbersome to add a layer of logic to retrieve all of the tables and aggregate them into a single block of data.

[oyiptong]

Thanks for your comments, @raprasad3986.

Should the data returned by the font data object be streamable, would you still have a use for tables?

The Blob returned can be accessed as a ReadableStream. Alternatively, the Blob has a slice() method, which returns a new Blob with a subset of the data.

The following syntax is not final, but just to give an idea:

for await (const entry of navigator.fonts.query()) {
  let fontBytes = await entry.blob();

  // Process fontBytes in user script.
  // Here, we use opentype.js, which expects an ArrayBuffer.
  // Ideally, the user script should read the Blob as a stream.
  let buf = await fontBytes.arrayBuffer();
  let font = await opentype.parse(buf);
  ...
}

[inexorabletash]

And note that slice() doesn't require pulling anything into renderer memory. You can slice out an arbitrary range of bytes before reading it.

[raprasad3986]

@oyiptong @inexorabletash Thanks for the information.

Regarding your query, currently we don't have any use for tables and we are not sure if it will be required in the near future. But, given there is support for slicing the blob via an arbitrary range of bytes, I think if required, we can fetch the table data since we will have in hand the information of offsets and table sizes.

[inexorabletash]

The API shape has moved towards providing the full blob of a font file, rather than tables. So.. done!