Could SVG output be officially supported?

[joewestcott]

Currently I'm importing the DrawingSVG function from the example file (bwip-js/examples/drawing-svg.js), and passing it to bwipjs.render method, like so:

const svg = bwipjs.render(params, DrawingSVG(params, bwipjs.FontLib))

Is it possible to have SVG generation a 'first class' output method for this library? Perhaps something like bwipjs.toSVG(params) to match the toCanvas method. For the web, vector output with SVG seems like the best option for most use cases.

Finally, thank you very much for your work on bwip-JS, especially the drawing API making SVG output possible! 🎉

[joewestcott]

Hi @metafloor any chance you could give your opinion on this one? Thanks.

[metafloor]

Yes it is possible. I will roll it in when I have some time to work on this project.

[JoeABCDEF]

请问啥时候会出 svg生成的功能来

[willyou]

• 1 same here.

[metafloor]

Integrated SVG is on the development list, but highest priority is upgrading the cross-compiler to handle the most recent changes to BWIPP. Falling too far behind the main branch...

[terryburton]

@metafloor I've mentioned recently, but the current pace for introducing new paradigms into the PostScript code base is expected to slow down now, which should make targeting much simpler.

For the ctxdef stuff you could just create an idiom where the enclosed sections are executed as is, and not try to emulate the PostScript. Few people will enable this feature, and I don't propose to document how to use it at this point. The basic ideas is that initialisation can be kept close to the code rather than broken out into separate routines, so those sections are executed once, the result recorded in user-provided, opaque storage, and then restored on subsequent invocations. This helps in a minority of configurations in which the PostScript VM context is long lived with user inputs fed to it continually, e.g. Online Barcode Generator. (However many of the benefits are offset because the tokenisation cost is high in PostScript.)

I've just tightened up the options processing code so that users can no longer define arbitrary variables based on the options that they input. They can now only redefine default options already present in the current dictionary, and only with a value that is compatible with the existing type. This sanity check has introduced some interaction with the PostScript types system, but for the transpile it can likely all be faked and/or the processoptions routine replaced with a pure JS stub.

The only planned items that I have on the agenda are some options interaction cleanup and also to put more effort into catching error conditions via raiseerror, rather than letting the PS interpreter bomb out.

[metafloor]

Thanks @terryburton! I was trying to figure out the why of that context dict manipulation. But interestingly, just this last weekend, I had an aha moment and realized how it could be emulated in javascript using a prototype on the zero-level dictionary. That keeps much of the code generation unchanged and only the assignment of the encoders/renderers to the zero-level dict needs to be changed.

From a javascript perspective, that is a win both in terms of code simplicity and performance. Now I just need to find the time...

[willyou]

Although maybe this is not your purpose for this repo, but I want to express my appreciation. I'm using this repo a lot. I suggest you add donate or buy me a coffee button. Whether this feature is done or not, I'm willing to buy you a coffee. I couldn't find your email on your profile, so if it is not suitable to be here, please let me know, and I will remove it.

[metafloor]

I have put this on the 4.0 task list. To be released by end of year.

[metafloor]

It took a bit longer than expected, but bwip-js finally has built-in support for SVG. Available in version 4.0. See the project README and the announcement at https://github.com/metafloor/bwip-js/discussions/299.