paper.js

[gambhiro]

By all means I am coming late to the discussions (#119, byte-foundry/prototypo#115), but now, before @mattlag's big boolean target, is perhaps a good time bring it up.

When I noticed that I'd like to rotate a bowl for a serif o, I thought, hmm, let's add the feature and keep designing. But then, when I see that I'd have to implement the classic matrix classes and transforms, debug the whole mess I'd write, work out the API for it and so on, I feel very tired. I was interested in pretty typefaces and now I would have to code compsci to continue.

Do you not get this feeling?

I pick up the atmosphere that you think paper.js would be a good thing, but it would mean re-writing most of Glyphr Studio using the paper.js classes and API, and perhaps just thinking of that makes you feel tired.

Rewriting is not a bad thing! I want to help putting fire in that flame.

Sure, math is just math, UI is just gfx, and paper.js is not magic, but compsci is time consuming, and the paper.js folks have already had the headaches of growing and debugging a rich library of vector graphics features.

If all one needed was a rotation transform, then yes, the rest of a big lib is too much extra. But then you need booleans, intersections, some other feature, and so on, and adding UI for it is all about vector graphics animations (if not the bouncy-bouncy type), so paper.js would get well used.

It also lowers the bar and the effort needed to add new features. I mean, I'm not very experienced in JS, but if there is lib with docs, I can write a loop or two and keep going, like in #124. That vision is fun, in addition to actually drawing pretty letters! Even if it is the payoff of a major backtrack and rewrite.

What are your thoughts on this?

[mattlag]

Hi @gambhiro!

This is pretty cool. I have two quick comments - and then I may have time to dig deep into this later.

1. To answer your question about paper.js, i'm not inherently opposed to using it. Glyphr Studio may seem like a big, fancy program (maybe it is?) but it's secret is that it can be better categorized as a crazy spare time project I do for fun. Probably not too different than a lot of other projects out there. Taking this into consideration, I actually have a different set of goals than most projects, and speed of development isn't one of them! Additionally, digging into crazy maths and understanding random stuff is actually one of the benefits, in my opinion. For the Bezier add-point-to-path, I actually sat down and spent time learning about Bezier curves - it took a long time, but that's my idea of an intellectual diversion. So: Slow / Grueling / Boring / In-depth programming is something I like about this :-)
2. Getting help from outside people has also been a goal of mine, but the scope of your improvement is much larger than any collaboration that i've done before. Not a problem! Eventually i'd like to actually have native Glyphr Studio code that does all the mundane matrix compsci stuff, but i'm not opposed to using paper.js as a stopgap. I would recomend you dig a little deeper into how Components in Glyphr Studio work. Essentially they take a pointer to another Glyph, and keep track of the changes between that Root Component and a Component Instance. Any rotate / skew / whatever edit on a shape also has to be stored in Component Instances - so it can't just be a simple dump off to Paper.js and get new points back. This shouldn't be too hard to do, but it will be a blocker for shipping a feature like this. Because of the functionality of Components, most transform methods have to be implemented for Shapes, ComponentInstances, and Glyphs.

That's it - i'll look at your new stuff in more detail later. Thank you!

[gambhiro]

Thanks.

I should have mentioned that I didn't think that this is a serious approach either, copying objects to paper.js and back was just a quick hack to see that paper.js would fit the use case like a glove.

My motivation to code is usually very purpose driven. I appreciate the purity and elegance of compsci but I don't find a lot of energy to implement it for the sake of it, so kudos to you for that.

But I enjoy scripting useful pieces into existing frameworks, things that help getting something done better, or add some new bag of tricks.

When I saw for example Toche/BubbleKern for glyphsapp, or things you see in fontforge plugins and so on, I thought these would be cool to use in Glyphr.

So what this comes down to, and I suppose this is what I'd like to find out here, is if I could help to migrate / replace / rewrite the classes you have implemented in Glyphr, to the equivalent classes in paper.js.

Just to the point where paper.js is drawing on the canvas and one can deal with scripting things in terms of its classes, or extensions of them. For this I will have to study Glyphr deeper, and I will probably need advice.

Javascript allows such violence in it objects, I'm sure this can be organized in such a way that a neat compsci lib can grow in the app when you dig into the crazy math.

...to come close to the nighted and abysmal secrets of the infinite and the ultimate—surely such a thing was worth the risk of one’s life, soul, and sanity!

The Whisperer in Darkness, H.P. Lovecraft

Lovecraft is fun to quote :)

[mattlag]

+1 Lovecraft quote :-)

So i've thought about this a bit more. Taking rotation as a specific example, I think using paper.js (or really any other library) to quickly get functionality seems good up front. But if I think about it for a few more seconds, the amount of work to create a 'rotate' feature is a bit more involved - and most importantly, most of the work is not actually taken care of by the readily available paper.js function. Off the top of my head, these work items would have to be done as well:

• Create a rotate affordance, both on the canvas and in the attributes pane, that felt good / easy to use (relatively easy)
• Think about what would make sense for multi-selected shapes, or even multi-selected points (easy route is disable rotation in both these cases... but is that leaving important scenarios out?)
• Store rotation as a re-applyable action to Component Instances (depending on rotation features, this may range from difficult to impossible)

I'm thinking about those things, vs. re-writing the rotation math myself. And, actually, rotation math is quite easy!

Thanks, Wikipedia.

In general, I feel like paper.js provides a lot of generic functionality, so it seems cool. But actually any new feature in Glyphr Studio will need much more specific functionality, to a point where it significantly outweighs the generic functionality. I've been trying to get my feelings down into words as to why i'm sticking with not onboarding paper.js, and I think this is a pretty good description. When I start in on a new feature for Glyphr Studio, I actually don't spend that much time on the generic stuff.

I had another idea, though I am really appreciative of your offer for help, and I do want to enable some new scenarios for people. Do you think an "Export Glyph to Paper.js Format" would enable some new stuff? Or somehow create a side-by-side workspace where you could start working with a glyph using a paper.js backend? As you can probably tell :-) i'm not such a fan of the idea of replacing Glyphr Studio code, but there might be a way to add to it, or coincide with it. [edit: or maybe something like "apply paper.js function to the selected shape"? then internally we do a quick convert Glyphr Studio format to paper.js format, apply the function, and convert it back... almost exactly like what you did, except with a lightweight UI wrapper?]

Any ideas?

[mattlag]

Also! A big point for me here is to nail specific scenarios. Paper.js is a great generic vector editing platform, but glyph design is a very specialized subset of vector design. For rotation specifically, I could make the following statement: "The majority of rotating shapes in glyph design is between 0 and 15 degrees clockwise" - you may or may not agree with that, but the point is, a rotate feature in Glyphr Studio should be optimized very differently than a rotate feature in paper.js.

Again with the generic vs. specific feeling, most of our effort for Glyphr Studio should be making scenarios very specific.

[gambhiro]

Thanks for f40e2c456a!

i'm not such a fan of the idea of replacing Glyphr Studio code, but there might be a way to add to it, or coincide with it.

I understand. You wrote it and want it to live. I don't want to get in the way of that. I'm glad that this discussion is happening.

About the specific vs. generic solutions. First off I just want to say you have a lot more experience and do correct me if I make wrong observations.

A specific scenario benefits from a specific solution, probably will perform faster, and less likely to cause writing block to the person.

It just tends to develop idiosyncratic behaviour in the code and it gets harder and harder to see how wider aspects could connect.

Say, if the different editing operations all have a specific mechanism that performs them, then recording them for undo / redo has to keep track of the different ways to deal with them.

Are there editing operations that can't be expressed in matrix transforms? On specific path points or on the whole shape. Rotate, scale, shear, skew, translate, and stretch is maybe just a skew.

Storing these matrices in a sorted array could be stepped back and forth (undo and redo), and shared (or cloned) between Component Instances.

[gambhiro]

but glyph design is a very specialized subset of vector design.

So true. Once I started designing a font in Inkscape -- a lot of time and effort went not into design, but into keeping basic type features (stem width, x-height) consistent, because the editor has no knowledge about the relationships between the shapes, and it should have.

On the other hand, the way I had been imagining this, is that one would build that behaviour on top of a generic vector editing framework, so that say, you wouldn't implement getting intersections for every new editing feature.

That said, I'm also beginning to see how it is faster to implement those specific behaviours, and maybe it is just a waste of time thinking about universal frameworks.

It's a bit of a demoscene feeling -- get sharp on the basics and write code that works just now in just this case, and run the demo already. But it does mean starting with an empty sheet again and again, and even sceners start writing their demotool frameworks.

[mattlag]

So i'm a UX Designer in my real life. I have a big philosophical emphasis on understanding very specific scenarios, and nailing the details. With Glyphr Studio i'm actually doing things strangely - developing a tool so I can learn about how to use a tool, so it's a little circular, but I still lean away from big systems. Engineering: if you can't solve a problem, break it up into smaller problems, then address those. Hence my small-bites approach.

So, since we've been talking, I realized it would be more useful to do Rotation as opposed to Boolean Combines. So it has begun! Rotate support is almost done being added to various objects, and all the UI controls come next. Should be done sometime this week :-)

[davelab6]

@mattlag whats the current status of this? Seems related to #234

[mattlag]

@davelab6 I think this issue was one of the other big reasons I wanted to start a v2 - just to leverage everything Paper has to offer. So, I think for V1 this issue is essentially punted... Since we're basically doing a re-write for v2, it makes total sense to incorporate Paper from the very beginning.

Along with incorporating all of the other obvious stuff that isn't in v1 :-)

[davelab6]

@mattlag right on :) I suggest using the github issue tracker milestones feature to create a v1.07.0 milestone and then mark all open issues as part of that milestone except #234 which should be in a v2.0.0 milestone :)