This probably requires more support for computing the minimum size of things.

When rewinding into a previous slide, figures should be in their final state, not their initial one.

Currently they only work on connectors.

That is, they should have the setCornerRadius method like rectangles do.

Currently, labels and other text-like things only allow text to be specified as a Unicode string. It should be possible to specify text in a more structured way (ala HTML!) rather than requiring things like subscripts to be manually positioned.

For smoother animations, tweening should be used between fully solved positions. Am thinking that all renders should be based on interpolation between two solved positions, since the time at which rendering begins will almost never be exactly on the time that was solved for. The fundamental issue that minimization takes more than 1/60 s can't be solved just by tweening, though -- the solver needs to run in parallel, stealing time to make progress on solutions, and a target time needs to be set so that it has a useful solution when it comes up with one.

One possible strategy is to keep estimating a next time point that will be useful, with a little overshoot for safety. Another idea is to start by computing the initial and final positions so that there is always an interpolation result, and then filling in the middle points adaptively.

There should be a renderer that generates PDF or PostScript so that Constrain can be used to generate figures for papers. PostScript would be easy, though these days people would then have to use some tool to convert to PDF.

Currently it is more painful to typeset math (or just bold/italics) than if typing TeX or Markdown. What's wanted is markdown functions that can translate strings into text objects with suitable formatting structure.

It's a little slow. Part of the reason seems to be my use of 'unshift' and 'slice'. Options for fixing are to reverse the order of the arrays being used so I can do 'push', or to switch to linked lists. Not clear that reversing the order solves the 'slice' part.

Geometric diagrams would be easier to construct if there were a constraint for point–line distance and/or perpendicularity

Currently constraints have to be installed explicitly via ensure. They don't know what figure they belong to or whether they are grouped or delayed. Alternatively they could install themselves like graphical objects do. Downside is that constraints can't be shared across figures. But this seems rare and also addressable via functional abstraction. This would also help with allowing after() to be used uniformly.

This seems to be computed incorrectly, although it does not seem to be breaking anything. Fixing it is tricky because it involves computing distances and gradients differently when the distance is close to zero.

Another possibility is to introduce an explicit CONG constraint as in Juno-2. Distance is a problematic operator because its gradient is discontinuous at zero, whereas a congruence constraint would not be.

On Safari some constraints are intermittently being solved some other way. Possibly DOMElementBox is not reliable.

aligning against them is not working correctly

Often we want to interpolate point positions rather than individual values. It's supposed to support that but something is going wrong.

Figure and TextContext both have style mechanisms. Perhaps they should be unified so styles can be passed more flexibly.

Double-clicking on the canvas causes the browser to start selecting nearby text, which is undesirable. All my efforts to cause double-click events to be absorbed and not propagate to nearby elements have failed. Sigh.

The problem is that MathJax generates SVG images, and although jsPDF does have some SVG support (via Canvg, apparently), it doesn't seem to be able to handle the images generated by MathJax.

Backpropagation seems to be running incorrectly or very slowly or both in the presence of some uses of Projection. This can be seen by the bad behavior of hint() when applied to a point value instead of a scalar.

rendering is kicked off when a document completes loading. However, figures may finish loading even after that via ajax calls. This creates a race.

The fundamental problem is that nothing says when a figure is done being constructed. This should be the role of Figure.start(), or perhaps it should be renamed to Figure.ready()

context.clip() should provide the necessary rendering support.

There will also need to be a notion of the size of the clipped margin.

So they can be aligned with the line/connector.

It would be helpful to be able to define code to run at the beginning or end of frames, e.g. to change the style of existing objects. Possibly as a higher level Event abstraction that handles undo/redo.

Differentiation is currently done by symbolic differentiation. That is, for each node in the AST, Constrain computes the gradient of that node with respect to all active variables. Since the AST is actually a DAG, it would probably be more efficient to compute the gradient using backpropagation, in which what is computed for each AST node is the differential of the final output cost with respect to that node's value. Backpropagation uses the chain rule, so every node needs to know not only what it depends on, but also what depends on it. This change would require some significant rearchitecting.

A cheap hack that will avoid much of the inefficiency of the current scheme is to introduce memoization nodes that simply remember the gradient they computed. For example, LayoutObjects could automatically memoize, and that would prevent the redundant computation incurred when interpolating between objects/points.

Maybe the gradient is being computed incorrectly — perhaps it's the tranpose?

Simple mistakes like passing the wrong kind of argument are going to give new users grief. Most user-facing methods should do run-time type checking of arguments. The run-time overhead would be paid at declaration time so should be insignificant.

It should be easy to specify multiple fonts ala CSS and have Constrain find the best one.

It would be handy to have conditional expressions, if e1 ≥ 0 then e2 else e3, and this would be easy to support.

Hints become important for complex diagrams with a lot of constraints in tension with each other. It's not clear that there is enough support for computing hints in a way that is responsive to the actual canvas size.

It would be nice to have interactive objects on the canvas that respond to double-click events. I killed double-click so comprehensively (#28) that that is not possible.

There should be a general (filled) polygon object.

Currently the PrintContext maps web fonts into PostScript fonts, but for inclusion in LaTeX documents, it would be nice to be able to match the fonts used there. More-powerful font support is needed to achieve this goal.

It might be easier to achieve this by implementing an explicit PDF rendering back end rather than generating PostScript and relying on conversion to PDF.

It would be useful to be able to compute the average of three or more things.

Things like graph support should be refactored into their own modules that users can choose to load, or not.

With the recent changes to the handling of fonts, text labels are no longer vertically centered, sigh.

It wouldn't be hard to add an "editing toolbox" widget that allows extending the figure with new objects and constraints, ala Juno-2, allowing figures to be created interactively.

The current hints are ad-hoc and spectral layout seems like it would give a good disentangled initial position for nodes.

Recomputing components discards the old inverse Hessians implicitly. This is fine for regular solving, but for animated solving it means the inverse Hessian is lost on every step.

It would be convenient if all graphical objects for which it makes sense allowed text to be formatted inside them. FormattedText just becomes text formatted inside an invisible rectangle in that case.

It should support clipping, scaling, and rotating the image and also probably add expressions for reading image attributes that can then be used to construct constraints.

This might be a little hard, but I was having a look at the postscript backend (which looks very nice and useful), and it made me think that I could get a lot out of having an SVG backend. The benefits are:

1. Vector drawing rather than pixel drawing: the user can zoom in
2. Accessibility features: in addition to zooming, we can attach data to assist screenreaders, etc.
3. The ability to embed MathML directly, rather than embedding 'screenshots' of math

E.g., taking the average of two points would be useful.

These would be B-splines, ideally. The Connector code shows how to do this.

The package puts too many things in the global namespace. This is convenient but it should be available in a more hygenic mode.

Not clear whether this is a problem with canvas placement or reading DOM client bounding boxes, or what.

Occasionally it explicably fails. This can be seen by viewing tests/text-format.html and dragging the diamond control back and forth. After a while you start seeing more failures. The time-dependent behavior suggests that something is degrading as the system runs, though I can't figure out what it could be, since the text formatter is coded in a more functional way than previously.