I have encountered problems sending email to users of GMail, to
users of Google email services using domain names different from
gmail.com, and to Google employees using their corporate email
account.
Google is the only email provider that does not accept my emails,
as far as I know.
This adds an option to enable white spece detection, and two
further options to control the operation of white space detection.
White space detection (--print-spaces) is intended for use cases
where digit (resp. character) grouping is important for correct
interpretation. One use case is the recognition of superimposed
dates in photographic images.
This commit also increases the version number to 2.21.0 and tweaks
some debug output.
C compilers are getting more aggressive with warnings and are producing
more false positives. While I intend to keep ssocr compiling without
warnings (as in the last 15 years), I do not use the newest C compilers,
but rather the GCC version included in a stable GNU/Linux distribution,
it may take some time for me to encounter those problems myself, and thus
it may take some time for me to work around them.
A user reported a compilation failure due to new warnings in GCC 10.1.
Since I currently use GCC 7.5.0 from Ubuntu 18.04 LTS, I do not see
those warnings yet, and thus cannot test any workarounds yet.
A first investigation into the issue hints at a need to replace valid code
with code invalid for GCC's default C standard version (necessitating
the specification of a newer C standard in the CFLAGS) to work around
said problem. I have no idea if there are additional warnings with GCC
10.1 after working around that one. Since Google blocks my emails to
the reporting user, I cannot even communicate to find this out. Thus any
code changes will have to wait for either a GCC version with additional
warnings arriving in my GNU/Linux distribution, or establishment of a
different communication channel, e.g., a GitHub issue.
There have been issues with the basic security features a modern C
compiler should provide, hindering compilation of ssocr. One way to work
around those is to disable use of the broken features. Another way is
to use a quality C compiler, e.g., a stable GCC release.
Google is blocking my answer emails to @gmail.com addresses. So I
can only advise to use a real email provider, not Google. If one
cannot do that, or does not want to, one can open a GitHub issue
instead.
This adds information relevant to issue #9 to the README file.
Before, the information was added to the ssocr home page and
the GitHub issue tracker only.
This introduces a function to scan part of the image for foreground
pixels.
This scanline() function may be of use for distuingishing between
the digit '1' and the symbol ":".
It may also help in segment detection reliability if the "len" parameter
is used to skip scanning image areas between segment positions.
Before, there was a special case where a blank ' ' could be printed
if no segments were detected in a digit at all. But this would not
happen, since all digits contain at least one pixel which would result
in some set segments.
This commit is a preparatory step for refactoring segement detection
in a digit.
Many people, including packagers for GNU/Linux distributions, seem to
think that ssocr is a "GitHub project." It is not. It is older than
GitHub and may well exist longer that GitHub. It is older than git.
The official website contains documentation not found on GitHub. GitHub
is just use as a currently convenient way to have an external copy, a
backup, of the development repository. This does provide third parties
with access to the developent code and its history as an added benefit.
The "added value" of GitHub (issues, pull requests, ...) is meaningless
to me and may be abandoned anytime. The contents of the official website
will be preserved even if it needs to be moved. The development history
has already been preserved during the migration from subversion to git.
This is intended to interfere less (not at all?) with Debian
packaging efforts.
The Debian Upstream Guide says:
"Some projects include a rough /debian directory among source files
to ease bleeding-edge package compilation and installation on Debian
(and derived) systems. While this is a good effort, it is better to
leave it out of the final tarball as it can interfere with debian's
own packaging effort."
I have renamed the directory to "notdebian" to clearly show that this
is not official. Since the Debian packaging system needs the exact name
"debian" for this directory, "notdebian" does not interfere with this.
All "common" tools used to build ssocr have been part of GNU/Linux
distribtuions for decades. But since more people want to build ssocr
on non-GNU systems it might be helpful to hint at where to find the
common utility programs:
- some are used in a POSIX compatible way
- some are part of GNU
- then there are others
Erik Auerswald