Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading the font with @fontface? #62

Open
Aetherpoint opened this issue Aug 14, 2014 · 17 comments

Comments

@Aetherpoint
Copy link

commented Aug 14, 2014

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

@fpirsch

This comment has been minimized.

Copy link
Collaborator

commented Aug 14, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2014

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

This comment has been minimized.

Copy link
Author

commented Aug 20, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2014

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

This comment has been minimized.

Copy link

commented Aug 20, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2014

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

@davelab6

This comment has been minimized.

Copy link

commented Aug 20, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2014

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

@Pomax

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2014

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

This comment has been minimized.

Copy link

commented Mar 18, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2015

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

This comment has been minimized.

Copy link

commented Mar 18, 2015

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

This comment has been minimized.

Copy link

commented Nov 26, 2016

Has any of this been implemented?

@fdb

This comment has been minimized.

Copy link
Contributor

commented Nov 26, 2016

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.

@cyberwombat

This comment has been minimized.

Copy link

commented Nov 28, 2016

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

@fdb

This comment has been minimized.

Copy link
Contributor

commented Nov 28, 2016

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

@Pomax

This comment has been minimized.

Copy link
Contributor

commented Nov 28, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.