Patrick Ohly wrote:
> On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>>
>> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote:
>>
>> >>
>> >> Hi,
>> >> I hope you have not forgotten about this problem. Please look into my
>> >> last message and let me know if I can do something more. If it is the
>> >> same issue as the TDE/libkcal one, the fix should be really simple.
>> >
>> > There was a misunderstanding: I need you to re-run the sync as
>> > explained above (loglevel=4 as command line parameter), and *then* the
>> > resulting log html file will have more information. The one you sent
>> > doesn't include information about the detailed item conversion.
>> >
>>
>> Might be my bad - sorry.
>>
>> Here
>> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10',
>> localID='' remoteID='526'
>>
>>
DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82
>> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A=
>> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0
>> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A=
>>
>> Note ==0D=0A=
>>
>> It is also visible in syncevolution-log_trm002_003_incoming.xml
>
> Sorry, I'm still confused about what the actual, unmodified incoming
> data is. Can you attach the entire log file?
>
> I doubt that I will have time to fix this, but at least I should be able
> to reproduce it and point you into the right direction in the code.
>
Looking into the synthesis quoted-printable parser .... it's really a
brainf**k. I'm just wondering if I am the only one on this planet to have
such issues doing a sync with UTF-8 encoded text.
I was expecting to find something like the versit parser, which I think is
really nice in KDE3/TDE[1], but I found here something self written, not
based on grammar ... and giving me a lot of headache.
Very very sad story!
The diff is the closest I could get to make it work acceptable for me - it
at least does not mangles the text.
[1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit
I hope it helps come to some solution.
regards
--- syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa/src/synthesis/src/sysync/mimedirprofile.cpp 2016-09-20 13:47:49.000000000 +0200
+++ ../syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa/src/synthesis/src/sysync/mimedirprofile.cpp 2016-10-02 00:21:19.632479707 +0200
@@ -1939,6 +1939,7 @@
char hex[2];
s=nextunfolded(p,aMimeMode,true);
if (*s==0) break; // end of string
+ if (*s=='=') { p=s; continue; } // EKO workarround ==0D=0A=
hex[0]=*s; // first digit
s=nextunfolded(s,aMimeMode,true);
if (*s==0) break; // end of string
@@ -1947,12 +1948,14 @@
p=s; // continue with next char after second digit
c=code; // decoded char
if (c=='\x0D') {
- c='\n'; // convert to newline
+ //c='\n'; // convert to newline - EKO: this creates a lot of mess
+ p = nextunfolded(p,aMimeMode,true); // move forward
lastWasQPCR = true; // remember
+ continue; // EKO: start new iteration
}
- else if (c=='\x0A') {
+ if (c=='\x0A') {
if (lastWasQPCR) {
- // if last was CR, ignore LF (CR already has generated a newline)
+ // if last was CR, ignore LF (newline will be generated below)
p = nextunfolded(p,aMimeMode,true); // but skip it for now.
lastWasQPCR = false;
continue; // ignore LF
@@ -1960,8 +1963,8 @@
// LF not preceeded by CR is a newline
c='\n'; // convert to newline
}
- else {
- // neither CR nor LF
+ if (lastWasQPCR) {
+ c='\n'; // EKO: take care of CR on mac or similar
lastWasQPCR = false;
}
}
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
