<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On Sunday 04 August 2013 01:02 PM, Stef
wrote:<br>
</div>
<blockquote cite="mid:51FE037D.7060300@free.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/08/2013 19:39, viresh wrote:<br>
</div>
<blockquote cite="mid:51FBEEDD.4000906@yahoo.co.uk" type="cite">On
Wednesday 17 July 2013 07:17 AM, m. allan noah wrote: <br>
<blockquote type="cite">I can confirm your findings- i think
this is a bug in sanei_constrain_value.c. <br>
<br>
allan <br>
<br>
On Tue, Jul 16, 2013 at 8:46 PM, Bureau <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:viresh_shirol@yahoo.co.uk"><viresh_shirol@yahoo.co.uk></a>
wrote: <br>
<blockquote type="cite">Hi all, <br>
<br>
During my backend testing efforts with tstbackend.c frontend
that is available in the distribution ,I observed an issue
in the sanei_constrain_value function. <br>
<br>
The details are as below. <br>
1)I believe the specifications for SANE_Range are simple
enough and there are no further rules on the values for
min,max and quant members. <br>
<br>
2)assuming #1 above is correct, my observation is that the
constrain_value function returns values that are greater
than the max specified for the range. <br>
<br>
3)I am assuming that #2 item is either unknown or known but
not fixed/valid scenario. <br>
<br>
<br>
4)the issue <br>
<br>
the issue happens for constraint type RANGE when following
condition is satisfied <br>
<br>
(max-min)%quant >=(quant/2) <br>
<br>
AND <br>
<br>
value to be set >=max <br>
<br>
<br>
Cause:Due to rounding done using quant/2 value,the final
value put in array[i] overshoots the max value by at the max
quant/2 units. <br>
<br>
<br>
5>Why this is an issue for me <br>
<br>
for few reasons <br>
a)I blindly believed the value returned by constrain_value
is actually constrained to the max. By this assumption,I did
not have to check the values everywhere for their
constraint-wise-correctness. <br>
<br>
b)the machine that I am writing the backend for seems to
take tl br values in mm and seems to do some kind of
validation using which it decides the actual scan size.So
offset of value/s for tl br options would lead to heavy
offsets when large resolution scan is done. <br>
<br>
c)the issue is very dominant,I believe,when the range type
is SANE_Fixed. Note that in this case the quant value is
sufficiently large leading to larger offsets. <br>
<br>
6)Solutions possible <br>
a)temporary fix can just check whether the adjusted value is
larger than Max for the range and set it to either max or
one quant level lesser. <br>
Also,I can temporarily fix it in a local function. <br>
b)not very sure but If the rounding via quant/2 is removed
we can safely say that the value is always safe. I think
it's a subjective item and can not discuss further but I
think flooring isn't that bad. <br>
<br>
<br>
<br>
7)My test values(sorry to put them at the end) <br>
max=SANE_FIX(431.8);//ledger width <br>
min=SANE_FIX(0.0); <br>
quant=SANE_FIX(0.01);//tried .1,1.0 too <br>
<br>
value to be set (actually the issue was found when testing
with tstbkend.c fronted) is 431.8. (or more ...as constrain
value reduces it to max in that case) <br>
<br>
<br>
Query:how do I proceed with this?My main question is "am I
doing something wrong??" <br>
<br>
8)Additional: <br>
this is my first post.I wanna thank you all and especially
the ones who have authored the tstbackend
frontend.Also,please note that I may ve wrong in using
fractional quant values etc but i think there was no
limitation w.r.t. in the spec. I apologize in advance if
anyone feels any sentence in this post seems to show
impoliteness in any way. ...I am newbie/noob u knw!!!! <br>
<br>
<br>
Thanks and regards, <br>
Viresh <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Sent from my iPhone <br>
-- <br>
sane-devel mailing list: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:sane-devel@lists.alioth.debian.org">sane-devel@lists.alioth.debian.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel</a>
<br>
Unsubscribe: Send mail with subject "unsubscribe
your_password" <br>
to <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:sane-devel-request@lists.alioth.debian.org">sane-devel-request@lists.alioth.debian.org</a>
<br>
</blockquote>
<br>
<br>
</blockquote>
Hi Allan, <br>
<br>
Thanks for the quick response that day. And I am sorry for the
late reply from my side. <br>
<br>
I am attaching the updated code based on the temporary solutions
that I had mentioned in my original mail. <br>
<br>
I am not sure if this is the correct procedure to send the
updated code but I am new to git as well. <br>
Also I believe newbies like me can not update the code tree
directly anyway. <br>
Could you please review and include the changes in the next
release? <br>
<br>
Please note that the changes in my backend code were external
to sanei_constrain_value.c. <br>
i.e. though the logic was same as the attached file, the patch
was external to constrain_value function. <br>
<br>
<br>
<br>
Apart from this, I would like to know if I could help the
efforts in any way. I dont have any hardware to test any
backends etc but I have some experience with opencv-v4l
configuration which I think can be helpful in improving the v4l
backend. (At least the man page says it is not so stable) <br>
Also as a plus point w.r.t scanners ,I have some 3+ years of
experience on multi functional peripherals controller
development(for one of the brands which do not have a sane
backend of their own yet) which included work on UI to
middleware. <br>
Let me know if I can be of any help in any way. <br>
<br>
Regards, <br>
Viresh M.Shirol <br>
P.S: rather large comment for 1 if block addition in the code
but I think it explains why the changes were done clearly. <br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
Hello,<br>
<br>
I have commit the fix in git tree. I have also added test
cases in sanei_constrain_test.c which detected the problem before
fix, and are now 'passing' with the fix.<br>
I don't think there is a better way to change this. Since sane
'fixed' values are float values multiplied by 65536, there will be
always rounding issues. For instance the SANE_Range you used
resolved to min=0, max=28298444 and quant=655, so min+k*quant will
always be different from max.<br>
<br>
Regards,<br>
Stef<br>
</blockquote>
Hi Stef,<br>
<br>
Thanks for the commit.<br>
<br>
A new issue report follows...<br>
<br>
While testing our backend code for Pardus Linux Turkish version, we
observed another issue.<br>
Though I would like to think that it is not a serious bug but the
efforts put in to pinpoint the issue root cause were sufficient
enough to mention it here for your opinions.<br>
<br>
The details of the issue are as below.<br>
Problem statement: Debug logs were not output even though the
SANE_DEBUG_XXX env variable was set to non-zero value.<br>
<br>
Analysis details:<br>
1>XSane front end supports internationalization via ,probably,
setlocale() call. (i think it's bindtotextdomain() or something but
I am not sure of the actual func. call)<br>
<br>
2>When setlocale (most likely LC_ALL category) is done by xsane ,
the case conversion is affected.<br>
<br>
3>When sane_init_debug() call is made by the backend the flow is
as below,<br>
a> set buf="SANE_DEBUG_"<br>
b> get the backend name <br>
c>convert the backend name to all UPPER CASE using toupper()
call.<br>
d>append the converted backend name to buf<br>
d>get the user set env variable value using getenv(buf)<br>
e>if the env is set and valid convert it to int and set
DEBUG_LEVEL. else return.<br>
<br>
4>THE ISSUE point<br>
toupper() call usage is probably not good. When character 'i'
(HEX 49) is passed to toupper() after xsane has set the LC_CTYPE is
changed to turkish ,its upper case character is still "i".<br>
i.e. uppercase('i') ='i' ----i.e. not 'I'<br>
<br>
(btw, i had no clue such things existed....a learning point you
know..at least dint expect it for ASCII chars)<br>
<br>
now if my backend name is xixi then the uppercase counterpart
would be "XiXi" ,for turkish locale ,which is completely different
from the expected XIXI value.<br>
<br>
<br>
5>As the sanei_init_debug() was searching for SANE_DEBUG_XiXi
,the export SANE_DEBUG_XIXI=100 done by us was never recognized.
And thus no logs output by the backend.<br>
<br>
<br>
<br>
<br>
Implications:<br>
1>The debug log issue applies to all the backends which have
character 'i' in their name.<br>
-->The issue specific to character 'i' is only for Turkish.<br>
However the manpage for toupper clearly mentions that for some
scripts there are no uppercase counterparts for some letters. (for
ex. the sharp s in german)<br>
<br>
2>The toupper logic seems to be present in libsane-dll.so too as
we could see SANE_**_CONFig_PATH too being queried incorrectly due
to which the default path /usr/local/lib/ was being searched for the
so files.<br>
-->As I am not sure about where all and how all the toupper()
call is made, I think we need to check this part to avoid
unnecessary debugging. <br>
For ex. Even thouhgh the configure path was /usr/lib ,due to
incorrect env variable name creation the dll.so would try to search
for the installed drivers in /usr/local/* which it won't find.<br>
<br>
<br>
<br>
Possible solutions:<br>
We are not sure about where all the changes may be required but I
think the following might work.<br>
In sanei_init_debug()<br>
before toupper() call, set the local to en_US.en_US and after
toupper call restore the original locale.<br>
<br>
But will this transient change have any side effect on the frontend
(especially the graphical frot end such as xsane) any effect on its
text conversions is not clear.<br>
<br>
Note: I am not sure if backend names have any
limitations/specifications ,w.r.t characters that they can have ,in
the standard1.0.<br>
<br>
<br>
<br>
Though it's not a major item as far as debug log output is concerned
,but I think if there are any other such instances in the source
files which I am not aware of yet, they could lead to few other
problems too probably relatively major ones when we target
different langauges.<br>
<br>
<br>
Backends which would not output debug logs in Turkish OS would be as
below,<br>
(reference:supported backends page
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://www.sane-project.org/sane-backends.html">http://www.sane-project.org/sane-backends.html</a>)<br>
<br>
epijitsu,fujitsu,ibm,kodakaio,magicolor,matsushita,microtek,microtek2,niash,pie,pixma,ricoh
etc. which all have character 'i' in their name.<br>
<br>
NOTE: This is only regarding Turkish OS and I am not aware of other
languages where toupper() would return the same char for alpha
chars. Not aware means not knowledgeable enough.<br>
<br>
<br>
Other details:<br>
Pardus Linux Turkish 32bit OS<br>
XSane 0.998 package in the installed os<br>
probably 1.0.23(22?) sane backends package.<br>
<br>
<br>
Thanks and regards,<br>
Viresh M.Shirol<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>