Loading the font with @fontface?

[Aetherpoint]

Curious – is there anyway to access the font object with a CSS @fontface? Or would that require recompiling the font somehow?

[fpirsch]

TL;DR : No way
The font object is an in-memory javascript representation of the font. CSS @fontface loads files encoded in specific formats, preferably over the network.
This would require creating a ttfor woff file and using a special encoding to load it.
Note that for compatibility's sake @fontface usually requires more than 1 file format (usually 3 or 4), and that the data-uri encoding makes files 33% bigger...

[moyogo]

Actually, as I understand this is a goal of the project. The idea is to generate a font file, convert it to base64 and load it with CSS.

[Aetherpoint]

https://github.com/niklasvh/experiments.hertzen.com/tree/gh-pages/jsfont has fontface working in modern browsers with array buffers and blob URL's. Not sure how easy this would be to implement?

[fdb]

Yes indeed, the idea is to create WOFF files, encode them using a data: URL, and then load them back in. As soon as font writing works well, I'll implement the WOFF and data part.

Thanks @Aetherpoint for the reference – I didn't know about that one, might be interesting to look at.

[davelab6]

Why is woff needed?
On 20 Aug 2014 01:32, "Frederik De Bleser" notifications@github.com wrote:

Yes indeed, the idea is to create WOFF files, encode them using a data:
URL, and then load them back in. As soon as font writing works well, I'll
implement the WOFF and data part.

Thanks @Aetherpoint https://github.com/Aetherpoint for the reference –
I didn't know about that one, might be interesting to look at.

—
Reply to this email directly or view it on GitHub
#62 (comment).

[fdb]

Ah, I thought the WOFF was required, but it looks like browsers can just read OTF directly. Cool! I'll go try that.

[davelab6]

EOT is required for older versions of MSIE, and newer versions will render
OTF/TTFs as long as the fsType is 0. Anything that will render a WOFF will
render OTF/TTFs; its just a compression format.

[fdb]

Didn't know about that. Is that documented anywhere?

[Pomax]

not directly, but fsType determines the embedding policy and IE only lets you use fonts as webfonts if they have no embedding restrictions whatsoever. In order for a font to be used as webfont, that flag should be 0 already anyway because otherwise the browser downloading the font to cache counts as "installing" the font, violating the embedding policy =)

(as for WOFF as compression format, that's explained in the WOFF specs. Fun fact: WOFF can be used as a wrapper, but because the data must be compressible, has a few more restrictions on what the table layouts must be compared to regular opentype fonts. Not tables in tables or out-of-order tag directories, for instance)

[raphaelokon]

@fpirsch the 33% more additional base64 bytes should be mitigated by gzipping when you send the data ==> http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

[Pomax]

Note that if opentype.js is already running in-browser, then bear in mind that the data:uri will basically be immediately unpacked again in-memory, so you only save a bit of space in the data: string. The opentype.js font representation, and the font as loaded from data: source will both stay exactly the same sizes. For transmission, using gzipped tables inside the WOFF is a good idea. If it's all in the same client session, there's virtually no benefit.

[raphaelokon]

Ah yes, if it is all in the client that would make no sense.
I thought they want to persist it in a CSS/HTML and transfer the font embedded over network.

[cyberwombat]

Has any of this been implemented?

[fdb]

OpenType.js doesn't have this yet, but Plumin.js (which is built on top of OpenType.js) uses this technique.

This is through the CSS font loading API. Note that this currently only works in Chrome and Firefox.

• Example
• API Docs

[cyberwombat]

Thanks. I was able to use the toArrayBuffer() and convert to base64 and load it that way in my css.

[fdb]

Yeah, we should probably add that to OpenType.js directly....

[Pomax]

As a small aside, given that this issue is grounded in the past (filed august 2014), when the webfont landscape was very different: these days you do want just WOFF (possibly with WOFF2), as eot is obsolete (MS no longer supports any browser that needs the eot format), svg has been disavowed (most browsers that still had support for it in 2014 have since removed support again), and ttf/otf are full system fonts, subject to potentially stricter validation than "explicitly for web" fonts.

[Connum]

I agree there should be an easy integrated way to use the (possibly modified) fonts for text preview in browser context. Doesn't have to be in 2.0.0, but it shouldn't be too complicated to have this soon in 2.x.x at least.

[ILOVEPIE]

@Connum there's some problems with this, first off I don't think it should be the responsibility of our library to handle this, as it would introduce side effects. Secondly, this is already possible using Object URLs on the generated TTF or OTF files and embedding a new stylesheet that references the object URL. One thing we could do however is support outputting WOFF fonts, that could be useful.

[Pomax]

WOFF2 at least, then. WOFF was superceded quite a while ago =)

[ILOVEPIE]

@Pomax WOFF2 requires some fancy compression that is out of scope for this library, there are libraries that can be used with this one to read WOFF2 files.

[Connum]

Currently, we only have download() as a public method. If you want to only get a URL, you have to use all the more low-level methods yourself, building the DataView from the ArrayBuffer, the Blob from the DataView and finally the ObjectURL from the blob (or build a data: URL yourself by base64-encoding the data). I think it wouldn't hurt to expose a helper method (that we could then reuse in the download() method to download the file). After all, the download() method could be regarded as out-of-scope as well, as you could to that yourself from the underlying data.

As all modern browsers support TTF/OTF directly, I would also see this decoupled from WOFF writing support (which would nevertheless be nice to have), as it would be enough to simply preview the current state of the font object in an input/textarea/contenteditable element.

On a side node, we should probably call revokeObjectURL() in the download method to free up memory.

[Pomax]

@ILOVEPIE certainly (I wish JS had a Compression object, given that the browser already has in/deflate, gzip, and brotli built in), but if you're not going to support WOFF2, there's probably not a lot of benefit to supporting WOFF, as the older, superseded standard.

[ILOVEPIE]

Currently, we only have download() as a public method. If you want to only get a URL, you have to use all the more low-level methods yourself, building the DataView from the ArrayBuffer, the Blob from the DataView and finally the ObjectURL from the blob

iirc can't you just create a blob from an arraybuffer by passing it into the blob constructor?

[ILOVEPIE]

@Pomax here's how you can export/import WOFF2 from opentype.js:
#183 (comment)