a minus ('-') sign.
The patch fixes a comment typo as well.
After applying this patch, ssocr will crash if it finds a "digit" with
zero height. This will be fixed in the next commit.
"Thanks, I'm happy for you to add me (Russell Currie <rc454@cam.ac.uk>)."
Russel reported the floating point exception (division by zero) error
with zero width digits, and even provided patches fixing this.
Do not divide by digit width or height if it is zero, just skip this
digit during special case recognition of a "one" or a "decimal point".
Currently, the scan line detection will see the following if digit width
or height is zero:
_
|
|
This results in printing an underscore ('_') character for a not
recognized digit.
Bump version number to 2.14.1 for this bug fix.
Do not divide by digit width or height if it is zero, print "NaN" instead
of the ratio normally printed. This concerns debugging output only,
something equivalent is needed for the actual recognition algorithm
as well.
and bumped version number to 2.13.4.
As a result my regression tests using the _broken_ dynamic_threshold fail:
testing images in first2...FAILED
testing images in neu...FAILED
testing images in pics-2005-11-12...FAILED
testing images in schlechte_bilder...FAILED
testing images in new_token_2008-11-07...FAILED
testing images in calc_dyn_thresh...FAILED
But at least I do understand now why dynamic_threshold did not work as I had
expected...I just did not see the error until today.
- use optimization level -O3, which is supported by both gcc and clang
- removed a set of unnecessary parenthesis
- added info about 'brew' on Mac OS X to INSTALL file
bumped version number to 2.13.3
This relies on the definition of enum _imlib_load_error in Imlib2.h
and might break on different versions of Imlib2, but should be better
than the total lack of error reporting before.
Developed with Imlib2 version 1.4.5 from Debian/Sid:
$ dpkg -l libimlib2-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii libimlib2-dev 1.4.5-1 i386 Imlib2 development files
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 <abates@johncabot.edu>.
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
Erik Auerswald