[sane-devel] experimental/genesys backend status update

2005-03-14 Thread svo...@wanadoo.fr
Hello,

experimental genesys backend after checkin last updates is now close to
be finished for at least MD5345/MD6471 scanner:

- 50, 100, 150, 200, 300, 600 and 1200 dpi color and gray level
  8 bits scans are working reliably
- is already usable in xsane for varoius scans at various dpi

Current issues I am currently aware are:

1 - quality image issues:
- pictures are a little too red 
- seems gain should depend on exposure time
- picture are a little to dark 

2 - USB issues:
- there are bandwidth issues that lead to backtracking at high
  dpi scans
- usb read hangs sometimes when reading scan's data in 
  genesys_search_start_position() . It may be related to
  anything, and is quite mysterious.

Features that are can be added quite easily:
- lineart scanning
- 16 bits scanning
- scan resolution where motor dpi is not a round factor of CCD dpi
  such as 250, 350, 400, 450, ... genesys_shrunk_line is currently
  buggy.

I'm about to start code cleanup so that the backend can head to 
inclusion
in sane-backends. Which, I think shouldn't take a long time.

Regards,
Stef




[sane-devel] Genius ColorPage Vivid 3 - annoying issue

2005-03-14 Thread Joao Dias
Hi all,

I am posting to this list because of a minor problem with my scanner I would
like
somebody to help me with.

I have a Genius ColorPage Vivid III scanner.

Now that finally I got it working under linux (and out of the box with
Fedora Core 3)
it remains with an annoying problem for other users in my family (and that
makes
me feel guilty, cause I switched WindowsXP for Linux, and told them that all
would be
perfect ;).  

I am able to scan with very good quality, but sometimes the scan is
performed
a bit slower than usual and the result is a corrupted image either full off 
horizontal lines of several colors all mixed, or a kind of greenish +-1cm
height bar
at the top.

This happens randomly when scanning. Sometimes happens sometimes not.
It seems nearly alternating (nice/corrupted/nice/corrupted) but that is not
always true. Its very rare that I can scan twice with success, without
repeating
at least one time.

Is this a bug in the backend driver ?
I thought it could have something to do with warmup time and I managed
a bit with that and lamp on/off times but concluded nothing, or has nothing
to do with that.

I noticed too that xsane tells me I have an HR6 model but I actually 
have what claims to be ColorPage Vivid III in the scanner lid...
anyway I guess that's what lsusb says that matters...

Also if I open and quit xsane two or three times, it seems the usb subsytem 
uhci_hcd module gets corrupted in scanner communications and I have to
reload it.
(but that is not a problem because I always load xsane at session start to
get
the lamp off, and then let it stay there - and told others to do the same)

If more information is needed to help getting around the corruption issue, 
please explain me how to obtain it, also if there is
something I can do by myself while properly guided...

thanks for any help in advance,

Joao Dias


follows some info about my system:

#
lsusb output:
Bus 001 Device 002: ID 0458:2004 KYE Systems Corp. (Mouse Systems)

#
sane-find-scanner output:
found USB scanner (vendor=0x0458 [KYE Systems Corp.], product=0x2004
[ColorPage-Vivid 3150])at libusb:001:002

#
xsane info Colorpage HR6:002
Vendor: KYE/Genius
Model:  Colorpage HR6
Type:   USB flatbed scanner
Device: 002
Loaded backend: u12:libusb:001
Sane version:   1.0.14

##
my u12.conf file:
# U12-SANE Backend configuration file
#

# each device needs at least two lines:
# - [usb] vendor-ID and product-ID
# - device devicename
# i.e. for Plustek (0x07B3) U1212 (0x0001)
# [usb] 0x07B3 0x0001
# device /dev/usb/scanner0
# or
# device libusb:bbb:ddd
# where bbb is the busnumber and ddd the device number
# make sure that your user has access to /proc/bus/usb/bbb/ddd
#
# additionally you can specify some options
# warmup, lOffOnEnd, lampOff
#
# For autodetection use
# [usb]
# device /dev/usb/scanner0
#
# or simply
#[usb]
#
# or if you want a specific device but you have no idea about the
# device node or you use libusb, simply set vendor- and product-ID
#[usb] 0x0458 0x2004

# device auto
#
# NOTE: autodetection is safe, as it uses the info it got
#   from the USB subsystem. If you're not using the
#   autodetection, you MUST have attached that device
#   at your USB-port, that you have specified...
#

# auto deteccao
[usb]

#
# options for the previous USB entry
#
# switch lamp off after xxx secs, 0 disables the feature
option lampOff 30

# warmup period in seconds, 0 means no warmup
option warmup 15

# 0 means leave lamp-status untouched, not 0 means switch off
# on sane_close
option lOffOnEnd 0

#
# for adjusting the default gamma values
#
#option redGamma 1.5
#option greenGamma   1.5
#option blueGamma1.5
#option grayGamma1.5

#
# and of course the device-name
#
device auto

#
# to define a new device, start with a new section:
# [usb] 
#



my system (Fedora Core 3)
uname -a output:
Linux neptuno 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004 i686 i686 i386
GNU/Linux




[sane-devel] hp scanjet 3770

2005-03-14 Thread W. Goedel
I bought a hp scanjet 3770 revently. This scanner is correctly recognized b=
y=20
sane-find-scanner:

found USB scanner (vendor=3D0x03f0 [hewlett packard], product=3D0x2505 [hp=
=20
scanjet]) at libusb:004:005

But it=B4s not listed with scanimage -L.

Does someone allready have some experience with this type of scanner. Any=20
hints are appreciated.



[sane-devel] hp scanjet 3770

2005-03-14 Thread gerard klaver
On Mon, 2005-03-14 at 14:21 +0100, W. Goedel wrote:
 I bought a hp scanjet 3770 revently. This scanner is correctly recogniz=
ed by=20
 sane-find-scanner:
=20
 found USB scanner (vendor=3D0x03f0 [hewlett packard], product=3D0x2505 =
[hp=20
 scanjet]) at libusb:004:005
=20
 But it=B4s not listed with scanimage -L.
=20
 Does someone allready have some experience with this type of scanner. A=
ny=20
 hints are appreciated.


For status see this page:
http://www.sane-project.org/unsupported/hp-scanjet-3770.html

If you have more info on this scanner use the form to add information.
No backend exists and no one seems to be busy with it.

--=20

m.vr.gr.
Gerard Klaver




[sane-devel] UMAX Astra aborts in high resolution scans

2005-03-14 Thread Michael Stutz
Oliver Rauch oliver.ra...@rauch-domain.de wrote:

 May be your scsi controller or the driver of the scsi controller does
 not support scsi buffer sizes larger than 32768 bytes.
 
 I suggest to edit /usr/local/etc/sane.d/umax.conf (may be
 /etc/saned./umax.conf) and set the scsi buffer sizes to smaller than
 32768

Doesn't seem to do it. Adding option scsi-buffer-size-max 32767 to
/etc/sane.d/umax.conf gives the following result:

# scanimage -v -y 165 -x 120 --resolution 300  b 
scanimage: sane_start: Out of memory
scanimage: read 0 bytes in total

Without setting the buffer size, here is what I get:

# scanimage -v -y 165 -x 120 --resolution 300  b
scanimage: scanning image of size 1417x1948 pixels at 24 bits/pixel
scanimage: acquiring RGB frame
scanimage: min/max graylevel value = 255/0
scanimage: read 0 bytes in total
# ls -l b
-rw-r--r--1 root root   37 Mar 14 11:10 b
#

However, when the mode is specified as LineArt, it appears to work:

# scanimage -v -y 165 -x 120 --resolution 300 --mode LineArt  b
scanimage: scanning image of size 1416x1948 pixels at 1 bits/pixel
scanimage: acquiring gray frame
scanimage: read 344796 bytes in total
# ls -l b
-rw-r--r--1 root root   344829 Mar 14 11:17 b
#

When set to grayscale, it still bombs out but not as quickly as with a
color scan:

# scanimage -v -y 165 -x 120 --resolution 300 --mode Gray  c
scanimage: scanning image of size 1417x1948 pixels at 8 bits/pixel
scanimage: acquiring gray frame
scanimage: min/max graylevel value = 13/255
scanimage: read 56680 bytes in total
# ls -l c
-rw-r--r--1 root root56717 Mar 14 11:18 c
#

The SCSI controller is a BusLogic BT-958 that has worked in the past in
conjunction with this scanner. The only conceivable change is that SANE
was upgraded.


 Am Fre, 2005-03-11 um 17.32 schrieb Michael Stutz:
  I have a UMAX Astra 1220S scanner connected to a BusLogic SCSI card that
  I've used with SANE for years, but recently (possibly after a software
  upgrade) it has been giving me headache  trouble, and I have just about
  lost my wits.
  
  I am suddenly unable to scan images at higher resolutions. Without
  specifying the resolution, the scanner works flawlessly ... at the
  default of 100 dpi. But when the resolution is specified with
  --resolution just as I've always done it, and I give any value greater
  than about 150, the scanner will begin to scan (and produce output) but
  then exit almost immediately, and only a tiny portion of the specified
  area is actually scanned.
  
  Typescript follows ... assistance is greatly appreciated.
  
  
  Script started on Fri Mar 11 10:14:41 2005
  gatsby:/home/m#  export SANE_DEBUG_UMAX=12
  gatsby:/home/m# echo $SANE_DEBUG_UMAX
  12
  gatsby:/home/m# scanimage -d umax:/dev/sg1 -v -y 165 -x 120 --resolution 
  300  b
  [sanei_debug] Setting debug level of umax to 12.
  [umax] sane_init
  [umax] This is sane-umax version 1.0 build 32
  [umax] compiled with pipe for inter-process-data-transfer
  [umax] (C) 1997-2001 by Oliver Rauch
  [umax] EMAIL: oliver.ra...@rauch-domain.de
  [umax] reading configure file umax.conf
  [umax] attach_matching_devices(scsi UMAX * Scanner)
  [umax] attach_scanner: /dev/sg1
  [umax] attach_scanner: opening /dev/sg1
  [umax] attach_scanner: sanei_scsi_open_extended returned scsi buffer size = 
  16384
  [umax] attach_scanner: allocating SCSI buffer[0]
  [umax] init
  [umax] request_scsi_maxqueue= 2
  [umax] request_preview_lines= 10
  [umax] request_scan_lines   = 40
  [umax] handle_bad_sense_error   = 0
  [umax] execute_request_sense= 0
  [umax] scsi_buffer_size_min = 32768
  [umax] scsi_buffer_size_max = 131072
  [umax] force_preview_bit_rgb= 0
  [umax] slow = -1
  [umax] smear= -1
  [umax] calibration_area = -1
  [umax] calibration_width_offset = -9
  [umax] calibration_bytespp  = -1
  [umax] invert_shading_data  = -1
  [umax] lamp_control_available   = 0
  [umax] backend runs on little endian machine
  [umax] variable scsi buffer size (usage of sanei_scsi_open_extended)
  [umax] initialize_values
  [umax] identify_scanner
  [umax] do_inquiry
  [umax] Found UMAX  scanner Astra 1220S version V1.1 on device /dev/sg1
  [umax] umax_correct_inquiry(UMAX  Astra 1220S  V1.1)
  [umax] setting up special options for Astra 1220S 
  [umax]  - 16 bit gamma table is created lsb padded
  [umax] get_inquiry_values
  [umax] INQUIRY:
  [umax] 
  [umax] 
  [umax] vendor: 'UMAX'
  [umax] product...: 'Astra 1220S '
  [umax] version...: 'V1.1'
  [umax] peripheral qualifier..: 0
  [umax] peripheral device type: 6
  [umax] 
  [umax] CBHS value range..: 0-255
  [umax] scanmode..: flatbed (FB)
  [umax] inquiry block length..: 160 bytes
  [umax] 
  [umax] ISO  Version (reserved)...: 0
  [umax] 

[sane-devel] unpaper default parameter - empty output bug

2005-03-14 Thread Jens Gulden
Bertrik Sikken wrote:
  I put my patch in the place mentioned above, but I guess you
  probably already fixed most of the critical things.

Thanks for your help. In fact we did most of the things in parallel, but 
cross-validating our work this way can only increase quality... I also 
added the extra include-directive (stdlib), so I think the current 
version now fully includes all changes from your patch. In addition to 
that I made minor corrections to the documentation and fixed the 
variable 'half' uninitialized-bug (see below).

  The stack usage issue is not fixed and I am not sure if it is
  really too much or not (about half a megabyte I guess).

Wouldn't we get some error message in case of stack-overflows? I would 
expect some segmentation fault or other raised signal in that case. So I 
also haven't done anything about the stack yet.

  In warnings.txt is a warning about a variable 'half' that might
  not be initialized before use. I took a quick look at it and to
  me it appears the compiler is right to complain about it.

Yes! That was another potential bug, although it seems it was not the 
reason for breaking the optimized version (I didn't have that fix in the 
version I posted saturday, and still this one seemed to work.)
It should be fixed now.

  I haven't looked at the other possibly uninitialized variables.
These are ok, because their use is intentionally optional in the program 
flow.
I have also kept the yet useless parameter 'type' of getPixel() and 
setPixel() for possible future extensions (it should be optimized-away 
anyway - although I have made some bad experiences recently with my 
intuitive notion of what the optimizer does...:).

The remaining warnings with -pedantic and -Wall switched on are:

  [exec] unpaper.c:27: warning: string length `1303' is greater than the 
length `509' ISO C89 compilers are required to support
  [exec] unpaper.c:316: warning: string length `18802' is greater 
than the length `509' ISO C89 compilers are required to support
  [exec] unpaper.c:317:1: warning: C++ style comments are not 
allowed in ISO C90
  [exec] unpaper.c:317:1: warning: (this will be reported only once 
per input file)
  [exec] unpaper.c: In function `rotate':
  [exec] unpaper.c:1398: warning: implicit declaration of function 
`sincos'
  [exec] unpaper.c: In function `main':
  [exec] unpaper.c:2294: warning: `outputFilename' might be used 
uninitialized in this function
  [exec] unpaper.c:2300: warning: `qpixelBuffer' might be used 
uninitialized in this function
  [exec] unpaper.c:2302: warning: `inputTypeName' might be used 
uninitialized in this function
  [exec] unpaper.c:2315: warning: `startTime' might be used 
uninitialized in this function
  [exec] unpaper.c:2316: warning: `endTime' might be used 
uninitialized in this function
  [exec] unpaper.c: In function `setPixel':
  [exec] unpaper.c:634: warning: unused parameter `type'
  [exec] unpaper.c: In function `getPixel':
  [exec] unpaper.c:653: warning: unused parameter `type'

I will make an update version 1.0.1 out of the new code and will 
announce it to this list soon.

  Kind regards,
  Bertrik

Thanks and groetjes
Jens



Bertrik Sikken schrieb:
 Jens Gulden wrote:
 
 Bertrik Sikken wrote:

 I'm working on a patch and I'll post it when I'm done at:
 http://home.kabelfoon.nl/~bertrik/unpaper/



 I cleaned up the code at some places, so much less warnings remain 
 when compiling with -Wall -W -pedantic. (Thanks for the hints, 
 Bertrik, Monty, Frank.)

 And in fact the problems at least on the one machine I found have 
 disappeared, the -O3 optimized version runs there now.

 If, together with your patch, this turns out to be a more stable 
 version, I will put an updated version of distribution archive on the 
 project site and commit the changes in CVS.

 Jens
 
 
 I put my patch in the place mentioned above, but I guess you
 probably already fixed most of the critical things.
 
 Basically the patch does this:
 * replaced 'const' by '#define'
 * removed unused variables (this is not strictly necessary)
 * added missing return value
 * fixed some printfs
 * added an include file
 
 The stack usage issue is not fixed and I am not sure if it is
 really too much or not (about half a megabyte I guess).
 In warnings.txt is a warning about a variable 'half' that might
 not be initialized before use. I took a quick look at it and to
 me it appears the compiler is right to complain about it.
 I haven't looked at the other possibly uninitialized variables.
 
 Kind regards,
 Bertrik




[sane-devel] [ANN] Unpaper 1.0.1 update released

2005-03-14 Thread Jens Gulden
Hello,

an updated version of unpaper is available at:

http://download.berlios.de/unpaper/unpaper-1_0_1.tgz

This hopefully fixes problems that occurred on some platforms with 
optimized binary executables, and some other minor issues.

For a full overview on unpaper, see http://unpaper.berlios.de/.

Jens



[sane-devel] patched xcam.c and xcam.man in experimental/sane-frontends

2005-03-14 Thread gerard klaver
Hello, 
I have updated in experimental sane-frontends xcam.c and
xcam.man with:

-added TXT button for option text line adding to image
 with name, date and time info.
 font_6x11.h  file and add_text routine taken from the (GPLed)
 webcam.c file, part of xawtv, (c) 1998-2002 Gerd Knorr.
 add_text was modified for this program (xcam_add_text).
-font_6x11.h file added to src directory

-added RGB/BGR button option to switch the colors if needed.

-solved segment fault when no usb scanner/vidcam devices
 is attached to system ( bug report from Henning Meier-Geinitz)

-patch update for recording feature (SANE bugreport 300224)
 added SAVE Frame button, output filename box.
 With Save Frame button image can be saved as 
 .pnm .pgm .pbm or .ppm file

-added info row with x, y, image-size, fps count, fps, fps_ava

-added -V and -h option (version and help
-added option -B -buffersize so instead of default input buffer of
32*1024 a buffer of 1024*1024 can be chosen, so for vidcams for example
640x480, usb 2.0, 30fps less time is needed to fill input buffer.

Also some small updates to (for debug output):
xscanimage.c
preview.c
gtkglue.c

A example of the changed layout see:
http://gkall.hobby.nl/stv680-screenshot-text-25-65.jpg

A example of the added text line:
http://gkall.hobby.nl/sn9c10x-screenshot-text-0c45-6005.jpg

Before adding the patch to the sane-backends/frontends directory in cvs
i like to know if there are any comments about it.


-- 

m.vr.gr.
Gerard Klaver




[sane-devel] Help with USB scanner kernel config

2005-03-14 Thread thewade
Hello most generous OpenSource developers!

I am trying to get my old Acer Prisa USB scanner working with my
new AMD64 laptop running Fedora Core 2 and standard linux kernel
2.6.10-lsm. I had the scanner working on my old Pentium 3 laptop
running Fedora Core 1 and standard kernel 2.6.4 but I configured
that kernel so long ago I cannot remember what I did kernel
options I used to get the scanner working. My
/etc/sane.d/snapscan.conf is exactly the same and my u96v121.bin
is there too.
Does the u96v121.bin file need to be different for 64-bit?

Thanks for the help!
-thewade



[sane-devel] Help with USB scanner kernel config

2005-03-14 Thread thewade
Hello most generous OpenSource developers!

I am trying to get my old Acer Prisa USB scanner working with my
new AMD64 laptop running Fedora Core 2 and standard linux kernel
2.6.10-lsm. I had the scanner working on my old Pentium 3 laptop
running Fedora Core 1 and standard kernel 2.6.4 but I configured
that kernel so long ago I cannot remember what I did kernel
options I used to get the scanner working. My
/etc/sane.d/snapscan.conf is exactly the same and my u96v121.bin
is there too.
Does the u96v121.bin file need to be different for 64-bit?

Thanks for the help!
-thewade



[sane-devel] genesys and hp 2400

2005-03-14 Thread Florian Goth
--Boundary-00=_5tdNCJhQS5zYRSQ
Content-Type: text/plain;
  charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi!
I've downloaded the genesys cvs- Code from ca. 12:00 CET and a sane snapshot 
from last saturday. It compiled with some minor warnings. The scanner was 
detected. I set SANE_GENESYS_DEBUG=255 and tried to scan. The Log output of 
various combinations is attached. What I think is the showstopper: Somehow 
the scanhead doesn't move. It makes some clicking noises during scanning 
and somewhen scanimage aborts. If you want me to try something let me now.

Flo.

--Boundary-00=_5tdNCJhQS5zYRSQ
Content-Type: application/x-tbz;
  name=log.tar.bz
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=log.tar.bz

QlpoOTFBWSZTWSMzCXcBOF1/hOEUAIpi5//ybvfaqvAAAQAIYB+/eh8CQG2hRSQigqSokqew
DUA0AoKCgoUUUrRdtA4ANqgopSlKpJQhVKhUElJVUVUqkKOMmTQxGJowCMBMIAwE00aZGgGK/1VR
plH/6pSPSmkAGgOMmTQxGJowCMBMIAwE00aZGgGG1KTSMmTJgg02o2QAIyaZGjQYj00m
EBNVE0JogTIgTQZU80nqg00aMgaGQep6nqHpApSRBNJgmjTTQjRPSnkhphGg9EABoMT8b+L917b9
1zcZHx+Xx4iyNWnwyOC8LJq0BMTwnO1k3AcEvweJp1Eo9xwlEjYJ4agJeyNC5rZZatWLhbL/qNEn
O+l77Un3LxXajgtyOd0uFwt1uu5iGlilwJNrVlkna6GLGmNJJFZmZIYsswstLLdYtRq7bjdtu7GZ
xaHOyFUj8LsxlosT7273aV7K7qyrEzPafRtPymJ7zU95lX2zVK1MNTU9ptK+JibTCuWBhimX3MTv
MN27+9/gzMOZ2Yb+XWltw3nZifJ5MzzczM7Tzn6Z1PE4neeJ3nadTU1M0lzMU9aSw04niYmJ/hPa
bTebzAMMTFhcLe2tl2v7XidVFkYjCwsPCyNLFhYWVZZJliPK2vhYt7DLExMDDEwww/gy5cN52nzV
8x5yvYfOZYVuPSaYV7j5TdhXxK6bMU6ldnQ6GWG8rKumFYldMMDoYbNmzqV0rdhXUrpsxK6pwxOk
umzA6HTE5VmdTpu3ZnSuldTduyyrKuysssuldU6mzE6p1TppuyrqnSuWmXVOBp1TcZdPweLlV1QC
fQk+RzYcRGHUBpA7wIDnKNClOjNIAeLoMRlgWWLKUJXuX70fRLM7k//T+E/IanA4G1X73zfFXU/Y
+IdlxuyqXAeuy8rjfrWF+mMCTIPOwq0RfXfdGqxYj67VossrqssvO0k1ZFcRkn2WRLRklhmMWMWF
BKyF67vtL+mxdtiyyWtsvZhpiYYV7LLLDBb5ZliYmGBl6TUasjFl42R1/Pv+PdyuMZYWWSeV2aqy
8bQW9herFVasEmWAWWWSpiQ30tFl3rLS7l2LUYmzLdhl7WZlyqun6qfqmn5NoKmRsy1GWIyyrLF6
WmoysSmLJEMlTEc1lRqMLLkk3sVVd57zTynlf2t2rhebzfnPD6mJ05dmJy/Wlop4Yq/J2d3L1etW
n5vml5jquNyvUR7G6oJXrvOMjCT770stlXK7xcb7bLnYtDITViNMssLFIStLLGqbWIPNauix5W9l
lycb13g6LG12iCVzk4rkI9jgvF4cJVzO99F2nq2e/qxSFQzdhWKt0X9DU9FSpG83bu7L
wxMPSVWp7PN6Ow5bLLE8rqud3Xtuu6i6xZGRkZJliMsVYViYViaZn9s8Tu8Tp1P8k6nrKVPm
MzgYndX8m6RW1hi+Hm93NNK3SVMzNSvO7T9L/K+j2nu8PvdXeG6vnDaG9X2vdtFMK9mZ/RT7X4T0
bsvo/a/F+xzPunVKiHDp+U7TM6mqm6OSNh3xuvcsps3XzvslTVvfS99lhicTLM2bsNNpieJllw3b
TE3nK3jguK4XWt13LqXvvmjrjwZN2szMnksJArMRGZjJDCyxbXbf7Z7K+H1PycT3nrPaeU+JzPie
8+J2nU1NTFVKR5T0svOfDF/Sw2cv7n8XJTLa52LF+Zf0PRfRys6XstXG/mXC1ed8lwR+gYlYHL+T
8Hdh8p6n3YXF7P5uXu/6WXu5F5sLVhfFYsLEYvotltekfBcVskyxHiu5aSbRiOCxUmLS0WVb
LtRyu5GLjGXMuXDLsrfmfuahs6mbjDtOm7Ll3eKnEytT9jdiYGJpxVimJpu7TU2u7GaT9BHGwEbr
XZlddimtNddq4VYuJGhfSMqPuLZGFi4zF2W4stnpMdakvwfi7to/7X9feeTtvK8O7dtKsUsW1otL
VtaFssjtxG9vaDbI2bMtLErZ5NpsrZp57TTE00zKyyyrapszMNma4xNm0w/ixO08pqacGidzV6bu
d52MpJJOV10uI20j1yiexZAYrsRpDS0tC0stIwNLLSyTIxYsLFkYsMWRixYtWlqMLFkYWRiy
xGLFiyMsFlhYjFkrS0tVaWlpaWWlixYtLS0tLS0tLRaWlpaWlpak0WWhYsWLCxYkrBaFCVktJTLF
WWKWYFmUsBSVwcTE6V1MkzMP3zTqbO42bSsOXpJi5RlzLa35Ri3TEdFsuKwc6ipHo4V5UxO3G+z5
u0rs857sK3YVhiYdTw6abK1PfmdpW7sxK7MK4czZ2aaVxPozi/DTbFMMTqxMzDDtOzs02VqbO043
hpvOHDTVLTNOnnMytNTLhw0r5sPG7xibsJaczLlp33l828zTFTDiZcOG00rStMJZq2mWzTaaVqGG
VZaabNK1DDMy01NMs2zMy954mKmXu6VtMKxjGMOLZycXc5Nnfc3hplJOnTpp5KNuEu7EsYnM
2HErhW6tU8nd0NTZ2JmfKczCtpzO6XCvfzm0cvljYmLderOCZbzLZy2GlYm2laYnZgbu1xNnDhtN
6YmmGCZb7TZu3bTdWoZmGmm01TEw9m7OCcWplw4YbTdWJiaGJmZbNNpqmKpm1NMtNpqmKaaa
bTVMTaYmmWmGmXNMaamXieTL0mXGGzk0dGrZ2OjvJlJJOmnlQ4mzZmbz7GZtMTmcjiVqbK4p
+9s4mJ7zM6nqnx78anyZd204piGtNUxNNNPbcYeTicOHDimoammmnG47OnM5cuXA
3+ThXDhw4GlZbMTZvMOpzhjHbhs5OLdq2c3c7kyknTp008qRcKxN93dh+LftMTaV2ldl
ap5zsO/O5e04m03vFTkdTecvRhlob1FSM6aZcbjTTTYbNmzDyalZmmGmw2bNm0rs0005bjlu3btS
vjit27dvK2bNmGzNmYdp5TKWHBq0aOpls6nR0bpJJJl3d3d3d3EaYpiaVoalbzUyw3eHDTZu
xPScTZpi4lYtp2ZZY85qViktNmmpWs1K2ZmmWmpWpLE1NNNStps2ebSXpvN27LUrE2bN
ktps2mzE4ndzMO07q3auTm1bN27dJzZZSTLyhvvNxvK8StK1TydsSF6Daa2lYd3tYbTh
3nhw0l3YNTTTZthWaZmzLdtNmzzaa02bMzLLZvNTTTZtNmzMyy2YdTyejzmHU2bzlwbNGXU6
mW7sZTLLKSeUqz3cTTiZnZvPJhWG44S4V2p1t3ek8nm5d2WW07k2bOsMZZfR4eGm
nZll6Pps2YYnTC9Zw8Tw1PSZaaOpo0c2rZu6O1llJJMsssu7TUxO7l2fc7TE7DydSuZXSuKb
84b8PYZreetTwTzdPRll2ZZbssMTZhvOJ4neamHaZcmiatXN2t0kk5ssudu4
4m41N5XhLhW9PregzOzpuww9sssMNTLLXu2bO7Dqbzphph2MY68OLg4uxs1dHR0S
dOnTp08P6l9jGH7b/qwUzVh+T/PCqVfkt7717lR9y6o0je52wxB+qy5X4Wkt7TMN27La2Ze72fU+
b4nw+pl831PqdnZ2ezznvFMMq9qvS/0T5Pe4Zb2beJ7tO15Pk+T0er2e7p6zqKec5p+NMfHbpa17
6Spf32FLLKR+A9d6rxOuxl7rGiEiNKORHmhjp+Pl1DqIRkwySYqHiRH8Rxf2Lw/2P4tP/F/Uyrdh
XhifOfOUqYCi6oAQ8KvpfG+q+l/Vfpj7RfauS5Lmcz8Z+c/dO07zly5cuZ++dTLLu/N2nikv657T
0fnPWes3m88p2nrPWes9Z6vWd53es9JpmacO83eaXM3eN5qekzPE1manrPEzO804cZeU4npNPR2m
7lqam0ww8mR2HiYS9JiGZw2m03bTacTwrd2nlN1Zcur1es8qnk2a7TfDTDRyxhq3c27VzdrfDLdl
NEkkmySTVJJySSTrdbrSSSTZJJNmyScn