Einstellungen fürs ersetzende Scannen

[#1]

Wenn ich alles richtig verstanden habe, muss ich mit UO die Papierbelege nach dem Scannen nicht mehr aufbewahren - die Belege hängen an der Buchung und die StB'in kann alles für die Steuerprüfung exportieren.

Leider gibt die BSI "RESISCAN" Richtlinie wenig her was das Ablageformat angeht.

Ich scanne zzt. mit 200dpi (langt bei Fax ja auch) in Grau bzw. Farbe (entscheidet der Scanner selber) und packe das Abbild zusammen mit der OCR-Auswertung in ein PDF/A

200dpi sind manchmal etwas knapp, aber UO kann es bislang fehlerfrei indizieren und auswerten.

Komme ich damit klar oder gibt das Setup Ärger mit dem Prüfer (dh. die Belege nochmal in einem lokalen DMS ablegen)?

Gruss

Bernd

[#2 · Accepted solution]

Hallo Herr Hohmann,

bitte halten Sie diesbezüglich erneut Rücksprache mit Ihrer Steuerberaterin oder Ihrem Steuerberater. Das Einscannen von Belegen und die spätere Verknüpfung zu Buchungen befreit Sie nicht von der Aufbewahrung der Originalbelege, hierzu sind weitere Maßnahmen erforderlich. Das so genannte ersetzende Scannen setzt z. B. auch eine Verfahrensdokumentation sowie deren Einhaltung voraus.

Viele Grüße

Christian Wielgoß

[#3]

> bitte halten Sie diesbezüglich erneut Rücksprache mit Ihrer Steuerberaterin

> oder Ihrem Steuerberater.

"Ersetzendes Scannen" hab ich hinreichend bei meinen Kunden eingeführt und alle Prüfer der letzten Jahrzehnte waren überglücklich  - nur kann ich da problemlos jeden Fetzen Papier mit 600dpi als 2-10MB grosse Dateien revisionssicher ablegen weil die Storagebackends mitgewachsen sind und mittlerweile Terabytes die untere Grenze darstellen.

Bei UO hingegen kostet mich jedes Kilobyte eines jeden abgelegten Dokuments erstmal nicht viel, aber über 10 Jahre doch merkbar Geld.

Und daher möchte ich natürlich meine Dokumente möglichst klein halten.

Die StB'In brauch ich nicht zu fragen - da kommt als Antwort "§ 257 Abs. 3 HGB, § 147 Abs. 2 AO" und da sind wir ganz schnell beim Problem der "Lesbarkeit" was die StB'In den Teufel tun wird, das für mich zu entscheiden

Ich habe keine "Best Practices" für Datev-UO im Bereich "Scannen" gefunden, ausser dem Ratschlag dass ich 300dpi verwenden soll - was mein Scanner bei recht langen Streifen aus dem Baumarkt verweigert und nur 200dpi anbietet - und 300dpi ist eh überbewertet...

> Das so genannte ersetzende Scannen setzt z. B. auch eine Verfahrensdokumentation

> sowie deren Einhaltung voraus.

Auch diese Dokumentationen habe ich in allen Varianten in der Schublade - dejure kann ich dort reinschreiben, dass Mönche aus dem Mittelalter die Belege 1:1 per Gänsefeder abmalen und alle Kriterien sind erfüllt - was der Prüfer dazu allerdings sagen wird weiss keiner.

Bernd

PS: die eigene Antwort als "hilfreich" taggen hat ein gewisses "Geschmäckle"....

[#4]

Hallo Herr Hohmann,

dass ich meinen eigenen Beitrag als hilfreich markiert habe, kann sich nur um ein Versehen handeln...jedenfalls kann ich mich nicht daran erinnern...

In Ihrem ursprünglichen Beitrag gingen nicht die Rahmenbedingungen hervor, die Sie in Ihrem Folgebeitrag geschildert haben. Mir ging es vor allem darum klarzustellen, auch für die Mitleserinnen und -leser, dass das Einscannen der Belege und ggf. Verknüpfung mit Buchungssätzen für sich allein genommen nicht von der Aufbewahrungspflicht der Originalbelege befreit.

Empfehlungen zu den Scaneinstellungen finden Sie hier: Digitales Belegbuchen: Arbeit mit dem Scanner

Eine Checkliste mit den wichtigsten Punkte zum ersetzenden Scann i. V. m. Unternehmen online finden Sie hier: https://secure4.datev.de/web/de/media/datev_de/pdf/checkliste.pdf

Viele Grüße

Christian Wielgoß

[#5]

Guten Tag,

leider reicht meine Berechtigung (SmartLogin für DUO) nicht aus, um auf

https://secure4.datev.de/web/de/media/datev_de/pdf/checkliste.pdf

zuzugreifen. 

Wie komme ich an dieses Dokument?

Danke sehr

[#6]

DUO ist grundsätzlich für esetzendes Scannen geeignet,

aber es stellt halt nur ein Teil des Workflows dar. Wichtig für ersetzendes Scannen ist aber der gesammte Workflow. Dieser muss in einer sogenannten Verfahrensdokumentation beschrieben und dokumentiert werden (Wer macht wann, wie und womat was, ...) 

https://www.datev.de/dnlexom/client/app/index.html#/document/1022111

https://secure16.datev.de/dlpon/course/view.php?id=284

https://www.datev.de/dnlexom/client/app/index.html#/document/9229235

[#7]

Gerne würde ich hier noch meinen Fall schildern, da sie Benutzer wie @berndhohmann anscheinend sehr ausführlich mit der Materie auseinandergesetzt haben.

Mir - als Einzelnunternehmer - kann in diesem Fall weder der StB noch die Datev helfen.

Falls Kosten für ein beratendes Projekt enstehen würden, können wir darüber auch gerne reden.

Ich würde gerne wissen, ob folgendes Vorgehen "legal und OK" ist:

- Rechnungen per Email sind in der Regel (leider) häufig 500 oder mehr Kilobyte gross, teilweise sogar mehrere MB. Entspricht somit nicht der Dateigrößen-Empfehlung der Datev und wird sehr teuer, teilweise können (aus nachvollziehbarer technischer Natur) keine Vorschauen erstellt werden

- Diese Rechnungen werden direkt auf dem Mailserver rechtsgültig gesichert und mehrstufig gesichert

- Ich drucke diese Rechnung aus

- Ich scanne diese Rechnung und importiere sie in DUO als PDF/A mit OCR

- Ich vernichte den Ausdruck aus Archiv-Platz-Gründen.

- Ich behalte die PDF/A, welche ich in DUO importiert habe, in einem lokalen Backup

- Ich brenne dieses lokales Backup jährlich auf ein nicht veränderbares Medium (Bluray)

Ich kann zu jeder Zeit den genau identischen Ausdruck wieder herstellen ("drucken", ggf durch einen anderen Drucker/Toner/Papier, inhaltlich jedoch identisch / oder aus einem lokalen Backup wiederherstellen)

(Ich bin mir bewusst, dass dies in Mehraufwand ist, der sich jedoch bei aktuellen Datenkosten in DUO deutlich rentiert)

Falls dieser Weg nicht legal ist: wie bekomme ich die Belege in DUO, ohne gegen die Dateigrössenwarnung, welche aktiv in DUO erscheint, zu verstossen sowie dies im bezahlbaren Rahmen zu halten und sämtliche Vorschaubilder zu erhalten?

Danke

[#8]

---

@sebn  schrieb:

- Rechnungen per Email sind in der Regel (leider) häufig 500 oder mehr Kilobyte gross, teilweise sogar mehrere MB. Entspricht somit nicht der Dateigrößen-Empfehlung der Datev und wird sehr teuer, teilweise können (aus nachvollziehbarer technischer Natur) keine Vorschauen erstellt werden

- Diese Rechnungen werden direkt auf dem Mailserver rechtsgültig gesichert und mehrstufig gesichert

- Ich drucke diese Rechnung aus

- Ich scanne diese Rechnung und importiere sie in DUO als PDF/A mit OCR

- Ich vernichte den Ausdruck aus Archiv-Platz-Gründen.

- Ich behalte die PDF/A, welche ich in DUO importiert habe, in einem lokalen Backup

- Ich brenne dieses lokales Backup jährlich auf ein nicht veränderbares Medium (Bluray)

---

In diesem Fall handelt es sich bei dem gescannten Beleg nicht um den Originalbeleg. Den Ausdruck können Sie nach dem Scannen dann problemslos vernichten, wichtig ist die digitale Version in der Emails

[#9]

Lieber Herr @mkinzler , ich glaube Ihre Antwort fehlt in letztem Beitrag.

Herzlichen Dank vorab schon für Ihre Mühe!

[#10]

Die Forumssoftware hat mich im Zitat gefangen genommen.

[#11]

---

@mkinzler  schrieb:

---

In diesem Fall handelt es sich bei dem gesannten Beleg nicht um den Originalbeleg. Den Ausdruck können Sie nach dem cannen dann problemslos vernichten, wichtig ist die digitale Version in der Emails

---

Die digitale Version ist rechtsgültig gespeichert und mehrfach gesichert.

Danke für die hilfreiche Nachricht!

[#12]

Wichtig ist die Dokumentation.

[#13]

Ja, ich habe hier intern das Wichtigste bereits zusammengefasst.

Bin jedoch an den unendlichen Vorlagen der Verfahrensdokumentation momentan gescheitert.

Für uns unwichtige Einzelunternehmer scheint es nichts passendes bisher zu geben.

[#14]

Hallo Sebn,

die Antworten der "Kollegen" zu Deinem Thema sind leider (ich hätte hier auch mehr erwartet) völliger Unsinn.

Defacto ist es leider so, dass PDF-Rechnungen mittlerweile so erstellt werden, dass ein Unwissender eine Toolbox nutzt die ein Unwissender via "Versuch und Irrtum" erstellt hat die auf einer Arbeit beruht, die ein Anderer auch mit viel Fleiss und "Versuch und Irrtum" erstellt hat.

3 Megabyte grosse Rechnungsdateien sind hier eher die Regel als die Ausnahme.

Der Trick besteht darin, via Ghostscript die eingehenden Belege zu untersuchen, die Grafiken darin ggf. auf 72dpi zu reduzieren und die im PDF gespeicherten "embedded" Fonts durch etwas Generisches zu ersetzen.

gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dDetectDuplicateImages=true \
-dPDFSETTINGS=/ebook -sOutputFile="tmp.pdf" "$file"

Das ist alles (naja, etwas Nachbearbeitung zb nachschauen ob das Kondensat eventuell grösser geworden ist etc...)

Bernd

[#15]

Hallo @berndhohmann ,

für mich klang das oben stehende und meine Recherche ganz plausibel.

Leider muss ich hier aber betreffend GS widersprechen. Und zwar energisch.

Durch meine Arbeit habe ich sehr viel mit PDFs zu tun, ebenso viel mit der ISO 32 000. Gerade Ghostscript (oder ImageMagick) besitzen als OpenSource-Tool nicht alle Eigenschaften, um moderne PDFs sauber herunterzurechnen. Transparanzen, DeviceN-Farbräume, Sonderfarben, Ebenen – ich besitze einen großen Satz an Testdokumenten, die  "abenteuerlich" erzeugte Rechnungen sein könnten, bei denen GS/IM kläglich und ohne Fehler scheitern.

Die Gefahr, dass ich durch den Einsatz von GS/IM das Original so verändere, dass sich nicht nur die Repräsentation, sondern auch der Inhalt ändern könnte, wäre mir persönlich und aus Erfahrung zu heiss.

Ein Ausdrucken über Acrobat (oder Produkten mit der APDFL integriert) wird das PDF immer genau so drucken, wie es erstellt wurde.

[#16]

> Leider muss ich hier aber betreffend GS widersprechen. Und zwar energisch.

Ich mache diesen sch**ss schon 35 Jahre und was Sie da - gerade gegen OS - aufführen ist völliger Käse, denn genau sowas läuft bei meinen Kunden und die haben etliche Prüfungen damit völlig problemlos überstanden.

Sie wollen sich nicht helfen lassen, für mich damit EOD

[#17]

---

Sie wollen sich nicht helfen lassen, für mich damit EOD

---

Ich lasse mir gerne helfen und bedanke mich auch hier nochmals über die Antwort – jedoch wird GS/IM für mich aus Erfahrung kein Weg sein. 

[#18]

> Ich lasse mir gerne helfen

Bei einer Rechnung zählt lediglich der für die Fibu interessante Inhalt, also ggf. die Artikelpositionen mit ihren Steuersätzen und final die Nettosummen mit ihren zugehörigen Steuersätzen.

Für den Prüfer ist interessant, ob der Ersteller der Rechnung irgendeine Steuer-ID hat und damit berechtigt ist, Umsatzsteuer auszuweisen und ob eine postalisch korrekte Absenderadresse vorhanden ist.

Und das ist das Zeug, was nach Komprimierung (also wegwerfen von überflüssigem Kram)  in Datev UO landen muss.

Dass 3MB fancy Hires-Logos im PDF auf platzsparende 72dpi (irgendwas um 5kb) wegkomprimiert werden ändert nichts an der "Legalität" der Rechnung - genausowenig wenn man den gesamten Inhalt so umstrukturiert, dass er weitaus weniger Speicherplatz benötigt und trotzdem das Orginal reproduzierbar bleibt.

PDFs zu konvertieren bedeutet nicht, irgendwelchen ISO-Normen zu folgen sondern dem zu entsprechen, was die HM der Gesetzgebung in der Interpretation durch die Richter an den jeweiligen Gerichten ist.

Und wer nicht versteht, dass sklavisches Nachbeten von ISO-Normen vor Gericht oftmals kein vollkommender Schutz vor Haftung ist - der sollte seine Arbeitsweise stark überdenken.

[#19]

@berndhohmann ,

letzten Endes zählt nur die Prüfungspraxis.

Niemand scannt wegen der Schönheit des Dokuments/des Belegs, sondern nur, um einen Beleg korrekt in digitalem Format zu archivieren und weiter zu verarbeiten. Selbstverständlich sollen/müssen sämtliche Vorgaben des FA erfüllt sein, z.B. wg. Vorsteuerabzug und die Speicherkosten sollen möglichst niedrig sein.

Hilfreich wären ein paar Urteile zum Thema "Ersetzendes Scannen".

Ich hatte mir bisher noch nicht die Mühe gemacht, danach zu suchen, da ich dem "Ersetzenden Scannen" (immer) noch sehr skeptisch gegenüber stehe.

... sich aber gegenseitig die Kompetenz abzusprechen, ist kontraproduktiv.

[#20]

Bei elektronisch eingehenden Rechnungen von „ersetzendem Scannen“ zu sprechen, ist aus meiner Sicht ohnehin nicht korrekt.

Nur papierhaft eingegangene Belege können ersetzend gescannt werden. Denn nur bei diesen kann das durch das Scannen entstandene Digitalisat das ursprünglich eingegangene Papieroriginal ersetzen.

[#21]

Deshalb kann man die Arbeitskopien (Ausdrucke) von digitalen Belegen nach dem Digitlalisieren (Einscannen) auch vernichten, da diese keon Original darstellen.

Obwohl ich den Sinn an dem analogen Umweg auch nicht ganz sehe.

[#22]

---

@mkinzler  schrieb:

Obwohl ich den Sinn an dem analogen Umweg auch nicht ganz sehe.

---

Falls gewünscht, schreibe ich gerne ein paar Zeilen erklärend dazu.

[#23]

> Obwohl ich den Sinn an dem analogen Umweg auch nicht ganz sehe.

Das ist ganz einfach: der Anwender bekommt schlampig erstellte PDF-Rechnungen wo zb. das Unternehmenslogo unkomprimiert mit 600dpi - und das noch mehrfach - sowie ganze Font-Libraries eingebunden sind.

Die Datei ist dann natürlich gross, Datev moniert das beim Upload, kann keine Vorschauen erstellen etc..

Jetzt könnte man das ganz simpel über ein Script lösen welches das PDF aufräumt. Also eingebettete Grafiken auf 72dpi herunterrechnen, Font-Libs herausschmeissen und einen Verweis auf Systemschriften setzen.

Damit hat sich Inhaltlich am PDF nichts geändert da ja nur um den Text herum aufgeräumt wurde (geht natürlich nur, wenn der Text als Text und nicht als Grafik abgelegt ist).

Da hat der Anwender aber Angst, dass ihm irgendwas verloren geht. Daher der Umweg über Ausdrucken, low-res Scannen, das entstandene TIFF dann hochkomprimiert in ein PDF stecken (macht der Scanner automatisch) und dieses Ergebnis in Datev eintüten.

Am besten macht man den Scan über eine alte Xerox Workstation für optimale Ergebnisse ...

[#24]

---

@berndhohmann  schrieb:

Damit hat sich Inhaltlich am PDF nichts geändert da ja nur um den Text herum aufgeräumt wurde (geht natürlich nur, wenn der Text als Text und nicht als Grafik abgelegt ist).

Da hat der Anwender aber Angst, dass ihm irgendwas verloren geht. Daher der Umweg über Ausdrucken, low-res Scannen, das entstandene TIFF dann hochkomprimiert in ein PDF stecken (macht der Scanner automatisch) und dieses Ergebnis in Datev eintüten.

Am besten macht man den Scan über eine alte Xerox Workstation für optimale Ergebnisse ...

---

Ich greife hier in ein PDF auf Textebene ein. Es könnten zb Ligaturen oder Euro-Zeichen verloren gehen, wenn diese in einer Schrift nicht standardmässig kodiert wurde. Technisch stimme ich zu, dass dies ein möglicher Weg wäre, ich könnte aber - in meinem Umfeld - bei diesen Korrekturen nicht gut schlafen. Am Ende hängt es ja am Prüfer - und ich weiss nicht, wie diese reagieren, wenn jede Rechnung schon visuell anders in Datev ausschaut als auf dem Papier.

Die erzeugten PDF/A mit OCR sind pro Seite nicht grösser als 20-30 kb und repräsentieren genau das Erscheinungsbild der Originalrechnung. Als "Abfallprodukt" landet genau dieses noch im DMS und ist per Volltextsuche indexiert.

Ich verstehe, dass es verschiedene Ansätze gibt (und verschiedene Glaubensrichtungen hier). Für mich war wichtig, ein inhaltlich korrektes, visuell identisches, volltextindexiertes, platzsparendes und kostengünstiges PDF/A in DUO zu haben. Originalrechnungen in Datev abzulegen funktioniert preislich und technisch nicht wirklich.

Danke an alle für ihren Input hier.

[#25]

> Am Ende hängt es ja am Prüfer - und ich weiss nicht, wie diese reagieren, wenn jede

> Rechnung schon visuell anders in Datev ausschaut als auf dem Papier.

Welches Papier?

Ich bin bislang davon ausgegangen, dass die Rechnungen vom Ersteller direkt als PDF erzeugt werden.

Da bei der nachträglichen Kompression von eingebetteten Bildern keine Änderung des Sachverhaltes stattfindet, sind wir immer noch im Rahmen der AO §140-148

Es gibt im PDF-Standard 14 Schriftarten (incl "Symbol" und "ZapfDingbats"), die werden Erfahungsgemäss auch genutzt. Einziger Ausnahmefall in den letzten 20 Jahren: Die Fiducia hat im Onlinebanking mal PDF-Kontoauszüge ausgeworfen wo ein OCR-A Font genutzt wurde - der ist nur in den seltensten Fällen irgendwo installiert, entsprechend wurde Courier genutzt und die Ausdrucke sahen etwas "seltsam" aus).

Und ansonsten schaut man einfach mal in das, was das BMF so zur GoBD sagt - neuester Wurf ist BMF v. 11.07.2019 - IV A 4 - S 0316/19/10003 :001

4.3 sagt "Eine erfassungsgerechte Aufbereitung der Buchungsbelege in Papierform oder die entsprechende Übernahme von Beleginformationen aus elektronischen Belegen (Daten, Datensätze, elektronische Dokumente und elektronische Unterlagen) ist sicherzustellen." und "Werden neben bildhaften Urschriften auch elektronische Meldungen bzw. Datensätze ausgestellt (identische Mehrstücke derselben Belegart), ist die Aufbewahrung der tatsächlich weiterverarbeiteten Formate (buchungsbegründende Belege) ausreichend, sofern diese über die höchste maschinelle Auswertbarkeit verfügen"

Habe ich also ein PDF und dazu noch ein XML, muss ich nur das XML aufbewahren und schmeiss das PDF weg (natürlich nur sofern ich das XML verarbeite, buche ich den PDF-Beleg muss das aufgehoben werden - nach AO eigentlich logisch).

Ausnahme: ZUGFeRD, da ist im PDF noch ein XML - getreu den Buchstaben des BMF-Schreibens darf man die eigentlich nicht Drucken und nur den Ausdruck archivieren (oder Scannen und dann Archivieren) sondern muss auch das PDF mit XML aufheben. Interessiert in der Praxis aber nicht wenn keine elektronische Verarbeitung des Belegs gemacht wird.

Und ist ein 30MB grosses PDF nicht "erfassunggerecht", dann sehe ich keinen Grund, die Datei "erfassungsgerecht" Aufzubereiten - ich ändere ja nichts an der Buchungsgrundlage und damit auch nichts an den Besteuerungsgrundlagen (§ 146 Absatz 4 AO) (man kann

Zitat meines letzten Prüfers: "Herr Hohmann, sie können das Firmengeld auch zum Fenster herauswerfen - solange sie es ordnungsgemäss versteuern, ist uns das egal"

Interessant wird es im BMF-Schreiben bei Rzn 135 wo steht: "Bei Umwandlung (Konvertierung) aufbewahrungspflichtiger Unterlagen in ein unternehmenseigenes Format (sog. Inhouse-Format) sind beide Versionen zu archivieren, [...]"

ABER (und das musste man dem BMF erst mühsam beibringen):

"Die Aufbewahrung beider Versionen ist bei Beachtung folgender Anforderungen nicht erforderlich, sondern es ist die Aufbewahrung der konvertierten Fassung ausreichend:

• Es wird keine bildliche oder inhaltliche Veränderung vorgenommen.

• Bei der Konvertierung gehen keine sonstigen aufbewahrungspflichtigen Informationen verloren.

• Die ordnungsgemäße und verlustfreie Konvertierung wird dokumentiert"

Übrigens: Ein Buchhaltungs-Dokument in allen Verarbeitungsstufen aufzubewahren ist bei Prüfungen eher ein Ärgernis als ein Vorteil - dann wird nämlich genau hingeschaut.

[#26]

Hallo Herr Hohmann,

... mir hat sich in einem Ihrer vorherigen Posts 'eingebrannt', dass Sie per Script quasi 'auf die Schnelle' eine PDF-Datei optimieren können (DPIs reduzieren, eingebettete Fonts entfernen etc.).

Gehört das zum Allgemeinwissen eines DigitalNaives ?

... oder anders gefragt:

könnten Sie hier ein Beispiel oder einen Link für ein solches Script posten ?

[#27]

> könnten Sie hier ein Beispiel oder einen Link für ein solches Script posten ?

Ich bin von Beruf eigentlich Softwareentwickler in den Bereichen Warenwirtschaft und Finanzbuchhaltung - und da muss man natürlich (oder sollte eigentlich immer) das Wissen haben den Kram so zu implementieren dass es der Gesetzgebung entspricht bzw. dem Prüfer plausibel machen kann warum man es so macht.

Also kein Wissen eines "Digital Natives" sondern schon Fachwissen.

Aber das Script (Linux Bash Shell) macht bei mir eigentlich nur folgendes:

gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dDetectDuplicateImages=true -dPDFSETTINGS=/ebook -sOutputFile="tmp.pdf" "$file"

"gs" ist Ghostscript - eine OpenSource Software (die es auch in einer kommerziellen Variante gibt) und defacto das Standard-Triebwerk fast sämtlicher (ausgenommen Adobe) PDF, PCL und PostScript Interpreter und Konvertierer ist.

Der Schalter "/ebook" komprimiert Bilder auf 150dpi und eine Fontersetzung findet nicht statt (kann man machen, aber ist in der Regel uninteressant - siehe meine Ausführungen weiter 'oben')

Am Ende prüft mein Script noch, welche Datei mehr Bytes hat (Orginal oder die Umwandlung) und schickt die kleinere an DATEV UO), denn manchmal erzeugt der Konverter eine grössere Datei.

Eigentlich nix was man nicht unter Windows in der Powershell genauso machen kann (da bin ich leider völlig Ahnungslos).

[#28]

Wer GS verwenden möchte und ein GUI für Windows sucht: 

https://www.noliturbare.com/convert/ghostfriend 

[#29]

Aber, aber Herr Kollege sebn - gestern haben Sie mir noch erklärt dass dieser OpenSource-Kram wie GhostScript nix taugt - wie können Sie es wagen, da eine Empfehlung auszusprechen.

Sinneswandel?

Gruss,

Ihr Bernd Hohmann

[#30]

Wie ich gestern schon schrieb - ich kenne die Problemstellen von GS & IM und würde sie daher bei mir nicht einsetzen.

Wenn es jemand anders tun möchte, kann er dies gerne tun - dort helfe ich auch gerne.

Hier noch eine Übersicht, was das "Device ebook" bei GS alles ändert: https://www.ghostscript.com/doc/9.23/VectorDevices.htm