Add Font and Glyph types from plumin.js

[louisremi]

Hello,

I'm working on plumin.js, a wrapper around the paper.js API that adds .otf export capabilities using opentype.js.

We'd like to generate fonts in real-time without locking the UI. We only need to render one or two glyphs in a canvas (a glyph is basically a Group of <10 Path or CompoundPath), but we want to generate fonts (consisting of dozens of glyphs) in real time, and that involves a lot of CPU intensive operations.

The best way to improve performances in our case is to do all the computation in a WebWorker, to at least avoid locking the UI, and maybe later parallelize the operations at the glyph level.

I'll start working on a canvas-less version of paper.js this week, but I wondered if you had advices on how to achieve that.

Best regards, Louis-Rémi

[lehni]

Wow, plumin.js looks amazing! Would you be interested in discussing joining forces? I meant to extend Paper.js with a Font and Glyph class forever, which should be able to read from SVG (and other formats), and used to render to the canvas, with the possibility to tweak the geometries. Being able to do that through a generated OTF would be impressive, especially for performance. And the aim is to make paper.js as useful for fonts as it is already for vectors. This will also require the building of a powerful layout engine for type...

[lehni]

As for how to achieve a canvas-less version, that should be fairly simple. It's almost entirely the drawing parts that actually use it (except for two dimension related helpers: View#getPixelSize(), View#getTextWidth()), most things should be drawing independent.

The View has two references two canvas related objects: _element (the canvas itself), and _context (the 2d context received from it). Most code just uses _context. Yould create a DummyContext class that doesn't perform anything and returns some meaningful values ideally, e.g. in View#getPixelSize(), View#getTextWidth(). Or you could just have branching in each place where _context is accessed, and have a fallback for when it's nulll. That's probably better, as there are not many places at all.

[louisremi]

Yes, we could merge pluminjs into paperjs if you think it makes sense. We don't need a text layout engine because we generate real fonts, so we use the browser engine. But opentypejs is fairly large dependency, so I'm not sure what should be merged exactly.

I hope to start working on a canvas-less branch tomorrow, thanks for the directions.

[lehni]

Looking through the code a bit, I am wondering about the necessity of the renaming of Segment -> Node and Contour -> Path. You could keep the names, and inject the required additional methods into Path.prototype. What's the reason for adding the different names? There are synergies to be enjoyed when things between two related libraries remain named the same way : )

[louisremi]

I originally looked at the RoboFab API, which is the API most serious type designers are familiar with. I tried to alias the names used in paperjs to something that looked more familiar to them. I had a problem with "Segment", because RoboFab uses that terminology to describe what paperjs calls a "Curve". So I chose a different name to remove that confusion.

But I'm not sure yet these aliases are a good idea. I could start by moving these aliases to a different file, and have the rest of the code base use only the paperjs API.

[lehni]

Hmm, I understand. Wasn't aware of that naming. Ours comes from Illustrator, and seemed to make sense to me. But of course both do : )

As for merging, here how I would approach it:

• opentype.js remains separate
• Paper.js receives a Font and Glyph class. Path is used for Contour (also: CompoundPath?), and Segment for Node.
• If opentype.js is present, the the plumin.js features become active.
• The same classes shall eventually be used / extended to load fonts from SVG, and to render to canvas without the browser engine (e.g. when on Node.js, or for advanced typography features that the Canvas cannot handle).

[lehni]

Also: Not having to regenerated the font on each change for a simple preview might be beneficial, e.g. when working on kerning / spacing, no?

[louisremi]

Alright, I'll also create a merge-plumin branch.

Having a text layout engine as an alternative would certainly be interesting. @davelab6 and the Metapolator team are working on an harfbuzz.js based engine I believe.

[davelab6]

I have talked about it but maybe but needed

[lehni]

@davelab6 looks like your message got lost in transmission

[davelab6]

I have talked about using github.com/prezi/harfbuzz-js but maybe it is not needed, with opentype.js meaning we can use the browser's shaping and text layout system

[lehni]

Let's discuss this further soon. Very absorbed at the moment but things clear up in about two weeks.

[louisremi]

I've renamed this bug and added a bug in plumin's tracker (see reference above). I'm not sure when we'll find the time to do that though, probably not before March.

[tdavis1198]

@louisremi any update on adding font and glyph types to paper.js?

[louisremi]

Hello @tdavis1198, Prototypo is in the process of moving away from Plumin.js. We're currently building a stateless / FP library to replace it. We don't have much time to dedicate to this issue.

[lehni]

@louisremi sad to hear that you're moving away from Plumin.js / Paper.js, but I guess your new structure makes more sense for your use case. I'd still be interested in adding this to Paper.js, probably as an optional module, once v1.0.0 is out. Let's leave the issue open.