Do you accept feature requests? I have some requests that shouldn't be too difficult to implement.
Is there a reason that things like scratched strokes can't be pulled to the client-side? Seems to be pretty minimal processing and makes sense to do on individual strokes. Could also give some flexibility in new functionality.
I have a lot of questions about the JS API and web service APIs (eg: documentation doesn't make clear a lot of information about the stroke structure and the importance of some of the data and the class implementation)
Recommended serialization method, and the significance of certain data
Making it easier to process/store strokes selectively and extend things like the recognizer and renderer (esp. without tearing down all the MyScriptJS code).
Is there a reason you don't use require() or import?
Analyzer web demo was taken off the demo list recently, and it seems to be working a lot more poorly than before (text gets displaced far from its detection point and it is very, very slow).
Is there a way to hide my e-mail address? I'd rather not have my e-mail publicly available to spam bot spiders.
Yes we appreciate your feedback about our technology and MyScript JS API.
We would need more details to better understand your first point about scratched strokes. Do you face any issue?
Regarding the api, you can find many information in the api documentation: http://doc.myscript.com/MyScriptCloud/3.1.0/reference/index.html
Please let us know what is missing or not clear enough, so we can improve it with the next release.
Could you elaborate about recommended serialization method ? What do you expect exactly?
MyScript JS github project has been built to show an example of what can be done with our technology, we try to improve each release, so we appreciate your suggestions. As it is open source, you can clone it and use some parts only.
Regarding 'import', here is an example of integration that may interest you:
Unfortunately the Analyzer webdemo is not available anymore, so I guess you tried our Shape webdemo, that's the reason why you notice such difference.
As a reminder, you can create your own apikey on your CDK dashboard and use it your application.
Do you guys have plans to add some Analyzer-like features to the Math component? I need some basic decoration features (circling things). It would be helpful for me if it's easy for you guys to add.
Thanks for that react library; it is helpful. Seems like a bit of a workaround though. And, unfortunately, it isn't enough to support some needs and it looks like I will have to dig into InkPaper and InkGrabber, and probably a little bit of the renders/recognizers.
The stroke's t property is a timestamp, which I got from reading the code. Is this data important to your recognizer?
There is also the p, d and l properties, which I see are pressure and length calculations.
Right now, just taking the stroke components and direct stringify seems to work fine, and I'm wondering if this is the general recommended method for serializing/deserializing the strokes? I like the rendering, but is it all necessary? I'm guessing that just x,y,t are enough to derive the rest.
Also, the library doesn't give a simple way to expose the components or just an easy save/restore. Right now it requires grabbing private variables to implement.
Do you do any line data compression? Is it possible to do this for your stroke components?
Our cloud developer team is really happy to receive your feedback. They really hope to update MyScriptJS soon.
X,Y strokes coordinates are mandatory, t information are helpful to better display the result actually. You can do some testing, depending on the devices you target, to remove the decimal part of X,Y coordinates to reduce your cartridge consumption.
Hope it helps.
Cartridge usage was not the concern; it's just a drop in the bucket and development complexity/time is more important in this case.
The problem is that the recognition engine is too limiting and performance also suffers considerably for our use case.
If you could implement just recognition for scratch out and decorated objects recognition; that would work for me. And a server in Asia. Although: it would still be a performance issue.
So the t variable doesn't help server recognition and is only used for drawing strokes nicely?
Do you know if (poly)line compression algorithms like RDP affect recognition?
I wanted to be able to serialize and restore stroke data (a simple example being localStorage). I also need more control over stroke data than MyScriptJS currently provides (for complex apps that require special interaction) and to be able to do some simple manipulation.
I might just end up refactoring because of my own needs, but I think there is room for collaboration.
Is the websocket API designed only to process one drawing canvas at a time?
I need to be able to identify multiple drawings separately, preferably in parallel. Making many REST calls works, but I would prefer to be able to stream multiple requests (which would improve performance and allow batching calls, and enable a lot of different use cases).
The other workaround I see is to start new requests and reset many times, which creates a less than preferable synchronous bottleneck.