Application Tool Kit

Background recognition

Currently using ATK for Android, but related to any other toolkits (iInk) except for cloud recognition.

Is there any SDK(?) which allows to make recognition on background, not forcing to use custom view objects? Im using kind of dumb workaround just to hide the view but still using it for recognition. The point is most stroke recognition apps demand their own view, not myscript's fixed view, and recognition on background, without any forced view changes. In case of cloud, it is super intuitive to send strokes and get the result, is there same library for any offline libraries or toolkits? All this real time dot-by-dot algorithms are messing whole concept of recognition, i have my strokes ready already, I just need to recognize them. No views or wasting resources are needed.

Thank you.

Dear Zharas,

You may switch to MyScript Interactive Ink SDK, that will let you send strokes and get results with no UI parts involved. MyScript iink SDK is available from MyScript Developer Portal. Just follow the Get Started instructions to retrieve the libs and example code for Android.

To implement a "no UI" workflow, here are the steps to follow:

  1. Create and configure an engine. The activation certificate can be the same than for ATK (provided that you keep the same bundle ID).
  2. Call `engine.createRenderer()` and pass it your own `IRenderTarget` implementation, which methods do nothing. This way, you will not need any rendering view.
  3. Create a package from the engine
  4. Create an editor and attach it a part of the type corresponding to what you want to recognize (ex: "Text"). Do not forget to call `editor.setViewSize()` and to attach a font metrics provider to the editor before setting the part. A one-class implementation of a font metrics provider is available from the UI Reference Implementation in the Android examples.
  5. Send all your strokes at once using `pointerEvents()`, setting the `processGesture` parameter to `false`.
  6. Call `editor.waitForIdle()` to wait for the recognition to complete.
  7. Export your result using `editor.export_()`.

All these steps can be achieved with limited modifications from the graphical "Get Started" example.

Best regards,


1 person likes this

One additional precision: if you are recognizing text, you should take care of disabling the guides to get a proper recognition, as without "seeing" anything your ink will likely no be written on them.

engine->getConfiguration()->setBoolean("text.guides.enable", false);

1 person likes this

Thank you for your detailed answer!

I had tried IInk earlier but its sample examples also were running with 'mandatory' editorView, which is initiated by calling  findViewByID()

How can I initiate that editorView without view itself?, because it is needed to get editor and other dependencies or is it fine to use just engine to initiate them myself. Also, structure of IInk structure was looking bit confusing due to editorView, engine, renderer, etc. in sample application creating themselves one inside another repeatedly without proper following Model-View-Controller approach. (creating renderer inside view and accessing via view)

As I understand, I can totally avoid editorView, but work only with editor and renderer objects, instantiated using engine only? 

You mentioned  editor.setViewSize(), what  should be input parameters . Is it related to max x/y coordinates I will use? (My strokes' coordinate system goes up to 65535, 65535). 

Thank you for answer again

I will change toolkit to IInk again (first attempt had some serious limitations what I already forgot =( and hope it will be fine) ~

Dear Zharas,

The example is meant as a help to let people easily start with a graphical interface. There is no problem in not using the EditorView and directly instantiating the different components by yourself in a non-graphical class following the sequence I provided to you.

The view size and the dpi information you provide (respectly to the renderer and to the editor) are needed for the recognizer to get a sense of "writing size" and thus better recognize the content (e.g. seen from very far, an "o" may seem like a "."). The view size is that of the area from which you retrieve your strokes. If you write full screen, it will for instance be the size of the screen in dots. It does not need to be exact, but to be consistent with the dpi information you provide.

If you find limitations that you think would prevent you from using iink SDK, please let us know, so that we can see if these are actual ones or if there are workarounds. Interactive Ink SDK should cover approximately everything ATK can do, but with a lot more flexibility.

Best regards,


1 person likes this


Can I ask purpose of having ContentPackage and ContentPart. Ive read the documentation but cannot get the meaning (except for storage), is this generally for keeping different Math formulas some predefined format? Whats its usage for text recognition? And is it mandatory to keep data in a file? 

And about ContentPart, what might be use cases for defining several content part? How many content parts is possible to create, when to switch between them? Why "Text Document" is needed while there are  "Text", "Math", "Drawing" can exist separately. 

And is MetaData for some identification/version comparison purpose only, and may be skipped? From the "Content types" article of documentation I get that Content Part is a central block unit, which is generated/edited during recognition and universally used later for different "output" purposes, and in my case rendering output and file output are unnecessary, so is it also possible to skip it? Oh, also, does ContentPart keep the stroke data as well along with recognition results? Basically for many elements I can see some usage, but cannot get why it is mandatory to have them.

Thank you very much and mt apologies for excessive amount of questions. I just want to understand the logic of the process ~

Dear Zharas,

Please keep in mind that MyScript iink SDK can do a lot more than just processing a batch of strokes and outputing a result. It is very flexible and adapts to many use cases, including interactive ink edition. Some aspects may not matter for a particular use case but will for others.

A content part can be seen as the "work memory" of Interactive Ink SDK. It is where it stores the data it works on, the recognition results it can manipulate, data it off-loads from RAM when there is a need to reduce memory usage, etc. It can be serialized so that you can store all this data and open it at a later point. This may be useful for note taking use cases, for instance. If the data you manipulate is "transient", you do not need to save the part and its parent package, but you must create them for the duration of the session so that iink SDK has a place to work.

Packages group parts together. If you develop a note taking application, each part can correspond to a different "page", while the package corresponds to the "document". It allows iink SDK not to load all pages into the memory at once.

The type of a content part defines the type of its root block. Identifying the type of a block is important, as different types of blocks are processed by different recognition services and technologies. Depending on the type of a block, you will also get different import/export possibilities.

A Text Document part is meant to organize different types of blocks in a vertical layout. It is useful if you want to provide an integrated way to interactively edit text, math and shape in a single page, and comes with matching export capabilities, such as a rich export to Word. If you just want to manipulate basic text, then a "Text" part is all you need.

Metadata allow you to attach custom data to a given content part. It is sometimes useful, like for the "calculator" example in the documentation where it is used to store the computation history. If you do no need metadata, you can safely ignore them.

Stroke data is stored in a part along with recognition results until you convert to typeset text. If you are in a transient mode and just care for the result, you can clear the part via `editor.clear()` once you are done and reuse it to process another input.

Best regards,


1 person likes this
Login or Signup to post a comment