Re: capi4hylafax in sarge bzw. sid
Hallo!
Gerhard Brauer schrieb:
Das Tiff-Komprimierungsformat hat aber IMHO nichts mit den Fax-Klassen
(Analog, ISDN) zu tun, sondern lediglich wie optimiert das daraus
generierte Fax für das verwendete Transportmedium und die Gegenstelle
ist. Bin mir aber da nicht 100% sicher.
Gut, da bin ich mir auch nicht sicher, ich hatte so verstanden.
Danach funktioniert es bei mir sowohl vom Server, als auch über SambaFax
einwandfrei (Linux-Clients habe ich keine). Wäre interessant ob das nur
bei mir funktioniert oder auch bei Euch?!
Ja, diese "harte" Konfiguration funktioniert hier auch mit
Linux-Clients.
Das ist schön, aber ja leider keine endgültige Lösung.
Das gleiche Verhalten kannst du mit sendfax durch die Parameter -1, -2
oder -3 erreichen. -1 entspricht der Verwendung von tiffg3. Siehe auch
man sendfax. D.h. mit sendfax -1 funktioniert es auch ohne die
Verwendung des globalen Parameters Use2D: no.
Damit ist es für mich wenigstens für den Moment gelöst - ich hab einfach
den -1 Schalter in das sambafax-script eingebaut und konnte die Änderung
am ps2fax script damit rückgängig machen.
Wann von ps2fax welcher Parameter verwendet wird, ist IMHO etwas
undurchsichtig. Laut Manpage würde er aufgrund des verwendeten
Faxdevices (Modem,ISDN-Karte) und das, was die Gegenstelle kann,
ermittelt. Letzteres kann sein, es gibt die Möglichkeit ein Log über die
Gegenstelle zu führen. Vor dem Verbindungsaufbau ist das ja nicht
möglich.
Ich hab gerade nochmal mehr zum Thema Modems gelesen und in der
hylafax-Doku einen Hinweis über sog. Class2Liars gelesen. Dort steht
dass das Modem selbst angeben kann ob es tiffg4 unterstützt oder nicht.
Mir ist allerdings nicht ganz klar, ob hylafax das im Fall von
capi4hylafax überhaupt abfragt bzw. ob es eine Antwort bekommt. (Siehe
http://www.hylafax.org/setup-advanced.html#Class2Liars)
Ich hatte zu diesem fehler ja einen Bugreport geschrieben, #296302. Und
auch mit dem Maintainer noch einige Tests durchgeführt. Dieser Bug wurde
dann an capi4hylafax weitergeleitet, da die von hylafax generierten
Ausgangsdateien (also das PS und das Tiff) in Ordnung sind. Weiter
konnte der Maintainer aufgrund fehlender CAPI-Umgebung nicht testen.
Ich bin darüber momentan nicht sehr glücklich, weil deine Tests ja jetzt
auch gezeigt haben das die Ursache in der ps2fax liegt. Jetzt ist halt
nur die Frage wer ruft wann dieses Skript auf und wie wird bestimmt
welcher Parameter (-1,-2,-3) für die Fax/Tiff-Erstellung verwendet wird.
Wenn es dir recht ist, schreibe ich deine Erkenntniss dem Maintainer
noch mal, mit dem ich mittlerweile "ganz gut kann". Wäre das OK?
Ja logisch, gerne!
Ich sehe das momentan als irgendetwas sehr Verzwicktes an, woraus halt
ersichtlich ist das Sarge noch nicht stable ist.
Das stimmt ganz gewiss :-)
a) Modem-Benutzer haben scheinbar dieses Problem nicht. Heißt das, das
bei denen z.B. immer -1 als Parameter an ps2fax mitgegeben wird? Wenn
ja, warum?
Ich vermute das kommt daher, dass eben wie oben beschrieben das Modem
gefragt wird welche TIFF Formate es unterstützt. Und wenn die Modems
funktionieren und keine "liars" sind dann wird entweder -3 nicht
verwendet oder das Modem unterstützt es eben.
b) Wie war das "damals", als es noch funktionierte? Wenn da auch schon
per Default mit dem Parameter -3 (tiffg4) gearbeitet wurde, dann konnte
scheinbar capi4hylafax das durchaus. Dann wäre die Ursache doch bei
capi4hylafax zu suchen. Oder hat sich in ghostscript etwas geändert, das
ps2fax veranlaßt jetzt die g4-Kompression zu nutzen und dann fällt
capi4hylafax auf die Schnauze.
Der -3 Schalter zum ps2fax script wurde mit Version 1.2 dieser Datei im
hylafax-CVS eingeführt und das war am 09.02.03 und damit nach dem
Release der Version 4.1.3, die in Debian stable verwendet wird (laut
hylafax Pressemitteilungen und Dateidatum 29.07.2002). Daher hat es auf
jeden Fall mit Debian stable und vermutlich bis einschließlich Version
4.1.5 von hylafax funktioniert.
Siehe dazu CVS-Web von hylafax:
http://www.hylafax.org/cgi-bin/cvsweb.cgi/util/ps2fax.gs.sh.in?hideattic=1&sortbydate=0#diff
http://www.hylafax.org/cgi-bin/cvsweb.cgi/util/ps2fax.gs.sh.in.diff?r1=1.1&r2=1.2&hideattic=1&sortbydate=0&f=h
Und das Source-Release-FTP-Verzeichnis
ftp://ftp.hylafax.org/source/
c) Es hat ja (bei mir und ich denke auch bei anderen, die Sarge
verwenden) auch funktioniert. Aber es gab sowohl 1-2 hylafax(server,
client) updates, IMHO auch für capi4hylafax und auch von ghostscript.
Und der Zeitraum, ab dem die ersten Probleme auftraten dürfte so 4-5
Wochen sein.
Das wiederum passt zu meinen Beobachtungen nicht so ganz, Erklärungen wären:
a) Es werden modem-capabilities von capi4hylafax abgefragt und die sind
seit neuestem falsch (es wird angegeben dass tiffg4 unterstützt wird,
was es laut der LIESMICH.html in der capi4hylafax-Distribution im
Abschnitt 4 aber definitiv nicht wird) Allerdings gibt es in den
capi4hylafax sourcen keinen Hinweis auf eine capabilities-Abfrage, daher
halte ich das für unwahrscheinlich.
b) Es wurde etwas in hylafax geändert wodurch nun der Schalter -3 erst
seit neuestem verwendet wird. Zum Beispiel ein default nun nicht mehr
auf -1 eingestellt ist, wenn es keine capabilities mehr gibt sondern auf
-3. Aber das sind nur Spekulationen.
BTW: Wenn jemand, der hylafax+capi auf stable verwendet vielleicht mal
testen könnte ob ein:
sendfax -3 <übliche Optionen> /etc/motd
auch zu dem Fehler (nur Kopfzeile im Fax) wie in Sarge führt.
Den Schalter gibts da vermutlich gar nicht (siehe oben)...
Viele Grüße,
Markus
Reply to: