FpdfOutput: Positioning problems with long address lines
merlincom opened this issue · 9 comments
Without specifying the customer, in the Fpdf output in the left section, the bottom edge of the rectangle for the field 'Payable by (name/address) with the text Currency and Amount are touching.
Ohne Angabe des Debitors berühren sich beim Fpdf-Output im linken Abschnitt der untere Rand des Rechtecks für das Feld 'Zahlbar durch (Name/Adresse) mit dem Text Währung und Betrag.
Thank you for reporting!
Can you provide a reproducable code example for this behaviour? Maybe based on one of the examples in this library.
The test pdf within this library looks good:
Oh, I see! Your address on top left has a line more (but not on top right). It must have to do with long address lines.
It must have to do with long address lines
Your guess is correct. I have just tested it. The long line( max 72 characters are acepted ) with automatic wrap make the problem
With only one line without wrap everything is ok: 01-09-_2022_18-37-58.pdf
// Add creditor information // Who will receive the payment and to which bank account? $qrBill->setCreditor( QrBill\DataGroup\Element\CombinedAddress::create( substr( trim( $_POST['qrForm-kreditor-fullname'] ), 0, 72 ), trim( $_POST['qrForm-kreditor-strasse'].' '.$_POST['qrForm-kreditor-hausnummer'] ), trim( $_POST['qrForm-kreditor-plz'].' '.$_POST['qrForm-kreditor-ort'] ), trim( $_POST['qrForm-kreditor-land'] ) ) );
Your guess is correct. I have just tested it. The long line( max 72 characters are acepted ) with automatic wrap make the problem
the specification allows a maximum of 70 characters for creditor and debtor names, not 72 😉
see https://www.paymentstandards.ch/dam/downloads/ig-qr-bill-de.pdf
As a first step, I created test data in #190 to document the current wrong behaviour.
the specification allows a maximum of 70 characters for creditor and debtor names, not 72
Thanks for the hint. But even with 70 characters length the small graphical problem shows up. The cause is probably the line break with long creditor information (see screenshot).
As already said, it is only a rather insignificant graphical problem with the PDF output. This only occurs if no customer is specified AND the vendor contains so many characters (max. 70) that the line is (automatically) wrapped. Then the lower edge of the rectangle for the field 'Payable by (name/address) with the text Currency and Amount touch each other in the left section of the Fpdf output.
https://github.com/sprain/php-swiss-qr-bill/files/9471448/01-09-_2022_17-53-24.pdf
The solution is probably to set the x and y coordinates in the fpdf output absolute (and not relative to the position of the last line).
Danke für den Hinweis. Aber auch mit 70 Zeichen Länge zeigt sich das kleine grafische Problem. Ursache ist vermutlich der Zeilenumbruch bei langen Kreditorangaben (siehe Screenshot).
Wie schon gesagt handelt es sich lediglich um ein eher unerhebliches grafisches Problem beim PDF-Output. Dieses entsteht erst, wenn kein Debitor angegeben wird UND der Kreditor so viele Zeichen (max. 70) enthält, dass die Zeile (automatische) umgebrochen wird. Dann berühren sich beim Fpdf-Output im linken Abschnitt der untere Rand des Rechtecks für das Feld 'Zahlbar durch (Name/Adresse) mit dem Text Währung und Betrag.
Die Lösung besteht vermutlich darin, beim fpdf-Output die x- und y-Koordinaten absolut zu setzen (und nicht relativ zur Position der letzten Zeile).
I did some research and from the specifications it's not obvious how to fix this issue.
-
Other generators have the same problem … (Example)
-
…or they "handle" it by cutting off long address lines (Example)
-
The style guide shows no example of a qr bill with reference number but unknown debtor (see starting at page 18).
-
The style guide does hint that the information section on the receipt does not necessarily need to be 56mm high, as a beige number stands for «variations are possible».(see here).However, there are again no examples with such variance. Also, some beige numbers seem to make no sense (see width of qr code: mandatory 46mm + mandatory 5mm equal 51 mm with (impossible) allowed variation), so it's unclear how to understand them.
There is, however, one way that might make the most sense:
- The Raiffeisen generator omits the street in the receipt if the address becomes too long (Example).
In my opinion, since they are a bank, this would be the way to go.
What do you think, @kohlerdominik?
Hi all
I did some tests with the QRbill-Generators from Post and Raiffeisen. Unfortunatelly, the Post one doesn't support Reference Number, and with the validator in place it can't be tricked into overlapping.
Omitting the street name in the receipt seems very reasonable to me. Where it's required (QR-code and payment part), it's still there. The receipt is somewhat of a leftover anyway, IMO. Imagine the amount of paper and toner saved, if it was only printed on request. Really, why is paying at the Post office even a thing in 2022 :)
Because it's only the receipt, I would make suggest to resolve it by simply counting characters of Name and Street, and if both of them are more than 40 characters, they are most likely displayed in 4 rows. Therefore, omit the street. There might be hard to catch edge cases, though.
Also, I never testet the validator; does it enforce the max characters limits? It's probably important especially for the QR-code.
Wow, thank you for the late night response!
So I think we can agree on omitting the street when necessary. I will take care of this.
I never testet the validator; does it enforce the max characters limits? It's probably important especially for the QR-code.
Character limits are already enforced by this library – see this test for example. I do not know if the official validator enforces them, but honestly don't care. They are in the specs and we have taken care of them :)