Re: [sane-devel] perfection v10

[valerio]

hi Olaf,

Il 11/01/20 14:09, Olaf Meeuwissen ha scritto:

Hi Valerio, iscan-data maintainer(s),





Thanks for the files.  That policy.out file doesn't look like it should,
at all.  It's supposed to contain a pile of additional rules that look
like whatever the distribution's libsane package uses for USB devices.

It appears that the Debian package maintainer split off the USB devices
into a 20-sane.hwdb and only left the SCSI devices in 60-libsane.rules.
This was done to address Debian bug 869244 (see [1]).

   [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869244

Unfortunately, that seems to have broken the logic in make-policy-file.
That script has been working fine for more than a decade on multiple
distributions but it looks like it needs some fixing up now.  The Debian
change will problably also affect *all* of Debian's downstreams :-/


thank you for your answer

last week i gave the scanner to a friend, who has the shop where i 
normally buy the hardware, to test in a microsoft pc, and look at the 
components.

the scanner works, but only for two minutes and about forty seconds...
i tested the machine, cut the power supply, after half an hour, 
connected again, it worked for the two minutes and so and then gave me 
error.


valerio

sorry for my defective english



Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
  Support Free Softwarehttps://my.fsf.org/donate
  Join the Free Software Foundation  https://my.fsf.org/join

Re: [sane-devel] Canon Canoscan LiDE 400 support in Slackware

[Rolf Bensch]

Hi,

The LiDE 400 is fully supported by the pixma backend (see:
http://www.sane-project.org/lists/sane-backends-cvs.html#S-PIXMA). You
need to install recent SANE version 1.0.28 from git snapshots
(http://www.sane-project.org/snapshots/).

Hope this helps.

Cheers,
Rolf

Am 11.01.20 um 15:20 schrieb Kelly Price:
> It worked around the problem on the 220.  The 400 may need some research.
>
>
> On Sat, Jan 11, 2020 at 9:00 AM Rich Shepard  wrote:
>> On Sat, 11 Jan 2020, Kelly Price wrote:
>>
>>> You fall into the same category I do with my LiDE 220. It somehow just
>>> doesn't like USB 3.x ports. I think we were working on the issue still.
>>> Olaf can remind me (as it's early and coffee is just being had here).
>> Kelly,
>>
>> I recall reading somewhere that the LiDE 400 required USB 3.x ports. And,
>> when connected to a 3.0 port I could press the 'PDF' button on the front
>> edge of the scanner, which brought up a simple GUI interface, and was able
>> to scan a page. So it must accept the USB 3.0 ports when used by itself but
>> even after adding it to /etc/scan.c/genesis.conf it's not found by
>> 'scanimage -L'.
>>
>>> As a work-around, I ended up putting this in my PC:
>>> https://smile.amazon.com/gp/product/B002RL8V7E/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8=1
>> Did it solve the problem?
>>
>> I don't know about other Canon scanners but the LiDE 400 has no power
>> switch. It turns on when the USB cable is inserted.
>>
>> Regards,
>>
>> Rich
>>
>
> --
> Kelly "STrRedWolf" Price
> http://redwolf.ws
>
>

[sane-devel] Line wrapping in po/*.po files (was Re: [janitorial] Feature freeze for 1.0.29 and call for translation updates)

[Olaf Meeuwissen]

Hi list,

Yuri Chornoivan writes:

> понеділок, 13 січня 2020 р. 21:53:43 EET Ulf Zibis написано:
>> Hi,
>>
>> Am 13.01.20 um 20:26 schrieb Ralph Little:
>> > On Mon, Jan 13, 2020, 11:17 Ulf Zibis, > >
>> > > wrote:
>> > Am 13.01.20 um 19:58 schrieb Ralph Little:
>> >> On Mon, Jan 13, 2020 at 9:58 AM Ulf Zibis > >>
>> >> > wrote:
>> >> Here came some surprise. With diff, I could see, that many lines 
>> >> were
>> >> changed, even there was no semantic change. This was caused by 
>> >> poedit
>> >> from automatic line break. It breaks lines after 83 chars, 
>> >> regardless if
>> >> I e.g. set it to 70 (with "keep format of existing files"), the 
>> >> default
>> >> was 79.
>> >> So I like to suggest, to first "reformat" the de.po file for a 
>> >> stable
>> >> format, make a merge request and after do the semantic changes, so
>> >> reviewers would have less work.
>> >>
>> >> I tend to agree!
>> >> I prefer to formatting changes separated from functional updates.

Agreed on separating file formatting changes from the translation
updates.  But please read on.

>> > Great!
>> > I personally would prefer NO line breaks, as comparing the diffs after
>> > would be much easier (otherwise a little change at the beginning of a
>> > long text changes all line breaks for several following lines, which
>> > makes it error-prone to observe changes at the end of the long text)
>> >
>> > If you disagree and want automatic line breaks, which width do you
>> > want?
>> >
>> > -Ulf
>> >
>> > I personally don't have a view.
>> > However I see that the default setting in poedit is 79 and that seems
>> > reasonable to me.  In the version I have has a setting of "Preserve
>> > formatting of existing files" so I don't know why it would be making
>> > other changes. :(

If your tool has such an option, please use it.  If not, check if it has
a word-wrap setting and set it to 75 for the sane-backends.

>> Maybe this setting scans for the longest line in the input file an takes
>> its width instead the determined 79.
>>
>> Is there any opposition from someone against disabling the automatic
>> line break, as today's screens are huge and modern edit and visual diff
>> tools are anyway capable to visually wrap lines according the window
>> width. This would dramatically serve visual diff tools to highlight tiny
>> differences in long logical strings.

Many visual diff tools are also capable of highlighting differences
within the lines that changed.  I find that a whole lot more useful
and convenient for finding tiny differences, even in short strings.

# As for huge screens, I can fit about 260 9pt characters on a single
# screen line before it wraps on one of my machines.  And, no, I don't
# find that convenient.  I prefer to have three <80 char text panes open
# next to each other.  On my laptop it's only two such panes but still
# beats overly long lines hands down.

> Hi,
>
> Olaf proposed to use 75 chars.

Small correction.  I didn't propose.  It's what our build machinery
uses, see po/Makevars[1].  Whenever the po/*.po files are sync'd with
the source files (listed in po/POTFILES.in), it applies this width of 75
characters to the files that are generated.

 [1]: https://gitlab.com/sane-project/backends/blob/master/po/Makevars#L32-45

> https://gitlab.com/sane-project/backends/merge_requests/305
>
> Personally, I have configured my Lokalize project to use this width.

The value of 75 itself dates back traces back to a commit made on
2007-12-08 (see d4a6f33c383c5368fb9102242fafe7ef4818e25d), adding
Esperanto translations.  Seeing where it came from, I guess it snuck in
unintentionally, but we've been using this for a looong time.

Whatever value we end up using (after 1.0.29!), we need to make sure all
the various gettext utilities use the *same* value.  If they don't do
so, our CI will fail (see 2ea6e8eaaa214da7a551070763ef8e4f370018db).

FWIW and not that I'm in favour of this, there is a `--no-wrap` option
that we can use instead of the `--width=75` option we use now.

Thanks!

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Re: [sane-devel] Converting Raw Image Data to PNG

[Olaf Meeuwissen]

Hi Daniel, Andy, list,

Sorry, am a bit pre-occupied and busy with the upcoming 1.0.29 release
:-)

Andy Bennett writes:

> Hi,
>
>> Thank you for your responses. I was able to get something! Almost there.
>>
>> I've attached an image of progress so far. By preapending the
>> "magic pnm code" to the top of the data file I was able to get
>> the raw scan data to display, but not properly. It seems to be
>> separating the images into three sections, seemingly RGB. The
>> sideways slant of the image is also a bit off as I couldn't
>> specify the width with a double.
>
> I think you have the dimensions slightly off, but the width (1296) seems
> correct.
> As you say, the image appears slanted and when I try to convert RGBTest.pnm
> to png I get the following:
>
> -
> $ pnmtopng RGBTest.pnm > RGBTest.png
> pnmtopng: EOF / read error reading a row of pixels
> -
>
> It looks like there's an extra 5 pixels every 15 lines or so, except for
> every 5 set of 15.
>
> 15 lines fit into 20KiB, but 16 do not. I'm not sure if that's relevant at
> all. Perhaps there's some extra framing, checksum or meta data coming in
> from somewhere?

I had a quick look at the image only but it appears to be image in a
format very similar to

  p

where every R, G and B, stands for a single pixel's RGB values.  You'll
have to rearrange those in your backend.  The p stands for padding bytes
and need to be skipped when preparing the image data that your backend
returns.

This kind of image data is(was?) pretty common and you should be able to
find usable code in several of the SANE Backends.  I know that the epson
(and epson2?) backend is able to handle such data.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Re: [sane-devel] [janitorial] Feature freeze for 1.0.29 and call for translation updates

[Olaf Meeuwissen]

Hi Rolf,

Rolf Bensch writes:

> Hi Olaf,
>
> What branch do we provide in git snapshots, master or release/1.0.29?

The website project's .gitlab-ci.yml[1] says "master".

 [1]: https://gitlab.com/sane-project/website/blob/master/.gitlab-ci.yml

> Hope this won't confuse too much.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join