opentype.js icon indicating copy to clipboard operation
opentype.js copied to clipboard

Why did we depricate the load function?

Open ILOVEPIE opened this issue 1 year ago • 3 comments

It's a perfectly good function that's useful.

ILOVEPIE avatar Feb 11 '24 06:02 ILOVEPIE

Came across this too lately and was wondering if there is any explanation or documentation about it...

vinuel avatar Feb 12 '24 08:02 vinuel

The README was updated to state that the method is deprecated with this commit: https://github.com/opentypejs/opentype.js/commit/88c89dcdb2cc8952da9b270f39506afe2b715efa

The [deprecated] tag was added to the load() test cases in this commit: https://github.com/opentypejs/opentype.js/commit/a9acb24d90737c9432d77df38ede1c32e270c508 Maybe @yne can shed some light on it?

Connum avatar Feb 15 '24 11:02 Connum

Hi, the simple reason is that

  • loading from Buffer is platform agnostic
  • loading from path/URL makes us platform adherent (node/browser/...) and because of that, we shall offer (and document, and unit-tes) two API (sync/async) for loading a path/url while it wasn't even our job in the first place

Also, as demonstrated on the README, doing the path/fs to buffer only take 1 line anyway on the user-side (using require/import/fs/node:fs/fetch/XHR/net or whatever you need for your env/version/context)

the goal is to keep the lib out of those noises (look at the pain we have just to migrate to a module package.json)

I'd like to avoid that

yne avatar Feb 17 '24 17:02 yne

@ILOVEPIE any thoughts in @yne's response?

Connum avatar Feb 28 '24 09:02 Connum

in my opinion opentype should concentrate itself on bein a typing library and avoid when reasonable doing the fluff around it. doing the fetch() is an example of this, since this also inclused error handling, improving startup speeds by adding preloads to html header, caching etc. let the user of the library do it*. The same applies on the other side, canvas stroking and filling, there is an argument for opentype making the path in canvas, otherwise we'd redo the same thing over and over translating the opentype.js datastructure into pathing commands.. but the fill and stroke? Leave it to the user, then they can decide on colors, translations etc. without bloating the library.

  • If you want we could do "opentype-fluffy.js" or something as another module that does this fluffy things ontop, so people can decide they want to use that or the core only. For example since I'm rendering with opentype.js I have to do caching of the rasterized glyphs as well, which I also would avoid in opentype.js itself (it doesnt yet do it anyway).

TLDR: it was a good/useful function, but there is an argument to be made it isn't in the focus of the lib. It's certainly a one-liner to fetch it yourself (without considering preloading, then its 2 lines).

axkibe avatar Feb 29 '24 09:02 axkibe