Ränder zu EZ-Objekt auf 0 setzen / how to remove margins to qr-code object?

[FredyWenger]

Offenbar werden zum EZ-Objekt automatisch "Ränder" (links und rechts) generiert. Wie können diese entfernt werden? Was ich versucht habe: Dim EzAbschnitt As Bill = New Bill EzAbschnitt.Format.Language = Language.DE ' Sprache setzen! EzAbschnitt.Format.GraphicsFormat = GraphicsFormat.PNG ' Standard ist SVG ' Margins auf 0 setzen ' funktioniert so nicht - kein Unterschied EzAbschnitt.Format.MarginLeft = 0 EzAbschnitt.Format.MarginRight = 0 Sprache und Grafikformat funktionieren, bei den Margins sehe ich keinen Unterschied (Standard oder auf 0 setzen))

Besten Dank!

[manuelbl]

Vielen Dank für das Eröffnen eines separaten Issues. Noch besser wäre gewesen bei der .NET-Version der Library (anstatt der Java-Version). Der obige Code ist ja Visual Basic (.NET). Da die beiden Version in diesem Punkt gleich funktionieren, ist das aber kein grosses Problem.

Die Library geht davon aus, dass die QR-Rechnung relativ zum Blattrand positioniert wird. Dies ist durch den QR-Rechnungsstandard mehr oder weniger gegeben, insbesondere auch, wenn die gestrichelten Linien gedruckt werden sollen. Er geht unglücklicherweise auch davon aus, dass alle Drucker mit einem Rand von nur 5mm umgehen können.

Entsprechend sind die unterstützten Output-Formate definiert:

https://codecrete.net/SwissQRBill.NET/api/Codecrete.SwissQRBill.Generator.OutputSize.html

Alle Output-Formate (ausser wenn nur der QR-Code erstellt wrid), sind 210mm breit. Der Rand kann zwischen 5mm und 12mm eingestellt werden, beeinflusst aber nur den Abstand des Texts vom Rand, nicht die Grösse des Output-Formats. Werte unter 5mm werden auf 5mm erhöht:

https://codecrete.net/SwissQRBill.NET/api/Codecrete.SwissQRBill.Generator.BillFormat.html#Codecrete_SwissQRBill_Generator_BillFormat_MarginLeft

Können Sie mehr Kontext geben, wie sie genau die QR-Rechnung einsetzen möchten? Geht es darum, ein Dokument zu erstellen, in dem die QR-Rechnung ein Teil ist? Welche Software kommt dazu zum Einsatz? Und wieso ist eine QR-Rechnung ohne Rand nötig?

[FredyWenger]

Sorry #2 für nicht .net Version (ich dachte ich sei bei .net). Wenn Werte unter 5mm automatisch auf 5mm erhöht werden, ist klar dass es nicht funktioniert ;-) Zu Ihren Fragen: Wir haben eine VisualFoxpro-Applikation, welche wir mit QR-Code EZ erweitern möchten (wenn mit vertretbarem Aufwand machbar). Da VFP nur mit COM-DLL's umgehen kann, versuche ich die Generierung des QR-EZ einer COM-DLL zu kapseln, welche dann von VFP angesprochen werden kann (in einem VB.NET ,Forms-Client läuft bereits alles). In der VFP-App werden die Rechnungen in Form von Word-, bzw. RTF-Dokumenten gespeichert (damit die Kunden den Text zur Rechnung beliebig anpassen können). Die EZ-Grafik soll dann (als hex-string) im .rtf-Dokument einen Platzhalter ersetzen (das funktioniert in der .forms App bereits... Da Word (bzw. RTF) bereits einen Rand von ca. 7 mm hat, kommen die 5mm des QR-EZ noch hinzu, so dass links und rechts ein rel. (unnötig) grossen Rand entsteht. Obwohl ich damit leben kann, wäre es wohl sinnvoll, den 5mm "Zwangsrand" zu entfernen (auch 0 zulassen) bzw. nur zu setzen, wenn im API nicht explizit gesetzt.

[manuelbl]

Ich sehe den Anwendungsfall. Sinnvoll wäre dann aber ein neues Output-Format, das nicht 210mm breit ist, sondern nur 200mm oder sogar noch etwas schmaler.

Wie steht es mit dem Rand unten? Der sollte dann wohl auch weggelassen werden, oder?

Und wie sieht es mit den gestrichelten Linien aus? Verwenden Sie diese, lassen Sie sie weg oder erzeugen Sie sie auf eigene Weise?

[FredyWenger]

Neues Output-Format aus meiner Sicht nicht zwingend (wenn die margins auf 0 gesetzt werden könnten;-) Ja, der Rand unten sollte ebenfalls weggelassen oder auf 0 gesetzt werden können. Ich gehe davon aus, dass Sie mit "gestrichelten Linien" die vertikale Linie (mit dem Scheren-Symbol) meinen? Wenn ja -> ja, diese übernehme ich 1:1 (finde ich gut so). Hinweis/Frage: Ich habe vor kurzem einmal einen allgemeinen QR-EZ bei qrportal.ch generiert (ohne "Zahlbar durch" und Betrag). Da wurde oben (über Empfangsschein und Zahlteil) eine weiterer Linie mit Schere und dem Text "Vor der Einzahlung abzutrennen" generiert. Ich gehe mal davon aus, dass dies für Einzahlungen am Postschalter gedacht ist (bin aber nicht sicher -> kenne mich da nicht aus, da ich nie bei der Post einzahle ;-) Auf die Schnelle habe ich keinen Parameter gefunden, welche gesetzt werden kann, um das zu aktivieren/deaktivieren? => Auch habe ich kein Beispiel mit der "horizontalen Scherenlinie" auf der Wiki-Seite gefunden. Wenn meine Vermutung stimmt (für Posteinzahlungen soll der EZ-Teil abgetrennt werden) und ich nichts "übersehen" habe, wäre es vermutlich sinnvoll, das noch zusätzlich zu implementieren (mit Parameter generieren/nicht generieren)...

[manuelbl]

Die aktuellen Output-Formate haben eine fixe Breite von 210mm. Wenn man einfach den Rand auf 0 setzt, dann stimmen die Proportionen nicht mehr, die Rechnung muss skaliert werden und dann stimmen auch die Schriftgrössen und die Grösse des QR-Codes nicht mehr. Es wird also wahrscheinlich ein anderes Output-Format nötig sein.

Zu den Linien: Der Standard schreibt vor, dass QR-Rechnungen, die auf Papier versendet werden, perforiert sein müssen (horizontal, um die Rechnung abzutrennen, und vertikal, um den Empfangsschein abzutrennen). Wenn die Rechnung elektronisch versendet wird, kann man die horizontale und vertikale Linie aufdrucken, um den Rechnungs- und Empfangsteil mit der Schere abzuschneiden. Und ja, da geht es um die Kompatibilität mit dem Postschalter.

Ob das in der Praxis gut funktioniert, wage ich zu bezweifeln. Viele Drucker können die Rechnung gar nicht mit so wenig Rand ausdrucken. Und viele PDF-Viewer fügen einen zusätzlichen Rand hinzu, und verkleinern das ursprüngliche Dokument.

Diese Bibliothek kann natürlich auch die horizontale Linie erzeugen. Dazu muss ein Output-Format (bill.Format.OutputSize) gewählt werden, dass genügend gross ist, also entweder A4PortraitSheet oder QrBillExtraSpace.

https://codecrete.net/SwissQRBill.NET/api/Codecrete.SwissQRBill.Generator.OutputSize.html

Über den SeparatorType (bill.Format.SeparatorType) kann die Art der Linie gewählt werden.

https://codecrete.net/SwissQRBill.NET/api/Codecrete.SwissQRBill.Generator.SeparatorType.html

[FredyWenger]

Besten Dank für das ausführliche Feedback. Wenn die Proportionen verändert werden, wenn der Rand entfernt wird (warum ist das so?), haben Sie natürlich Recht, dann braucht es ein neues Output-Format... Das mit den Linien werden ich noch ausprobieren. Post: Ich verstehe das Gebaren der Post nicht und kann mir nicht vorstellen, dass viele Anbieter Ihre Rechnungen extra auf perforiertem Papier ausdrucken werden, wenn die Rechnungen mit der Post versandt werden, nur damit die Post es leichter hat. Das geht ja voll am Sinn / Zweck des QR-Codes vorbei - ich glaube, damit wird sich die Post abfinden müssen...

[FredyWenger]

Ich habe es mittlerweile geschafft, eine COM-DLL zu erstellen, welche aus Visual Foxpro angesprochen werden kann und SwissQRBill "kapselt". Fragen: Offenbar sind im QR-Standard nur 3 Adresszeilen für Kreditor und Debitor definiert (was mich sehr wundert...) Können Sie das so bestätigen (keine Möglichkeit eine vierte Zeile auszugeben)? Wenn die Grafik als Hex-String in ein .rtf eingefügt wird, kann eine Skalierung (X und Y) mitgegeben werden. Das funktioniert, der QR-Code kann danach problemlos gelesen werden und die Schrift auf dem Empfangsschein ist immer noch deutlich grösser als 6 Punkt (was offenbar als Minimum definiert ist). Aus meiner Sicht sollten die Proportionen weiterhin passen, wenn der gleiche Wert (Bsp. je 90%) zur Skalierung mitgegeben wird. Oder sind Sie anderer Meinung?

[manuelbl]

Ja, es nur 3 Adresszeilen vorgesehen.

Die Grafik zu skalieren, führt dazu, dass der QR Code nicht mehr die richtige Grösse hat und nicht mehr am richtigen Ort. Damit verletzt man den Standard. Ob das in der Praxis relevant, kann ich nicht sagen.

Auch die Schriftgrösse täuscht. Die Library verwendet automatisch eine kleinere Schriftart, wenn die Adresse lange Namen enthält.

Falls möglich, würde ich ein anderes Vorgehen vorschlagen. RTF unterstützt grundsätzlich auch das Zuschneiden (Crop) von Grafiken. Falls mit ihrer Software möglich ist, würde bei der Grafik links, unten und rechts je 5mm abschneiden. Wenn das noch nicht reicht, dann 7 oder 8mm und gleichzeitig den MarginLeft und MarginRight ebenfalls auf 7 oder 8mm. Damit ist eine Skalierung nicht mehr nötig und alle Texte und der QR Code befinden sich innerhalb der definierten Bereiche.

[FredyWenger]

Update: Ich konnte nun SwissQRBill voll in eine COM-DLL integrieren, welche dann von einer Visual Foxpro Applikation angesteuert wird (bereits produktiv im Einsatz). Der Funktion in der DLL können diverse Parameter übergeben werden (Daten zum Kreditor, Debitor, IBAN, Betrag und Zusatzinformationen, sowie Pfad mit Dateiname auf eine Word-Vorlage, Pfad mit Dateiname der zur speichernden .pdf-Datei, sowie Druckerangaben (Druckername und Schacht). Beim Aufruf wird dann die Word-Vorlage in eine RichText Editor (von DevExpress) geladen. Dann wird der QR-Code (auf Basis der Parameter) als Byte-Array im Speicher generiert und an einer klar definierten Stelle (Koordinaten) in das Word-Dokument eingefügt (unten bündig, ganze Breite). Dann wird das Dokument als .pdf gespeichert und auf den definierten Drucker/Schacht ausgedruckt. Der "Schlüssel" war der RichText Editor von Devexpress, mit welchem Word-Dokumente geladen und Grafiken direkt aus dem Speicher (Byte-Array) an einer beliebigen klar definierten Stelle in ein Word-Dokument eingefügt werden können. Somit konnte ich die QR-Grafik also auf der ganze Breite im Word-Dokument (bzw. ,pdf) einfügen = ohne Skalierung. Ich brauche also keine Anpassung und bedanke mich hiermit herzlich bei Ihnen für Ihre Arbeit!

Sonstiges: Sehr hilfreich/sinnvoll sind auch die Zusatzinformationen, welche (mindestens bei unseren Tests) 1:1 in das Telebanking durchgestellt wurden. Bei einer Post-Zahlung wird normalerweise nur "Schalterzahlung" angezeigt, mit dem neuen EZ übernehmen wir nun diverse Informationen (Kundennummern, Rechnungsnummer und Adresse), was dann auch bei einer Post-Zahlung sichtbar ist (ein echter Mehrwert).

Ich würden nur die default resolution auf 300 setzen (was ich gesehen habe, ist diese standardmässig auf 144 gesetzt = nicht so tolle Qualität). Vielen Dank also nochmals abschliessend...