scanimage kaputt? (openSUSE 15.3)
Hallo Zusammen! Rahmenbedingungen: openSUSE 15.3 Scanner ScanJet Pro 4500 fn1 sane-backend libsane-hpio aus dem openSUSE Repo scanimage aus dem openSUSE Repo skanlite aus dem openSUSE Repo Scannen über USB oder Netzewerk, macht keinen Unterschied. Scannen aus ADF mit --source Duplex Scannen mit skanlite funktioniert ohne Probleme. Insbesondere: alle Formate, die gescannten Bilder sind nicht korrupt (keine Fehlermeldungen beim Weiterverarbeiten oder prüfen mit z.B. tiffinfo -D, convert, ....) Scannen mit scanimage funktionert überhaupt nur mit tiff. Bei anderen Formaten bricht der Scanvorgang schon beim ersten Bild ab, das erste Bild wird unvollständig geladen. Beispiel: out001.jpeg.part Bei tiff sind die Bilder zu fast 100% zudem korrupt, mit den Fehlern TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and calculating from imagelength. TIFFFillStrip: Read error on strip 0; got 16665600 bytes, expected 16695360. convert meckert zwar, erlaubt aber noch eine Weiterverarbeitung. Damit scheint mit der Schluss, dass das Problem wirklich bei scanimage liegt, korrekt. Oder? Wie kann ich das Problem analysieren und weiter eingrenzen? Gibt es ein anderes Programm, welches das scannen von der Kommandozeile unterstützt, diese Fehler aber vielleicht nicht hat? Wichtig ist mir das scannen von der Kommandozeile, egal mit welchem Programm. Sollte nur funktionieren. Vielen Dank vorab! Viele Grüße Karl
Hallo Karl, es nützt dir zwar nichts aber unter Tumbleweed funktioniert es. scanimage --device=genesys -o Test.jpg Canon Lide 200 scanimage (sane-backends) 1.1.1; backend version 1.1.1 Lothar ursprüngliche Nachricht Von:Karl Weber <karl.weber99@gmail.com> An:users-de@lists.opensuse.org Datum:Mon, 30 Jan 2023 09:55:08 +0100 ----------------------------------------------------------------
Hallo Zusammen!
Rahmenbedingungen:
openSUSE 15.3 Scanner ScanJet Pro 4500 fn1 sane-backend libsane-hpio aus dem openSUSE Repo scanimage aus dem openSUSE Repo skanlite aus dem openSUSE Repo Scannen über USB oder Netzewerk, macht keinen Unterschied. Scannen aus ADF mit --source Duplex
Scannen mit skanlite funktioniert ohne Probleme. Insbesondere:alle Formate,
die gescannten Bilder sind nicht korrupt (keine Fehlermeldungen beim Weiterverarbeiten oder prüfen mit z.B. tiffinfo -D, convert, ....)
Scannen mit scanimage funktionert überhaupt nur mit tiff. Bei anderen Formaten bricht der Scanvorgang schon beim ersten Bild ab, das erste Bild wird unvollständig geladen. Beispiel:out001.jpeg.part
Bei tiff sind die Bilder zu fast 100% zudem korrupt, mit den Fehlern TIFFReadDirectory:Warning, Bogus "StripByteCounts" field, ignoring and calculating from imagelength. TIFFFillStrip:Read error on strip 0; got 16665600 bytes, expected 16695360.
convert meckert zwar, erlaubt aber noch eine Weiterverarbeitung.
Damit scheint mit der Schluss, dass das Problem wirklich bei scanimage liegt, korrekt. Oder?
Wie kann ich das Problem analysieren und weiter eingrenzen?
Gibt es ein anderes Programm, welches das scannen von der Kommandozeile unterstützt, diese Fehler aber vielleicht nicht hat? Wichtig ist mir das scannen von der Kommandozeile, egal mit welchem Programm. Sollte nur funktionieren.
Vielen Dank vorab!
Viele Grüße Karl
-- Mit freundlichen Grüßen Lothar
Am 30.01.23 12:06 schrieb Lothar Vorrath:
Hallo Karl, es nützt dir zwar nichts aber unter Tumbleweed funktioniert es. scanimage --device=genesys -o Test.jpg
Canon Lide 200
scanimage (sane-backends) 1.1.1; backend version 1.1.1
Lothar
ursprüngliche Nachricht Von:Karl Weber <karl.weber99@gmail.com> An:users-de@lists.opensuse.org Datum:Mon, 30 Jan 2023 09:55:08 +0100 ----------------------------------------------------------------
Hallo Zusammen!
Rahmenbedingungen:
openSUSE 15.3 Scanner ScanJet Pro 4500 fn1 sane-backend libsane-hpio aus dem openSUSE Repo scanimage aus dem openSUSE Repo skanlite aus dem openSUSE Repo Scannen über USB oder Netzewerk, macht keinen Unterschied. Scannen aus ADF mit --source Duplex
Scannen mit skanlite funktioniert ohne Probleme. Insbesondere:alle Formate,
die gescannten Bilder sind nicht korrupt (keine Fehlermeldungen beim Weiterverarbeiten oder prüfen mit z.B. tiffinfo -D, convert, ....)
Scannen mit scanimage funktionert überhaupt nur mit tiff. Bei anderen Formaten bricht der Scanvorgang schon beim ersten Bild ab, das erste Bild wird unvollständig geladen. Beispiel:out001.jpeg.part
Bei tiff sind die Bilder zu fast 100% zudem korrupt, mit den Fehlern TIFFReadDirectory:Warning, Bogus "StripByteCounts" field, ignoring and calculating from imagelength. TIFFFillStrip:Read error on strip 0; got 16665600 bytes, expected 16695360.
convert meckert zwar, erlaubt aber noch eine Weiterverarbeitung.
Damit scheint mit der Schluss, dass das Problem wirklich bei scanimage liegt, korrekt. Oder?
Wie kann ich das Problem analysieren und weiter eingrenzen?
Gibt es ein anderes Programm, welches das scannen von der Kommandozeile unterstützt, diese Fehler aber vielleicht nicht hat? Wichtig ist mir das scannen von der Kommandozeile, egal mit welchem Programm. Sollte nur funktionieren.
Vielen Dank vorab!
Viele Grüße Karl
Hallo Karl,
hier, auf einer openSUSE 15.1 funktionieren scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format jpeg --mode Gray --resolution 150 --compression JPEG > test.jpg scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format jpeg > test.jpg scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format tiff --mode Color > test.tiff einwandfrei. Ich kann's dann zu Hause auf einer OS 15.4 auch probieren... Grüße, Norbert
Hallo Norbert, Hallo Lothar, vielen Dank für Eure Tests! On Monday, 30 January 2023 13:13:58 CET Norbert Zawodsky wrote:
hier, auf einer openSUSE 15.1 funktionieren
scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format jpeg --mode Gray --resolution 150 --compression JPEG > test.jpg scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format jpeg > test.jpg scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format tiff --mode Color > test.tiff
Das Problem liegt leider tiefer. Ihr habe beide mit einer Seite getestet, beim ScanJet Pro 4500 fn1 implizit mit --source Flatbed, dem Default. Zudem bei niedriger Auflösung, denn ohne Angabe von --resolution ist der Default 75 DPI. Hier meine Versuche: Gearbeitet habe ich immer mit scanimage --resolution XXX -x 210.000 -y 296.985 --mode Color --format=YYYY -- batch="filename-600-%03d.YYYY" Variiert habe ich die Auflösung XXX, das Format YYYY, den Dateinamen sowie, und jetzt wird es richtig spannend --source Flatbed --batch-count=1 --source ADF --batch-count=1 --source Duplex --batch-count=6 In den ADF habe ich immer drei Blatt, doppelseitig bedruckt eingelegt, auch bei --source ADF und --batch-count=1. Auf das Flachbett die Titelseite davon. Source Flatbed funktioniert mit scanimage problemlos mit den Formaten tiff, jpeg, png und pnm, alles in einer Auflösung von 600 DPI. Andere Formate und die Auflösung von 1200 DPI auf dem Flachbett kann scanimage nicht. Kein Abbruch, kein Formatfehler! skanlite bietet noch ein wenig mehr an. Bei Flatbed auch 1200 DPI und auch BMP. Funktioniert auch problemlos. --source ADF --batch-count=1 jpeg: OK bei einer Auflösung von 75 und 150 DPI. Bei 200 und 600 DPI bricht der Scan vorzeitig ab. Die letzten 1 bis 5 mm unten fehlen. Anzeigen kann man das Ergebnis z.B. mit okular, da sieht man, was fehlt. Die Fehlermeldung von scanimage ist "Application transferred to few scan lines". Der Scanner hat noch eine Weile "scanning" im Display angezeigt, obwohl scanimage schon lange abgebrochen war. Dieses Verhalten zeigt sich so bei jedem Abbruch. Man beachte: Bei --source Flatbed wird eine Seite in jedem Format mit höchster Auflösung 600 DPI korrekt gescannt. Bei --source ADF --batch-count=1 scheitert scanimage schon bei der ersten Seite ab einer Auflösung von 200 DPI und jpeg. tiff: OK bei einer Auflösung von 75 DPI. Bei Auflösungen von 150, 200 und 600 DPI wird die Seite gescannt, völlig OK durch gwenview angezeigt, aber die beiden TIFF Fehler gemeldet. Die tiff Dateien sind also korrupt. png: OK bei 75 und 150 DPI. Bei 200 DPI ist die Anzeige in gwenview OK, aber es gibt wieder besagte TIFF Fehler. Die Datei ist also korrupt. --source Duplex -batch-count=6 jpeg: OK bei 75 und 150 DPI. Bei 200 DPI bricht der Scan bei der ersten Seite ab. Anzeige mit okular bestätigt, dass die letzten 2 bis 5 mm unten fehlen. tiff: OK bei 75 und 150 DPI. Bei 200 und 600 DPI werden alle sechs Seiten korrekt gescannt, haben aber besagte TIFF Fehler, sind also korrupt. Dagegen bei skanlite: jpeg und tiff mit 600 DPI und Duplex gescannt, alle sechs Seiten sind OK. Kein Abbruch, kein TIFF Fehler. Zur weiteren Eingrenzung des Fehlers: skanlite ist gegen /usr/lib64/libKF5Sane.so.5 gelinkt scanimage ist gegen /usr/lib64/libsane.so.1 gelinkt. Kann jemand, der xsane nutzt, vielleicht mal ldd `which xsane` ausführen und mir sagen, gegen welche Bibliothek xsane gelinkt ist, und ob es solche Probleme auch bei xsane gibt? Vielen Dank im Voraus Karl
Hallo Karl, Am 30.01.23 um 21:31 schrieb Karl Weber:
Hallo Norbert, Hallo Lothar,
vielen Dank für Eure Tests!
On Monday, 30 January 2023 13:13:58 CET Norbert Zawodsky wrote:
hier, auf einer openSUSE 15.1 funktionieren
scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format jpeg --mode Gray --resolution 150 --compression JPEG > test.jpg scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format jpeg > test.jpg scanimage -d hpaio:/net/scanjet_pro_4500_fn1?ip=192.168.1.133 --format tiff --mode Color > test.tiff Das Problem liegt leider tiefer. Ihr habe beide mit einer Seite getestet, beim ScanJet Pro 4500 fn1 implizit mit --source Flatbed, dem Default.
Zudem bei niedriger Auflösung, denn ohne Angabe von --resolution ist der Default 75 DPI.
Hier meine Versuche:
Gearbeitet habe ich immer mit
scanimage --resolution XXX -x 210.000 -y 296.985 --mode Color --format=YYYY -- batch="filename-600-%03d.YYYY"
Variiert habe ich die Auflösung XXX, das Format YYYY, den Dateinamen sowie, und jetzt wird es richtig spannend
--source Flatbed --batch-count=1 --source ADF --batch-count=1 --source Duplex --batch-count=6
In den ADF habe ich immer drei Blatt, doppelseitig bedruckt eingelegt, auch bei --source ADF und --batch-count=1. Auf das Flachbett die Titelseite davon.
Source Flatbed funktioniert mit scanimage problemlos mit den Formaten tiff, jpeg, png und pnm, alles in einer Auflösung von 600 DPI. Andere Formate und die Auflösung von 1200 DPI auf dem Flachbett kann scanimage nicht. Kein Abbruch, kein Formatfehler!
skanlite bietet noch ein wenig mehr an. Bei Flatbed auch 1200 DPI und auch BMP. Funktioniert auch problemlos.
--source ADF --batch-count=1
jpeg: OK bei einer Auflösung von 75 und 150 DPI. Bei 200 und 600 DPI bricht der Scan vorzeitig ab. Die letzten 1 bis 5 mm unten fehlen. Anzeigen kann man das Ergebnis z.B. mit okular, da sieht man, was fehlt.
Die Fehlermeldung von scanimage ist "Application transferred to few scan lines". Der Scanner hat noch eine Weile "scanning" im Display angezeigt, obwohl scanimage schon lange abgebrochen war.
Dieses Verhalten zeigt sich so bei jedem Abbruch.
Man beachte: Bei --source Flatbed wird eine Seite in jedem Format mit höchster Auflösung 600 DPI korrekt gescannt. Bei --source ADF --batch-count=1 scheitert scanimage schon bei der ersten Seite ab einer Auflösung von 200 DPI und jpeg.
tiff: OK bei einer Auflösung von 75 DPI. Bei Auflösungen von 150, 200 und 600 DPI wird die Seite gescannt, völlig OK durch gwenview angezeigt, aber die beiden TIFF Fehler gemeldet. Die tiff Dateien sind also korrupt.
png: OK bei 75 und 150 DPI. Bei 200 DPI ist die Anzeige in gwenview OK, aber es gibt wieder besagte TIFF Fehler. Die Datei ist also korrupt.
--source Duplex -batch-count=6
jpeg: OK bei 75 und 150 DPI. Bei 200 DPI bricht der Scan bei der ersten Seite ab. Anzeige mit okular bestätigt, dass die letzten 2 bis 5 mm unten fehlen.
tiff: OK bei 75 und 150 DPI. Bei 200 und 600 DPI werden alle sechs Seiten korrekt gescannt, haben aber besagte TIFF Fehler, sind also korrupt.
Dagegen bei skanlite:
jpeg und tiff mit 600 DPI und Duplex gescannt, alle sechs Seiten sind OK. Kein Abbruch, kein TIFF Fehler.
Zur weiteren Eingrenzung des Fehlers:
skanlite ist gegen /usr/lib64/libKF5Sane.so.5 gelinkt scanimage ist gegen /usr/lib64/libsane.so.1 gelinkt.
Kann jemand, der xsane nutzt, vielleicht mal
ldd `which xsane` ldd `which xsane` | grep sane libsane.so.1 => /usr/lib64/libsane.so.1 ausführen und mir sagen, gegen welche Bibliothek xsane gelinkt ist, und ob es solche Probleme auch bei xsane gibt?
Vielen Dank im Voraus Karl
Viel Erfolg Mark
Am 30.01.23 21:31 schrieb Karl Weber:
ldd `which xsane`
Hallo Karl, aber gerne! Bin jetzt wieder im Büro, also OS 15.1 : ----------------------------------------- rincewind:/ # ldd `which xsane` linux-vdso.so.1 (0x00007ffff0356000) libsane.so.1 => /usr/lib64/libsane.so.1 (0x00007f70d3869000) libgimp-2.0.so.0 => /usr/lib64/libgimp-2.0.so.0 (0x00007f70d3620000) libgimpbase-2.0.so.0 => /usr/lib64/libgimpbase-2.0.so.0 (0x00007f70d3406000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f70d2dcb000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f70d2b16000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f70d28c2000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f70d25ab000) libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f70d2368000) liblcms2.so.2 => /usr/lib64/liblcms2.so.2 (0x00007f70d210d000) libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007f70d1e94000) libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007f70d1c2b000) libz.so.1 => /lib64/libz.so.1 (0x00007f70d1a14000) libm.so.6 => /lib64/libm.so.6 (0x00007f70d16dc000) libc.so.6 => /lib64/libc.so.6 (0x00007f70d1321000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f70d1108000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f70d0f04000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f70d0b9b000) libgimpconfig-2.0.so.0 => /usr/lib64/libgimpconfig-2.0.so.0 (0x00007f70d098a000) libgimpcolor-2.0.so.0 => /usr/lib64/libgimpcolor-2.0.so.0 (0x00007f70d077c000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f70d0445000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f70d0220000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70d0001000) libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f70cfc62000) libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f70cfa5e000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f70cf850000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f70cf50f000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f70cf309000) libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f70cf0e3000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f70ceecc000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f70cec7d000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f70cea38000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f70ce82e000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f70ce62b000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f70ce41a000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f70ce20f000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f70ce004000) libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f70cde01000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f70cdbfe000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f70cd9ec000) libffi.so.7 => /usr/lib64/libffi.so.7 (0x00007f70cd7e2000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f70cd555000) liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f70cd31b000) libjbig.so.2 => /usr/lib64/libjbig.so.2 (0x00007f70cd10f000) /lib64/ld-linux-x86-64.so.2 (0x00007f70d3d3c000) libudev.so.1 => /usr/lib64/libudev.so.1 (0x00007f70cceeb000) libgimpmath-2.0.so.0 => /usr/lib64/libgimpmath-2.0.so.0 (0x00007f70ccce5000) libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f70cca3f000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f70cc785000) libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007f70cc571000) libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007f70cc36d000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f70cc144000) libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007f70cbf36000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f70cbca5000) librt.so.1 => /lib64/librt.so.1 (0x00007f70cba9d000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f70cb874000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f70cb65d000) libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007f70cb400000) libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f70cb158000) libthai.so.0 => /usr/lib64/libthai.so.0 (0x00007f70caf4e000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f70cad1c000) libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007f70cab17000) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f70ca8fa000) libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f70ca644000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f70ca440000) libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f70ca20e000) libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007f70c9fbb000) libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f70c9d95000) libdatrie.so.1 => /usr/lib64/libdatrie.so.1 (0x00007f70c9b8e000) libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f70c9986000) rincewind:/ # -------------------
Hi, ich weiß nicht, ob Ihr Euch erinnert, der Versuch mit dem hpaio backend vom Scanner HP ScanJet Pro 4500 fn1 zu scannen, schlug bei mir unter openSUSE 15.3 fehl. Ging nur beim Scannen von Flatbed, aber nicht beim Scannen von ADF oder Duplex. Weitere Analysen hatten schon auf das hpaio backend hingewiesen. Nach einem Umstieg auf openSUSE 15.5 hat sich daran nichts geändert. Nun bin ich inzwischen aber etwas schlauer. Laut Benutzerhandbuch unterstützt der Scanner auch AirPrint und damit das eSCL Protokoll. Dieses kann man prinzipiell mit den beiden sane backends escl und airscan nutzen. escl ist standardmäßig dabei, airscan leider nicht, aber das kann man über ein Repository für openSUSE leap 15.4 einbinden (funktioniert auch mit 15.5) -- oder selbst compilieren und installieren. Wenn man den Service mdns in der Firewall freischaltet, liefert scanimage -L alle drei backends (der Scanner hängt am LAN, nicht am USB): device `escl:http://192.168.5.20:8080' is a HP ScanJet Pro 4500 fn1[99F5CD] adf,platen scanner device `airscan:e0:HP ScanJet Pro 4500 fn1[99F5CD]' is a eSCL HP ScanJet Pro 4500 fn1[99F5CD] ip=192.168.5.20 device `hpaio:/net/hp_scanjet_pro_4500_fn1?ip=192.168.5.20&queue=false' is a Hewlett-Packard hp_scanjet_pro_4500_fn1 all-in-one hpaio funktioniert unter 15.5 genauso wenig, wie unter 15.3. Überhaupt gefällt mit hplip seit längerem nicht mehr! Schon bei 15.3 musste ich basteln, um den Drucker HP P2055dn via LAN zum Laufen zu bringen, unter 15.5 aus anderem Grund ebenso, (siehe den anderen Thread zur ppd Datei.) escl funktioniert noch schlechter, als hpaio, nämlich gar nicht! airscan dagegen scheint zu funktionieren. Alle bisherigen Tests waren erfolgreich, mit Flatbed, ADF und 'ADF Duplex'. Darüber hinaus bietet der Scanner HP ScanJet Pro 4500 fn1 mit den eSCL backends mehr Optionen an, als mit dem hpaio backend. Für mich ein Grund, hpaio mit diesem Scanner zu vergessen. Ist vielleicht auch für den einen oder anderen interessant. Viele Grüße Karl
Hallo Karl, großer Dank für den Hinweis. Mit freundlichem Gruß Karl Brandt -------- Original-Nachricht --------
Hi,
ich weiß nicht, ob Ihr Euch erinnert, der Versuch mit dem hpaio backend vom Scanner HP ScanJet Pro 4500 fn1 zu scannen, schlug bei mir unter openSUSE 15.3 fehl. Ging nur beim Scannen von Flatbed, aber nicht beim Scannen von ADF oder Duplex. Weitere Analysen hatten schon auf das hpaio backend hingewiesen.
Nach einem Umstieg auf openSUSE 15.5 hat sich daran nichts geändert.
Nun bin ich inzwischen aber etwas schlauer. Laut Benutzerhandbuch unterstützt der Scanner auch AirPrint und damit das eSCL Protokoll. Dieses kann man prinzipiell mit den beiden sane backends escl und airscan nutzen. escl ist standardmäßig dabei, airscan leider nicht, aber das kann man über ein Repository für openSUSE leap 15.4 einbinden (funktioniert auch mit 15.5) -- oder selbst compilieren und installieren.
Wenn man den Service mdns in der Firewall freischaltet, liefert scanimage -L alle drei backends (der Scanner hängt am LAN, nicht am USB):
device `escl:http://192.168.5.20:8080' is a HP ScanJet Pro 4500 fn1[99F5CD] adf,platen scanner device `airscan:e0:HP ScanJet Pro 4500 fn1[99F5CD]' is a eSCL HP ScanJet Pro 4500 fn1[99F5CD] ip=192.168.5.20 device `hpaio:/net/hp_scanjet_pro_4500_fn1?ip=192.168.5.20&queue=false' is a Hewlett-Packard hp_scanjet_pro_4500_fn1 all-in-one
hpaio funktioniert unter 15.5 genauso wenig, wie unter 15.3. Überhaupt gefällt mit hplip seit längerem nicht mehr! Schon bei 15.3 musste ich basteln, um den Drucker HP P2055dn via LAN zum Laufen zu bringen, unter 15.5 aus anderem Grund ebenso, (siehe den anderen Thread zur ppd Datei.)
escl funktioniert noch schlechter, als hpaio, nämlich gar nicht!
airscan dagegen scheint zu funktionieren. Alle bisherigen Tests waren erfolgreich, mit Flatbed, ADF und 'ADF Duplex'.
Darüber hinaus bietet der Scanner HP ScanJet Pro 4500 fn1 mit den eSCL backends mehr Optionen an, als mit dem hpaio backend. Für mich ein Grund, hpaio mit diesem Scanner zu vergessen.
Ist vielleicht auch für den einen oder anderen interessant.
Viele Grüße Karl
Am 3. Juli 2023 13:06:11 MESZ schrieb Karl Weber
Überhaupt gefällt mit hplip seit längerem nicht mehr!
Mir gefällt hp aus anderen Gründen schon seit längerem nicht mehr. Aufgrund deren Gebahren sollte niemand mehr hp kaufen. Und deshalb wurde hp bei mir ausgemustert und durch Brother ersetzt. Mit vollster Zufriedenheit . Gruß Eric
On Montag, 3. Juli 2023 17:44:02 CEST Eric Schirra wrote:
Und deshalb wurde hp bei mir ausgemustert und durch Brother ersetzt. Mit vollster Zufriedenheit .
Werde ich mir merken, sobald meine Hardware kaputt geht. Wobei ich hoffe, dass sie noch lange halten wird.... Viele Grüße Karl
participants (6)
-
Eric Schirra -
Karl Brandt -
Karl Weber -
Lothar Vorrath -
Mark Wenzel -
Norbert Zawodsky