Right now, remote paint is a non-mode. A piece of code that sits in front of RP proper, and controls other modes, providing a non-standard overlay mode. While this is certainly possible to re-implement in the new PaperJS branch, it requires some jiggery-pokery that I don't think we need, and is pretty well against any standards setup by other more "mode"ly things.

All the hard stuff that print mode used to do with some wacky wrappers and shared code with only manual mode, are now clean & open node APIs. We can re-implement all the functionality of auto-print mode, and most of what we needed from method-draw.

Really, this issue is a question: Method draw acted as dual purpose:

1. Make sure the SVG parsed correctly and was simplified enough to be printed
2. Resize the image to fit the canvas.

Without it, Paper.js has a built in "fit to area" functionality, and I think manages error callbacks for bad files, or at least does its best with what it's given. If we're OK with that simplification, then Remote Paint would become a full mode:

• Presenting the user with an empty canvas, and a disabled pause button, and likely the standard three buttons for calibration (unless I get to Add unified calibration wizard overlay #213). Also probably an API status area, showing how many items in the queue, waiting on user input, etc.
• It would instate its API only after being loaded as a mode. I'd suspect that we'd also remove the endpoint once the mode is closed. This doesn't quite match spec, but it's very close, as without the Remote print window open before, the API would just return "sorry, can't do that right now"
• Another button that might be nice is a "Ready for next job" state button, when clicked would let the API know that it's ready to process one queue item.
  • Once an item in the queue was done painting, the state of the button would reset, waiting for a user to put paper in and start again. Could even show on the canvas the image that's next.

Whatcha think @oskay ?