Since the primary purpose of this system is to
provide a GUI Scripting system, the only fonts that must be
dealt with are those of the user interface, and these can be
specified.
If all you care about is the UI font, than it means you deal with
standard controls. Custom controls ar custom exactly because
they want to look different.
You cannot read a web page. You cannot read a PDF document.
You cannot read the UI of a Flex, or WPF application, or a
more fancy VB or .NET application, where the designer decided
to use other fonts.
You probably cannot read a window covered by another window
(because in most cases it is not drawn).
And if you can only read standard controls, with standard fonts,
then why not just call GetWindowText (or use WM_GETTEXT,
LB_GETTEXT, CB_GETLBTEXT)?
That way you get 100% accurate text, Unicode, not guessing,
not performance problems, not problems with RTL, context
shaping, ligatures, and the font does not matter.
"Screen OCR" is great if you can use it to access stuff
that is not possible to access otherwise.
And exactly that is the stuff you are cutting out.
At that point I don't see any benefit in the "screen OCR"
approach.
I think the target audience is QA. Since the devs can give them a list of
available) probably will make this not work, though. Also, I agree with you
that the usage scenarios are quite limited. Too bad, this would be really