Tk Library Source Code

file model.cnv is attached. Following sequence should 
reproduce file exactly but it introduces differences
(Problem exists under WinXP but not Linux)
Generally an extra CR seems to get inserted into the file
after a certain number of chars

Jasper Taylor@SPIROGRAPH /cygdrive/m/Documents and 
Settings/Jasper Taylor/My Documents/Tests
$ tclsh
% info patchlevel
8.4.0
% package require mime
1.3.2
% mime::initialize -canonical text/plain -file model.cnv
::mime::1
% set f [open model.mm1 w]
file8a4f20
% fconfigure $f -translation binary
% mime::copymessage ::mime::1 $f
% close $f
% set g [open model.cnv1 w]
file8a4f20
% fconfigure $g -translation binary
% mime::initialize -file model.mm1
::mime::2
% puts -nonewline $g [mime::getbody ::mime::2]
% close $g
% diff model.cnv model.cnv1
152c152,153
< $c create line 153.208211621 304.213304026 
153.208211621 304.213304026 -capsty
le round -tags {arc00103 startblob realwidth
(4.83329818985)} -width 4.8332981898
5
---
> $
> c create line 153.208211621 304.213304026 
153.208211621 304.213304026 -capstyl
e round -tags {arc00103 startblob realwidth
(4.83329818985)} -width 4.83329818985

229a231
>
child process exited abnormally

Logged In: YES 
user_id=75003

Fix committed to cvs head. Added a testcase to the testsuite
as well. Thanks Jasper, for the report, and your patience.

Logged In: YES 
user_id=75003

I believe I found it. In command 'copymessageaux', near the
end (lines 1637, and 1639), we have two puts commands. These
should use 'puts -nonewline'. The reason: We are reading the
input with read and convert it, so the output of the
conversion has to be written without newlines. The converter
is itself responsible for the insertion of newlines where it
sees fit.

This asymmetry of reading/writing caused the problem.

Logged In: YES 
user_id=75003

Arg. Got thrown off, the same data is a bit earlier than the
line in question. It is a 492, and in the output, i.e.
model.mm1. Ok, it is still copymessage to look at. Stopping
now, evening, obviously my mental capacity is going down.

Logged In: YES 
user_id=75003

Ok, I tried my hand now. I can confirm that the new
character comes in after 2^15-1 characters, and at the very
end. Trf has no influence on this either. The problem
happens with and without.

New finding: Base64 is no problem either. Looking at the
intermediate file model.mm1 I see that quoted-printable was
chosen.

Another new finding: When looking at the equivalent position
in model.mm1 (line 488, .cnv = line 152) I do _not_ see
additional newlines. In other words, the characters are
_not_ added during writing. This exonerates copymessage.
They have to come in during _reading_ and we have to look at
'getbody' instead.

Urrk. That looks like a complex state machine ... value,
canonicalP, encoding ... Ok, we know the latter one. ...
canonicalP as welll ... This seems to be in this while loop
going through the input in some chunks ... With and without
Trf, so mime::qp_decode is most likely not the culprit. I
will have to look deeper at this loop.

Logged In: YES 
user_id=75003

Will have a look.

Logged In: YES 
user_id=24077

andreas - i can't figure this one out. any ideas?

Logged In: YES 
user_id=456242

I tried this patch and the behaviour is still the same.
    --Jasper

File Added - 32747: diffs.txt

Logged In: YES 
user_id=24077

what's going on here, i think, is that in one case Trf's
base64 is being called and on the other system, Tcllib's
base64 is being called.

it appears to be that the routines aren't identical in the
sense that one has a "\n" at the end.  since the copymessage
routine chunks at 32766 octets, this explains why a "\n"
shows up in the file.

try the attached patch and see if it works

File Added - 32720: model.cnv