News
Xerox kündigt Softwarepatch an
Einen Tag nach dem ersten Statement, das im wesentlichen bereits bekannte Informationen enthielt, gibt es nun ein weiteres Statement von Xerox.
Darin kündigt Xerox einen Softwarepatch an, der den fraglichen Kompressionsmodus komplett abstellt. Das ist die absolute Radikallösung, denn der Modus wurde immerhin in den Hochglanzprospekten als High-end-Feature hervorgetan. Wie ich hier ja schon mehrfach geschrieben habe, ist patch based lossy compression in einem Dokumentenscanner eher fehl am Platze.
Speicherknappheit ist nicht mehr verbreitet, und wenn man bei keinem der gescannten Dokumente Rechtssicherheit hat, oder Angst haben muss die Rentenkasse zu entlasten, indem man der eigenen Oma die Medikamentendosierung mit Xerox-Geräten scannt, ist das sicherlich auch nicht im Sinne des Erfinders.
Der Tag danach
… wird wohl noch etwas auf sich warten lassen.
So halb war ich drauf gefasst, dass die Sache jetzt an Schwung verlieren würde, und ich habe ja auch nicht vor, Xerox zu schaden. Ich habe mich ernsthaft gefreut, wie offen sie auf mich zugegangen sind und habe daher auch ernsthaft versucht, zu helfen.
Aber – Stammleser kennen diesen Satz schon – wir gehen nun über zur Thematik „das Internet vergisst nichts.“ Lest mal die teilweise harschen Kommentare unter dem Xerox-Statement! So ganz scheint man sich nicht damit zufrieden zu geben, dass ein einmaliger kleiner Hinweis beim Einstellen der Kompression auf „Normal“ (sic!) ausreichen soll, um mögliche Jahresladungen subtil verfälschter Dokumente über vielleicht zigtausende Unternehmen weltweit einfach abzuhaken. Die Seite läuft schon den ganzen Tag über bei bis zu 160 Hits pro Minute, weil die Xerox-Sache so ganz, ganz langsam die Massenmedien erreicht. Ein Bekannter von mir hat die Sache auf eine wunderschöne Art und Weise auf den Punkt gebracht, die ich euch nicht vorenthalten möchte:
Oh, wow, David, du bist am Arsch. Es steht GANZ KLAR im Bedienerhandbuch. Oder hast du etwa die Seite 107 von 328 nicht gelesen? – Das ist ja, wie wenn ich im Auto die Heizung auf exakt 21 Grad stelle, dann deswegen die Bremse nicht funktioniert, und sich die Herstellerfirma nach Jahren von unerklärlichen Unfällen auf Seite 107 im Manual bezieht, wo ganz klar steht, dass man nun mal nicht exakt 21 Grad einstellen sollte, wenn man auch bremsen will.
Treffer, versenkt – wobei vergessen wurde, dass ich meinen Blogartikel ja gar nicht erst geschrieben hätte, wenn der Xerox Support über alle Level hinweg mal auf das Schlagwort „Character Substitution“ reagiert hätte. Den Mund hab ich mir fusselig geredet.
Einenhabichnoch, einenhabichnoch: Den besten und trockensten Kommentar zum Thema habe ich auf Gizmodo gelesen. „You had 1 Job, Xerox, 8 Job.“
Bleibt mir gewogen, und natürlich wird hier weiter zum Thema gepostet, sobald es was neues gibt. Vielen herzlichen Dank für die Unterstützung aus aller Welt!
Edit: Noch eine (ernstere) Sache, die ich die ganze Zeit gefragt werde. Kann das mehr als nur ein Xerox-Problem sein? Ich denke, ja. JBIG2 ist ein mächtiges Kompressionsverfahren, aber wie wir alle sehen, kann es gefährlich werden, wenn es falsch eingesetzt wird. Der wichtige Punkt ist, dass die Benutzer nicht sehen können, dass der Scan falsch ist. Andere Kompressionsverfahren lassen Zahlen unter Artefakten untergehen, und dann sieht man das und scannt eben neu. Hier werden kaputte Zahlen durch wunderschön aussehende, jedoch vielleicht inkorrekte ersetzt. Das macht den Fehler extrem schwer zu finden. Diese Sache existiert in Xeroxmaschinen anscheinend über Jahre hinweg, und *jetzt*, wo die Leute aufmerksam geworden sind, reproduzieren sie den Fehler über die ganze Welt hinweg. Natürlich kann das auch bei Maschinen genauso passieren, die nicht von Xerox sind.
Was Xerox angeht: Ich stimme mit Xerox überein, dass die Sache nicht in dem Sinne ein Bug sein muss (it's not a bug, it's a feature!!1) – aber in jedem Fall ist es der Supergau unter den Kommunikationspannen sowohl vom Aspekt der Dokumentation, als auch vom Support, als auch von der Reaktionsgeschwindigkeit der Pressestelle her. Und diese Panne erzeugt dann leider exakt die Folgen, die ich gefürchtet habe, als ich noch davon ausging, es wäre ein Bug.
Andere sehen das nciht ganz so rosig. Mir ist mehrmals die Hypothese zugetragen worden, dass das durchaus ein Bug war, der Xerox irgendwann zugetragen wurde – und dann konnten sie natürlich keinen Rückschritt machen, sondern haben das „Normal“-Setting nicht mehr als Default rausgegeben und eine kleine Meldung daneben platziert. Dass Patch-Based lossy compression in einem Dokumenten-Scankopierer nicht sinnvoll einzusetzen ist, macht diese These nicht unplausibel.
Mag jeder selbst sehen, was er am wahrscheinlichsten findet.
Telefonkonferenz mit Xerox
Gerade eben hatte ich eine halbstündige Telefonkonferenz mit
- Rick Dastin, Corporate Vice President Office and Solutions, und
- Francis Tse, Imaging System Architect at Xerox Corporation.
Zuerst kann ich berichten, dass ich die Gesprächsatmosphäre angenehm und interessant fand, man war auch entspannt und keine Seite hat versucht, die jeweils andere zu irgendetwas zu treiben, sondern vor allem hat man sich gegenseitig zugehört. Ich begrüße sehr, wie Xerox die Sache angeht und das Gespräch sucht. Nicht alle Großkonzerne machen das so, wir alle kennen die Geschichten von Konzernen, die versucht haben, den Überbringer der Botschaft abzuwürgen.
Die harten Fakten vorab:
- Die Mutmaßungen hier im Blog zum Thema JBIG2 sind richtig
- der Workaround funktioniert, weil er das Pattern matching in JBIG2 abstellt.
- Das Problem war, bzw. ist, in erster Linie ein Serviceproblem, das nicht entstanden wäre, wenn der Support seine eigenen Menüpunkte gekannt hätte.
Jetzt zu den Einzelheiten. Das Design von Xerox ist so, dass man ein paar Standardkompressionslevel anbietet (higher / high) und dann eben noch ein niedriges, das weniger Rücksicht auf Datenintegrität nimmt (heißt dann normal). Das „normal“ verwendet nun JBIG2 und kann Buchstaben vertauschen, bei „higher“ und „high“ wird ein anderes Kompressionsverfahren verwendet. So kommt die Anti-Intuition zustande, dass die sichtbare Bildqualität sich beim Wechsel von „normal“ zu „higher“ verschlechtern kann.
Ob man jetzt bei einem Scanner überhaupt einen Scanmodus braucht, der keine Rücksicht auf Datenintegrität nimmt, darüber kann man natürlich trefflich streiten. Bildet euch eure eigene Meinung. Der Kerndoppelsatz aus der Telefonkonferenz hierzu war folgendermaßen (übersetzt aus dem Gedächtnis):
David Kriesel: „Wenn Sie mir ein Dokument bringen, dass auf diese Weise JBIG2-enkodiert wurde, kann ich doch einfach sagen, dass das inkorrekt wäre, und sie könnten mir nicht das Gegenteil beweisen.“
Francis Tse: „Ja, das ist so, einfach aus Gründen der Wahrscheinlichkeitsrechnung.“
Um direkt fair zu sein: Das „normal“ ist nicht default (insbesondere hat das also bei der betroffenen Firma jemand eingestellt) und es gibt auch eine, wenn auch kleine, Warnungsmessage im Webinterface – schaut euch den Screenshot im Workaround Blogpost an.
Ich sehe es aber nicht so, dass Xerox damit aus dem Schneider ist, weil so was immer irgendjemand einstellen kann, unabhängig vom Kleingedruckten im Webinterface, und alle anderen dann nichts wissen. Das grundsätzliche Design der Level finde ich zunächst mal verständlich, wobei wir aber darin übereingestimmt haben, dass die Benennungen sehr irreführend sind, weil man, wenn man eben nur Standarddokumente hat, vielleicht auch mal „normal“ einstellt ohne sich groß Gedanken zu machen (dass genau das anscheinend sehr viele Leute getan haben, dazu kommt gleich noch was, zusammen mit zwei Lösungsvorschlägen).
Möglicher Workaround für Zeichenersetzungen in Xerox Scankopierern
Es kann sein, dass eine Lösung oder zumindest ein Workaround gefunden wurde. Die Lösung scheint eine Scaneinstellung in den Kopierern zu sein, von der Xerox sogar bekannt zu sein scheint, dass sie Zeichenersetzungen produziert. Das wirft die Frage auf, warum mir die Einstellung von einem User überbracht wird, und nicht vom Xerox Support, der nun seid Ende Juli Zeit hatte und mehrfach vor Ort war . Aber dazu gleich mehr, erstmal die Lösung. Gestern wurde ich von einem Leser auf eine Einstellung in seinem (ebenfalls betroffenen) ColorQube 9203 aufmerksam gemacht, die den Fehler zumindest zu verringern scheint. Hier ein Screenshot:
Der Screenshot ist aus dem Browser-Menü des ColorQube 9203 (die Geräte besitzen einen integrierten HTTP-Server zur Steuerung) und da aus den Scanneinstellungen. Der Leser hat die Qualität von „Normal“ auf etwas höheres angehoben, was die Fehler ausmerzte (oder zumindest in der Anzahl deutlich reduzierte). Gleichzeitig wurde aber die Bildqualität nach Aussagen des Lesers deutlich reduziert (obwohl die Einstellung eine höhere suggeriert) – einige Zeichen sind nun sogar unleserlich. Aber so sieht der Benutzer wenigstens, dass etwas nicht stimmt, und kann noch einmal scannen. Die Firma des Lesers wird das „Normal“-Setting nun nicht weiter nutzen.
Nun zum Punkt: Ich kann all dies zumindest schon einmal für das Xerox WorkCentre 7535 bestätigen. Es gibt dieselbe Einstellung mit derselben „character substitution“ Meldung dort, und hochgesetzt wird die Qualität schlechter (sehr intuitiv), aber der Fehler tritt seltener oder nicht mehr auf.
Da Xerox nach wie vor keine Meldung von sich gegeben hat, kann ich nur hoffen, dass euch diese Information weiterhilft. Die Befürchtungen, dass mutmaßlich über verschiedenste Firmen hinweg vielleicht über einen langen Zeitraum subtil falsche Dokumente produziert worden sind, bleiben valide.