Hello all, been using eggplant for over a year. We just recently got the new 11 version with the OCR. I am trying to have OCR read a specified search rectangle. Now it works fine for other applications I run it against. Except this one particular font it has issues with.
Here is the code:
logerror readtext(((101,731),(430,785)), contrast:on, contrastColor:black, validCharacters: “,.1234567890”, DPI: 96, IgnoreSpaces: ON)
and here is my screenshot…
the code works fine with other “art”, but for some reason this “art” font is not being recognized.
and yes I’ve tried “Trim:ON”, it doesn’t help, actually seems to make it worse.
Please help!
Thanks!
The trim setting isn’t going to help; it’s not applicable to OCR. You were on the right track with the DPI – increasing it dramatically seems to help. I was able to read “9760” with the following code:
put readtext ((271, 276, 514, 341), contrast:on, contrastColor:black, validCharacters:"0123456789", DPI:288)
I can’t guarantee that will work with every number that will be displayed, but it shows promise. Let us know whether that helps and if it’s only partially successful, send us some other screenshots and we’ll see if we can come up with some more reliable settings.
Not that I’m arguing with you, but the eggplant reference states that “trim” is a parameter of readtext(). In saying that how is “trim” not related to OCR? I see it work just fine when ran. I am only stating this as the feature may be needed/wanted in future projects with OCR.
BTW, that seems to work. I was using 96 as that’s the default on a Windows platform. So I assumed I had to match the DPI of the SUT. I will run this overnight and see what results this has.
I really appreciate the effort in helping with this issue and the effort in building such a great automation tool.
Thank you,
Well Matt, that seemed to work. Had it run over night against the application and it appears to of captured every value correctly. I appreciate the help!
Now back to the “trim” not being applicable to OCR.
Nevermind my comments about “trim” – I was mistaken. I’ve never used it with the OCR, only with TIG, and couldn’t initially see how it would even work with the OCR. But it is a supported parameter, so just ignore my ramblings on that front.
Glad that my other input was useful though.
Hey, I know this prolly warrants another thread, if it does I will move it. I saw in another thread related to OCR that you (think it was you) mentioned adding a blankspace into the “TextPlatforms.plist”. You also tell where to go on either a Mac or Windows machine. When we browse to these locations specified we do not see this file. I see you attached one though, if you don’t have that file do we just drop it in the folder? Cause all we see in the location specified are licence files.
OSX 10.6.8
Eggplant 11.22
Place specified in post.
~/Library/Eggplant
Screenshot of location on our Mac’s.
Not sure exactly what issue you’re referring to here, but the reason that you don’t see the file is that you’re looking in /Library/Eggplant, not in ~/Library/Eggplant. The ~ (tilde) means that the path starts in the user’s home directory, so it’s actually /Users//Library/Eggplant.
Doh… :oops:
Thanks!