I'm using iink 1.1 and I've run into a tiny problem on the Text Document view. I'd like to enter "..." with no letters. It seems next to impossible—the characters get interpreted as letters, symbols, anything but an ellipsis. I suspect this is due to there not being a limit on the text scale. The scale gets set as soon as I enter a character. Then, "..." get interpreted fine.
Is it possible to set a default scale based on line height and position (or manually) rather than have the scale be interpreted from characters based on where I start writing and how large I make my characters?
Besides "...", I've also run into trouble with commas if entered without any letters. They get rendered as slashes or quotes just as often. I believe this is related to scale as well.
Thanks, Andrey
Best Answer
O
Olivier @MyScript
said
over 6 years ago
Dear Rev,
this is currently a technology limitation. Indeed, it is very difficult for our technolgoy to recognize such things as dots or commas when written out of any context. Unfortunately, we do not have much alternatives to this.
Is it possible to get more information about your use-case? would you like to recognize only dots, commas by themselves, without any letter? In that case, you could create a subset knowldege resource that only includes dots and commas: https://developer-support.myscript.com/support/discussions/topics/16000020936
this is currently a technology limitation. Indeed, it is very difficult for our technolgoy to recognize such things as dots or commas when written out of any context. Unfortunately, we do not have much alternatives to this.
Is it possible to get more information about your use-case? would you like to recognize only dots, commas by themselves, without any letter? In that case, you could create a subset knowldege resource that only includes dots and commas: https://developer-support.myscript.com/support/discussions/topics/16000020936
Best regards,
Olivier
R
Rev Andrey
said
over 6 years ago
Hello Oliver,
In my case, I use iink "text document" window as an input field (much like MyScript Stylus Beta), to enter text into a (non-myscript) text document in my app. Sometimes I need to replace a comma or add an ellipsis while editing. The focus of my app is the use of handwriting for novel-length projects. So far I've been super impressed with the recognition. The only trouble I get is with letter "S" not getting capitalized at the beginning of a sentence (happens about 1/3 of the time—I have to make it really large for this to work consistently) and the occasional non-letter character input (ellipsis, comma, single quote). As far as that goes, periods work great.
Since the Text Document view has lines, would it be possible to set the initial scale to those lines rather than derive it from context? I think it would take care of a lot of these scale-related issues.
As far as my use-case, I'm trying to optimize this all for eInk—minimal refresh/movement and CPU usage. Once SDK 1.2 comes out where I can have control over gesture interpretation (on/off) when importing motion events en masse, I'm thinking of reading the relative space between words and feeding the motion events into the iink engine one word at a time to reduce re-interpreting mid-word.
Thanks, Andrey
O
Olivier @MyScript
said
over 6 years ago
Dear Andrey,
Currently, for the S issue, is it possible to have a screenshot of the ink when getting a lower case "s" while a upper is expected? Did you try using a text part rather than a Text Document? Maybe it will be better recognized.
Indeed, in the case of Text Document, as the guidelines are enabled by default, our technology takes these into account, but at the same time, we also use the context of the sentence such as other end of the word and whole sentence to determine if a letter is to be upper/lower case.
Regarding feeding the iink with one word at a time, there is a risk of a accuracy loss, so please keep this in mind. For this reason, we rather recommend providing all the motion events at once.
Best regards,
Olivier
R
Rev Andrey
said
over 6 years ago
Hello Olivier,
Here are a couple of pictures of the "S" issue. The first one shows three words as lowercase. The second picture shows the same session after I wrote the fourth word—the third word got converted to capital.
O
Olivier @MyScript
said
over 6 years ago
Dear Rev,
thank you for the image!
Such use-case is not specially related to the iink but to our "core" technology: Indeed, we are in the limitation of our technology, i.e. when the "ll" tend to be taller than the "S", the first S may be considered as lower.
What can be done is set the "export.jiix.text.words" configuration to true then export the result as JIIX and check the other candidates, that are likely to contain the expected one.
From a user experience point of view, a solution is to propose alternatives candidates to the user.
Best regards,
Olivier
R
Rev Andrey
said
over 6 years ago
I see. Thanks for explaining how it works. I don't understand the core of the technology enough to propose solutions, but since l's and t's are always taller than other characters, would it make sense to "read" half their length in all cases or simply ignore them in calculations? This seems like an issue that's likely to occur frequently—people's l's and t's are usually taller than the initial capital. I guess b, f, d, k and h are the other letters with the same issue. Perhaps basing the scale off the other letters?
Rev Andrey
I'm using iink 1.1 and I've run into a tiny problem on the Text Document view. I'd like to enter "..." with no letters. It seems next to impossible—the characters get interpreted as letters, symbols, anything but an ellipsis. I suspect this is due to there not being a limit on the text scale. The scale gets set as soon as I enter a character. Then, "..." get interpreted fine.
Is it possible to set a default scale based on line height and position (or manually) rather than have the scale be interpreted from characters based on where I start writing and how large I make my characters?
Besides "...", I've also run into trouble with commas if entered without any letters. They get rendered as slashes or quotes just as often. I believe this is related to scale as well.
Thanks,
Andrey
Dear Rev,
this is currently a technology limitation. Indeed, it is very difficult for our technolgoy to recognize such things as dots or commas when written out of any context. Unfortunately, we do not have much alternatives to this.
Is it possible to get more information about your use-case? would you like to recognize only dots, commas by themselves, without any letter? In that case, you could create a subset knowldege resource that only includes dots and commas: https://developer-support.myscript.com/support/discussions/topics/16000020936
Best regards,
Olivier
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstOlivier @MyScript
Dear Rev,
this is currently a technology limitation. Indeed, it is very difficult for our technolgoy to recognize such things as dots or commas when written out of any context. Unfortunately, we do not have much alternatives to this.
Is it possible to get more information about your use-case? would you like to recognize only dots, commas by themselves, without any letter? In that case, you could create a subset knowldege resource that only includes dots and commas: https://developer-support.myscript.com/support/discussions/topics/16000020936
Best regards,
Olivier
Rev Andrey
Hello Oliver,
In my case, I use iink "text document" window as an input field (much like MyScript Stylus Beta), to enter text into a (non-myscript) text document in my app. Sometimes I need to replace a comma or add an ellipsis while editing. The focus of my app is the use of handwriting for novel-length projects. So far I've been super impressed with the recognition. The only trouble I get is with letter "S" not getting capitalized at the beginning of a sentence (happens about 1/3 of the time—I have to make it really large for this to work consistently) and the occasional non-letter character input (ellipsis, comma, single quote). As far as that goes, periods work great.
Since the Text Document view has lines, would it be possible to set the initial scale to those lines rather than derive it from context? I think it would take care of a lot of these scale-related issues.
As far as my use-case, I'm trying to optimize this all for eInk—minimal refresh/movement and CPU usage. Once SDK 1.2 comes out where I can have control over gesture interpretation (on/off) when importing motion events en masse, I'm thinking of reading the relative space between words and feeding the motion events into the iink engine one word at a time to reduce re-interpreting mid-word.
Thanks,
Andrey
Olivier @MyScript
Dear Andrey,
Currently, for the S issue, is it possible to have a screenshot of the ink when getting a lower case "s" while a upper is expected? Did you try using a text part rather than a Text Document? Maybe it will be better recognized.
Indeed, in the case of Text Document, as the guidelines are enabled by default, our technology takes these into account, but at the same time, we also use the context of the sentence such as other end of the word and whole sentence to determine if a letter is to be upper/lower case.
Regarding feeding the iink with one word at a time, there is a risk of a accuracy loss, so please keep this in mind. For this reason, we rather recommend providing all the motion events at once.
Best regards,
Olivier
Rev Andrey
Hello Olivier,
Here are a couple of pictures of the "S" issue. The first one shows three words as lowercase. The second picture shows the same session after I wrote the fourth word—the third word got converted to capital.
Olivier @MyScript
Dear Rev,
thank you for the image!
Such use-case is not specially related to the iink but to our "core" technology: Indeed, we are in the limitation of our technology, i.e. when the "ll" tend to be taller than the "S", the first S may be considered as lower.
What can be done is set the "
export.jiix.text.words" configuration to true then export the result as JIIX and check the other candidates, that are likely to contain the expected one.From a user experience point of view, a solution is to propose alternatives candidates to the user.
Best regards,
Olivier
Rev Andrey
I see. Thanks for explaining how it works. I don't understand the core of the technology enough to propose solutions, but since l's and t's are always taller than other characters, would it make sense to "read" half their length in all cases or simply ignore them in calculations? This seems like an issue that's likely to occur frequently—people's l's and t's are usually taller than the initial capital. I guess b, f, d, k and h are the other letters with the same issue. Perhaps basing the scale off the other letters?