On my current effort of getting rid of your libraries's forks on react-pdf (textkit, unicode-properties, pdfkit, fontkit and this lib), I think it would be beneficial for everybody to make this library a bit more browser friendly.
These are some of the issues I currently have with png.js:
Node version depends on fs, which is the one that pdfkit uses. So I cant use pdfkit without adding shims
Web version does not export the PNG object. Only adds it globally to window
Blocker for using directly pdfkit if your lib runs seamlessly on node and web
Changes proposal:
Write some tests to ensure everything works as before
Rewrite to ES6 (optional)
Make library browser friendly: ignoring fs on web build and (maybe) adding the XMLHttpRequest instead. Maybe adding the animation decoding also to this core (fcTL, fdAT sections)? There's no issues with zlib and Buffer since bundlers will shim them automatically (at least as far as I saw)
Keep /png.js with all the canvas manipulation for the people who is already using it
I already have a react-pdf fork with some of these points, and it's working great. These types of changes will make one day possible for me to rely directly on the main packages, and actively contribute to those. It's getting very complicated for me to do so when I have to also work on the forks
Hi @devongovett !
On my current effort of getting rid of your libraries's forks on react-pdf (textkit, unicode-properties, pdfkit, fontkit and this lib), I think it would be beneficial for everybody to make this library a bit more browser friendly.
These are some of the issues I currently have with png.js:
fs, which is the one that pdfkit uses. So I cant use pdfkit without adding shimswindowChanges proposal:
fson web build and (maybe) adding theXMLHttpRequestinstead. Maybe adding the animation decoding also to this core (fcTL, fdAT sections)? There's no issues withzlibandBuffersince bundlers will shim them automatically (at least as far as I saw)/png.jswith all the canvas manipulation for the people who is already using itI already have a react-pdf fork with some of these points, and it's working great. These types of changes will make one day possible for me to rely directly on the main packages, and actively contribute to those. It's getting very complicated for me to do so when I have to also work on the forks