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:

1. Die Mutmaßungen hier im Blog zum Thema JBIG2 sind richtig
2. der Workaround funktioniert, weil er das Pattern matching in JBIG2 abstellt.
3. 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).

Was Xerox aber so nicht klar war, und dadurch klargeworden ist, ist die Masse an Kunden, die das „normale“ Setting anscheinend nutzen, weil sie, wie ich oben sagte, es einfach routinemäßig eingestellt haben, und denen nicht bewusst ist, dass das keine Rücksicht auf Datenintegrität nimmt und gefährlich ist. In der Folge ist das Buchstabenvertauschen also nicht in dem Sinne ein Bug, aber leider genauso gefährlich wie eingangs angegeben, zumal man im Web Interface schon wissen muss, was man sucht. Ich persönlich würde die leicht größeren Dateien in Kauf nehmen und niemals, never-ever, eine patch based compression für Textdaten nutzen, die u.U. Rechtssicherheit benötigen, was ich auch so vertreten habe.

Ein weiterer kleiner Punkt war, dass ich gesagt habe, wenn sie sehen, wie diese Meldung einschlägt hätten sie ja mal eine Meldung raushauen können. Dazu haben sie gesagt, im Kern ist das richtig, das war aber durch die langen Entscheidungswege und rechtliche Gründe nicht so einfach.

Aus diesem Grund versuchen sie nun, das ihren Kunden zu sagen, aber haben leider aufgrund der Größe der Firma und des nicht komplett zentralisierten Vertriebs keine vollständige Liste. Sie werden wohl nun über die Massenmedien gehen, und dieses Statement ist ein Schritt dazu, und ich möchte dazu hier gerne beitragen, solange ich die Hits zu dem Thema noch habe.

Das Hauptproblem in unserem partikulären Fall war, und auch darin haben wir übereingestimmt, dass der Xerox Support anscheinend überhaupt nichts über die mögliche Buchstabenvertauschung wusste, und zwar über alle Supportlevel hinweg. Wir haben volle eineinhalb Wochen gegenüber dem Support immer und immer wieder alle Signalwörter genannt und hatten mehrere Hausbesuche, und am Ende war es – ausgerechnet! – ein von dem „Bug“ ebenfalls betroffener User, der uns mit der Nase drauf gestoßen hat. Es war quasi nicht diskussionswürdig, so einig waren sich alle, dass das sehr verwunderlich sei.

Zuletzt haben wir dann noch über die Anwendung der JBIG2-Kompression geredet, und man hat sich meine Bitte zu Herzen genommen, die Maximalgröße der Patches kleiner zu setzen. Inwiefern das auch gemacht wird, kann ich natürlich nicht sagen.

Edit und Fazit: Nach reiflicher Überlegung möchte ich noch mal ganz klar sagen, dass mir eigentlich nur zwei konkrete Vorschläge einfallen.

1. Man streicht patch based lossy compression komplett aus dem Programm (Speicherverbrauch ist sowieso fast nirgendwo noch Thema), oder
2. man bringt, falls diese Komprimierung eingesetzt wird, vor jedem einzelnen Scan eine Meldung, die auf dem Kopiererdisplay bestätigt werden muss, damit der User auf jeden Fall sicher ist, dass alles mögliche passieren kann. Zusätzlich kommt für den Fall der Weitergabe ein Warnungswasserzeichen auf so gescannte Dokumente.

Irgendeine winzige, technische Meldung im Webinterface genügt jedenfalls nicht – soviel hat die ganze Sache, und die mehr als 200.000 Hits auf meiner Seite, uns ja gelehrt. Ich kriege nach wie vor eMails von Leuten, die sich wundern, dass ihr Xeroxgerät das hier beschriebene Verhalten zeigt. Die kann ich jetzt wenigstens auf den Workaround verweisen.