Hi Barry,

Barry Warsaw <barry@python.org> to Michael Heydekamp on 24.01.04:

On Fri, 2004-01-23 at 07:54, Michael Heydekamp wrote:

...

as Mailman's qp routine seems to be completely broken I'd like to know how to prevent Mailman from qp'ing messages (for instance when sending out subscribeack.txt) at all.

...

I don't see the benefit of qp'ing anyway but wouldn't mind if Mailman would do it correctly. But that's not the case ...

Michael, can you please provide some detail?

Sure, but what about an answer to my question how to prevent qp'ing? ;-)

Reproducible examples would help.

Simple - say we have the following lines in subscribeack.txt (German text follows):

----------8<----------

1. Was Mailinglisten sind und wie man sie am besten und komfortabelsten in XP einrichtet und handhabt, ist ausführlich in der Online-Hilfe [...] ----------8<----------

When receiving the greeting message after subscribing to the list, the users see the following in their MUAs instead:

----------8<----------

1. Was Mailinglisten sind und wie man sie am besten und komfortabelsten in XP einrichtet und handhabt, ist ausführlich in der Online-Hilfe [...] ----------8<----------

Ugly, right?

There are two reasons for this:

1. Unnecessarily, Mailman wraps lines that are not longer than 76 characters (note that the line in question is just 71 characters long and therefore Mailman wouldn't even need to touch it).

2. When Mailman wraps, it simply "forgets" to use soft line breaks which would have to look like this:

----------8<----------

1. Was Mailinglisten sind und wie man sie am besten und = komfortabelsten in XP einrichtet und handhabt, ist ausf=FChrlich in der Online-Hilfe [...] ----------8<----------

Please note the "=" at the end of the first line. Only then every qp-aware MUA would be able to restore the original line.

The second reason is the more important one. Mailman may wrap even at pos 40 if it wants to but it *has* to use soft line breaks then. For more details see 6.7. of RFC2045.

Furthermore I'm not sure if Mailman calculates the line length correctly at all (would have to run another test to be sure). My impression is that characters are counted before being qp'd (because if they would be counted after being qp'd, also the line starting with "in XP einrichtet" should be wrapped, given that the same logic is applied to the line).

Anyway, I see no reason for qp'ing at all and to avoid the ugly output above, I'd like to get rid of it.

Just for demonstration purposes, I'm writing this last paragraph of the message in one long line and send it out qp'd. Look at the raw format to see how qp should work. You MUA should restore it to one long line (and afterwards internally wrap it again for display purposes).

    Michael

Hi Simone,

Simone Piunno <pioppo@ferrara.linux.it> to Michael Heydekamp on 25.01.04:

On Saturday 24 January 2004 23:07, Michael Heydekamp wrote:

...

Simple - say we have the following lines in subscribeack.txt (German text follows):

...

----------8<----------

1. Was Mailinglisten sind und wie man sie am besten und komfortabelsten in XP einrichtet und handhabt, ist ausführlich in der Online-Hilfe [...] ----------8<----------

Michael, what Mailman are you referring to?

2.1.3

There's no such text in the german translation for 2.1... neither in subscribeack.txt, nor anywhere else.

Of course not, this is a list specific subscribeack.txt that I created for each of our lists.

But what the heck :) has the (arbitrary) text itself to do with the fact that Mailman creates a technically wrong and therefore ugly qp'd output upon sending such texts? It would do so with the original subscribeack.txt in exactly the same manner.

Hey - anybody around who wouldn't mind to answer my original question? :) I'm asking questions and what I'm getting are more questions... I'm happy to answer them but at some stage an answer to my question would also be nice, so:

At this stage I just need to know how to prevent Mailman from qp'ing.

Simone, there is BTW still another open question in <91HicwPppwB@my.freexp.de> (how to make fuzzy translations non-fuzzy).

Well, there are even more open questions that I raised here, but as nobody came up with useful answers, I have almost solved these issues on INN or MTA level in the meantime.

    Michael

Hi Simone,

Simone Piunno <pioppo@ferrara.linux.it> to Michael Heydekamp on 25.01.04:

On Sunday 25 January 2004 15:45, Michael Heydekamp wrote:

...

...

There's no such text in the german translation for 2.1... neither in subscribeack.txt, nor anywhere else.

...

Of course not, this is a list specific subscribeack.txt that I created for each of our lists.

Ah ok, maybe we're getting closer to the solution...

Let's see...

...

But what the heck :) has the (arbitrary) text itself to do with the fact that Mailman creates a technically wrong and therefore ugly qp'd output upon sending such texts? It would do so with the original subscribeack.txt in exactly the same manner.

That text is not completely arbitrary: there's a little structure in those apparently flat files! The rationale is that, after variable interpolation, the text could become more ugly than you reported, because we don't know in advance how many chars will be used for each interpolation placeholder.

The text that I quoted did not contain any variables, Simone.

For this reason, after interpolation in Utils.maketext() the resulting string is filtered by Utils.wrap(), which basically reflows all not-indented paragraphs.

This *is* an indented paragraph (with a negative indention in the first line). Quite common thing...

And the wrapping is done at a fixed position of ...?

I also had cases where an empty line was inserted in the middle of a paragraph for no reason (for instance in the result of a 'help' request).

Probably you wrote your templates without taking care of these rules, and get ugly results.

Are these rules documented somewhere?

Anyway, when writing these texts, I was of course bearing in mind possible variable interpolation and made sure that lines with variables cannot exceed a reasonable line length.

If you want to completely disable the re-flowing logic, you should add a "raw=True" parameter to Utils.maketext() calls (e.g. at line 58 of Deliverer.py), or just change the defaults (at line 384 for Utils.py),

Ah, I'll try that. Thanks!

by I bet after some experimentation you'll prefer to rollback ;)

Never ever. :) I hate when software is messing up my carefully prepared text files without asking me.

...

Simone, there is BTW still another open question in <91HicwPppwB@my.freexp.de> (how to make fuzzy translations non-fuzzy).

You simply fix that translation string (if needed) and remove the fuzzy line.

But as I told you already in the message above:

----------8<----------

But as I said: Even if I remove the tag and recompile the file, the translation is still not used. What's wrong? ----------8<----------

I thought it might have to do with the fact that the English text additionally appears in line 17 of cmd_confirm.py, but I'm not sure what's this for?

I also don't know if the line numbers in the language file do have any effect (apart from being informational), but we can discuss this in the appropriate mailing list as soon as I have accomplished some Exim stuff here...

    Michael