This should improve compatibility for systems with Imlib2 installed
in non-standard places, e.g. Mac OS X.
On Debian GNU/Linux this results in some warnings when building a .deb:
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libdl.so.2 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libz.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libX11.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libfreetype.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/ssocr/usr/bin/ssocr was not linked against libXext.so.6 (it uses none of the library's symbols)
I'm ignoring this. Special local adaptations like this have no place in
a general build system. A dedicated Debian package might apply a local patch
to strip these dependencies. This could result in a non-working ssocr as
at least libdl is actually needed by Imlib2 to load images.
FreeBSD and Mac OS X don't know 'date -I', but do know 'date +%F' with
'%F' equivalent to '%Y-%m-%d'. POSIX knows neither '-I' nor '%F', but
just '%Y-%m-%d', so use the latter.
Problem reported by Alan Bates <[email protected]>.
Instead of specifying the excat number of digits in the display, use
--digits -1 to have ssocr auto-detect the number of digits. When this
is used, ssocr cannot check if the correct number of digits has been
recognized.
Bumped version number to 2.13.0 to indicate a new feature.
A decimal point (or thousands separator) is recognized by its small size
relative to the digits of the display. It must be counted in the number
of digits to recognize despite being no real digit.
Bumped version number to 2.11.0 as this is a new feature.
All calls to this function have been replaced by calls to make_mono()
with the appropriate luminance type (minimum, red, green, or blue).
This way --foreground / --background work with the commands
{r,g,b,rgb}_threshold as expected.
Problem was "shear" setting background pixels using the specified
--background color, but rgb_threshold() always using the default colors
(foreground black, background white), ognoring the options.
Added a formerly failing test case to the regression tests:
Lauro-LEDs-digits-fore_back
Build on recent Ubuntu systems would fail, because the --as-needed linker
option (enabled by default on these systems) needs a special argument
order for ld to work correctly.
(see http://www.gentoo.org/proj/en/qa/asneeded.xml)
Use LDLIBS instead of LDFLAGS to list needed libraries. See GNU Make docs
and http://www.roland-illig.de/articles/article-1.html for rationale.
Bumped version number to 2.9.8, so I can tell the users having build
problems to upgrade to this version.
This fixes the following compilation error:
cc -Wall -W -Wextra -pedantic -Werror -pedantic-errors -O6 -c -o ssocr.o ssocr.c
ssocr.c: In function ‘main’:
ssocr.c:963:21: error: variable ‘d_width’ set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [ssocr.o] Error 1
The compiler is right, the value of d_width is never used, the variable is
not useful and can be removed.
My regression tests all pass. :-)
GCC on Ubuntu 11.04 64-bit produces the following error:
ssocr-2.9.5$ make
cc -Wall -W -Wextra -pedantic -Werror -pedantic-errors -O6 -c -o
ssocr.o ssocr.c
cc1: warnings being treated as errors
ssocr.c: In function ‘main’:
ssocr.c:57:11: error: ‘count’ may be used uninitialized in this function
make: *** [ssocr.o] Error 1
This was reported by Bruce Dudek <[email protected]>.
If no input could be read from STDIN a spuriour error message might have
been created by this error.
Bumped the version number to 2.9.6 to reflect the bugfix.
Waiting for Bruce to tell me if I may add his name and email address to the
released THANKS file (the checked in version does contain it both).
the third "third" too short.
This error was detected with a digit "four" of 15 pixels height with a three
pixels thick middle segment.
Since integers are used for computation this is still not very exact and may
still be off by one, at least in some corner cases.
The regression tests now contain the problematic image and pass completely.
below vertical segmentation.
Before this the recognition of a "one" used the image height instead of
the digit height. This kind of worked because for all practical purposes
the image was cropped to leave just the digits.
The debug output of digit coordinates was flawed the same way.
Since now the real height/width ratio is used to recognize a "one" the
empirically determined default value had to be adjusted as well. Using this
value my regression tests are all passed.
Erik Auerswald