Re: Apple II Reference Manual Addendum PDF now online

[pausch@saaf.se (Paul Schlyter)]

In article <Rc-dnV4HaNNOel3fRVn-vQ@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:
............. 
>> What about OCR'ing the text and keeping the graphic parts at 4 bits that
>> would reduce the size drasticly.
>
>The problem is that you can always tell when a manual has been
>OCR'ed--there is no such thing as perfect proofreading,

Yes you can indeed!  If you get the manual as graphics files (GIF,
JPG, whatever) you know it has NOT been OCR'ed....

>and computer manuals have lots of character strings that are not
>dictionary words.  It is _far_ from perfect.

Otoh OCR'ing is done at the character level, not the word level.
And if the OCR program is good, and encounters something it cannot
interprete, it will display a graphical representation of that character
and then ask you what ASCII character you should assign to it.
In that way, the OCR program will "learn" and become better and
better.

Of course there are printed characters that are absent from ASCII
(or ISO-Latin, or whatever character set you're using).  One way
to deal with that is to replace it with a several-character sequence.
E.g. the mathematical symbol for integration can be replaced by the
character sequence "Integral".

Unless you're programming in APL (nicknamed "APe Language"), exotic
characters shouldn't appear too often in computer manuals.
Programming languages are traditionally text oriented and try to
stay within the confines of ASCII  (although e.g. Java does allow
any "letter" to appear in identifiers you define yourself in your
program, including Cyrillic, Arabian, Chinese and Japanese letters...
...remember that Java uses Unicode internally, and the external
representation of a source file can be e.g. UTF-8).




-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/