#68 Width of address field (especially back address) with DIN-lang window envelope

[Ulrich Müller]

scrlttr2 sets the default toaddrhpos to 20 mm and toaddrwidth to 85 mm, therefore the back address can extend up to x position 105 mm.

Now the DIN-lang window envelope is 220 mm wide, and its window extends from x position 20 mm to 110 mm. Nothing guarantees that the 210 mm wide A4 sheet is centered; in the worst case it can shift entirely to the right, so the right edge of the address field will be at x position 10 mm + 105 mm = 115 mm, meaning that especially the rightmost 5 mm of the back address won't be readable. (This isn't a constructed example but I've seen it in practice.)

So I wonder if the toaddrwidth default shouldn't be changed to 80 mm, in order to ensure that the field fits in the envelope's window.

\documentclass{scrlttr2}
\setkomavar{backaddress}{Vereinsname e.~V.\\c/o Vorname Name\\
  Langestr.~123\\45678 Stadt}

\begin{document}
\begin{letter}{an}
\opening{hallo}
text
\closing{mfg}
\end{letter}
\end{document}

[Markus Kohm]

This discussion is as old as window envelopes. It concerns not only the width, but also the height. How often do I receive letters where the return address cannot be read at all because the letter is slightly shifted upwards?

Let's remember what the return address is for: if a letter cannot be delivered, it is needed to return the letter to the sender. In this case, the post office is perfectly capable of moving the letter in the envelope if necessary by knocking on it - most of the time.

There are standards for the position and size of the address field, including the return address. Where available, these were used when designing the lco files. For compatibility and effort reasons, the lco files are also changed as few times as possible. At the same time, I always emphasize that the lco files supplied are only to be understood as templates. I expressly encourage you to create your own customized lco files. In the book, I therefore devote a separate, very detailed chapter in the appendix to this topic. There are also two examples in the wiki.

Incidentally, I once took the time to measure the windows on different envelopes and found that there were significant deviations. A solution that is always correct would probably have to be based on the smallest known window and in most cases would be smaller than necessary.

Incidentally, reducing the width would not really change the default style for the return address: The return address is not automatically wrapped. It would therefore simply exceed the set width. And if you define your own style with automatic wrapping, you can of course also redefine the width.

And before I come to a final answer, I would also like to point out toaddrindent. This makes it quite easy to achieve the desired " margin" with regard to the address field.

The final categorical answer is therefore: No. The supplied lco files should not be changed in this respect.

[Ulrich Müller]

Sorry if this is a duplicate; I had checked the existing tickets and didn't find any previous report.

I don't have DIN 678-1 and DIN 680 here, but they are often quoted so I'm pretty certain that the dimensions I mentioned in my original report (width of DL envelope 220 mm, window ends at 110 mm) are the ones specified by the standard.

IMHO having an address field that is too wide even for the perfect case specified by the standard (without considering any additional tolerances) makes little sense.

the post office is perfectly capable of moving the letter in the envelope if necessary by knocking on it

This isn't a particularly helpful argument in the age of automatic scanning services.

[Markus Kohm]

Not every discussion is done in the issue tracker. This year KOMA-Script is more than 30 years old. Meanwhile support was available via two different WWW sites, several third party internet forums, usenet, mailinglists, and unfortunately most users still don't use the tracker but email. But there is indeed already a LCO back address discussion in the tracker with a similar conclusion.

BTW:
- Automatic scanning AFAIK only uses the PLZ not the name of the city.
- If the automatic scanning fails a manual correction is tried.

And please note all the other arguments I've given. And please respect, that this is my decision, as long as I'm more or less the only developer doing all the support, communicating all the changes, doing all the documentation, making all the needed changes to keep KOMA-Script functional with all the LaTeX kernel changes and changes of several relevant packages, and doing all the discussions about opinions like yours.

Maybe you should just write longer letters. Five sheets of paper seldom moves inside the envelope … ;-)

Sorry, but if there isn't any real new argument, my decision is established. I will not change this length after 22 years of having it! But feel free to write your own DINimproved.lco and use it. You are welcome to distribute it as a new CTAN package and do all the support for it and manage all the (partly conflicting) “I would like to have … changed” requests and all the changes needed, when I change something in scrlttr2 or scrletter. Maybe you are much better in doing so than me. Maybe you can even do all the adaptions to new versions of DIN (AFAIK the norms are audited every 2 years) and also if a new DIN or ISO number refers to letters. Something I've missed out on all these years.

[Ulrich Müller]

Of course, I understand and respect that it is your decision.
Thank you for your ongoing support and dedication to KOMA-Script.