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

Why did we depricate the load function? #675

Open
ILOVEPIE opened this issue Feb 11, 2024 · 5 comments
Open

Why did we depricate the load function? #675

ILOVEPIE opened this issue Feb 11, 2024 · 5 comments
Labels

Comments

@ILOVEPIE
Copy link
Contributor

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

@vinuel
Copy link

vinuel commented Feb 12, 2024

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

@Connum
Copy link
Contributor

Connum commented Feb 15, 2024

The README was updated to state that the method is deprecated with this commit: 88c89dc

The [deprecated] tag was added to the load() test cases in this commit: a9acb24
Maybe @yne can shed some light on it?

@yne
Copy link
Contributor

yne commented Feb 17, 2024

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

@Connum
Copy link
Contributor

Connum commented Feb 28, 2024

@ILOVEPIE any thoughts in @yne's response?

@axkibe
Copy link
Contributor

axkibe commented Feb 29, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants