How to break lines?

[tbraendle]

Dear QR invoice community

Is there a best practice how to break the lines of the field "Rechnungsinformationen" next to the QR Code in the "Zahlteil"? E.g. would you break the lines exactly after 70 characters or before a new field starts (e.g. /32/)? If you break after 70 characters, a certain string could be taken apart...

Best regards Thomas

[gexclaude]

Dear Thomas

We have invested quite some time and testing in order to make sure, that all information fit into the QR Bills layout parts, even if every single SPC field is filled to the max. I won't go into every aspect of layouting logic we've implemented, that would be annoying and not a fun thing to write down neither. In my opinion, breaking at a specific number of characters is not a good thing to do. This would only properly work for monospaced fonts.

What we basically do is the following:

• break after/before words before max width of the layout part is hit
• if it takes more than a certain number of lines for a specific field (ie. 2 or 3 lines depending on the field length), break after any character as soon as the max widht of the layout part is hit
• measure the width a string takes when rendered with the specific font family & size in order to determine the breaking point - use intermediate strings to do so (of course, there are optimizations possible...)

You may have a look at how our solution behaves:

• https://rest.qr-invoice.cloud

Alternatively, you also find a Windows Demo Application on our page which is a bit more interactive for testing how the layouting behaves.

Hope it helps

Best regards Claude

[epsitec]

@tbraendle be aware that you may truncate the line and add an ellipsis ... anywhere as long as you don't hide personal information (paraphrasing the implementation guidelines).

Be aware that the so-called SWICO-String (//S1/...) is of use only to the bill recipient's software.

It is of no use to:

• The human recipient reading the QR-bill (same information should be provided in clear text in the invoice itself).
• The banking software (apart from the /40/0:30 indication which allows to derive the payment delay).
• The payment (this information does not get channeled back in the pain.001 file).

The team who defined the SWICO-string at SWICO did not intend it to be printed in the first place. It was the banks who voiced concerns with respect to data transparency and insisted that it should be printed on the bill.

Practically, it will not be a problem if you truncate the string early (or don't print it at all), as there should per se be no personal information in there, and I doubt that the Post Office employee will reject a printed bill where the SWICO-string is missing.

You could therefore print just ... or //S1/... and be done with it.

:smiley_cat:

[gexclaude]

@epsitec is referring to chapter 3.5.4 on page 16 of the implementation guidelines ( https://www.paymentstandards.ch/dam/downloads/ig-qr-bill-en.pdf).

This is where the content from the data elements «Ustrd» (Unstructured message) and «StrdBkginf» (Billing information) is shown. Both fields together can only contain a maximum of 140 characters. If both elements are filled in, then a line break can be introduced after the information in the first element «Ustrd» (Unstructured message). If there is insufficient space, the line break can be omitted (but this makes it more difficult to read). If not all the details contained in the QR code can be displayed, the shortened content must be marked with «...» at the end. It must be ensured that all personal data is displayed.

So I absolutely agree with @epsitec that this is a valid solution for the so-called SWICO-String (nice work btw).

My answer was a more general one regarding layouting. We made the design decision to print all information as text as long as it is possible. This has also some benefits, like there is no information "hidden" in the Swiss QR-Code only. Although I personally agree this not being an issue, some people do. And as we provide SDK and services for other software vendors and individual software systems, we were a bit more strict on this topic.