(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.1.61 (KDE 1.92 Beta >= 20000720) Severity: normal Hi! I should have received pictures send by an Macintosh. it starts with a sequence like this --------------D91D5CC97C0115A5122764CA Content-Type: image/jpeg Content-ID: <part1.397D2D84.AAFDA27F@wanadoo.fr> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="/Disque%20dur%201/%83l%8Ements%20temporaires/nsmail3.jpg" /9j/4AAQSkZJRgABAQEASABIAAD//gAoRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hv cKggNC4wAA3/2wBDABcQERQRDhcUEhQaGBcbIjklIh8fIkYyNSk5UkhXVVFIUE5bZoNvW2F8 Yk5QcptzfIeLkpSSWG2grJ+OqoOPko3/2wBDARgaGiIeIkMlJUONXlBejY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY...... sniü but it is not displayed (plain text and html) when I open the file(s) with konqueror I get 3 empty areas for the 3 pics but the pictures are not decoded the pics are displayed as code should this work ? cu ferdinand
Hi I really need a raw message to work on this problem. If possible please send a raw message that reproduces the problem. <q> Hi! I should have received pictures send by an Macintosh. it starts with a sequence like this --------------D91D5CC97C0115A5122764CA Content-Type: image/jpeg Content-ID: <part1.397D2D84.AAFDA27F@wanadoo.fr> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="/Disque%20dur%201/%83l%8Ements%20temporaires/nsmail3.jpg" </q>
--------------Boundary-00=_Q92XYDXEYFQ38Q686ADN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi I attached a message that reproduces the problem but I would consider the= =20 decoding as feature and not necessarily as bug. Or should that already work? Regards Michael H=E4ckel =00 --------------Boundary-00=_Q92XYDXEYFQ38Q686ADN Content-Type: message/rfc822; name="inlineAttachment" Content-Transfer-Encoding: 7bit Content-Description: Mail with inline attachment Content-Disposition: attachment; filename="inlineAttachment" From - Sat Aug 26 22:10:30 2000 X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 Message-ID: <39A82329.5FF43731@Haeckel.Net> Date: Sat 26 Aug 2000 22:06:02 +0200 From: Michael Haeckel <Michael@Haeckel.Net> Organization: Universitaet Bayreuth X-Mailer: Mozilla 4.74 [de] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: michael@michael.de Subject: Inline attachments Content-Type: multipart/related; boundary="------------77434D01A37F51DCC924EE6B" --------------77434D01A37F51DCC924EE6B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> This is above the image <br><img SRC="cid:part1.39A82329.6E0F0D36@Haeckel.Net" height=174 width=100> <br>This text is below the image</html> --------------77434D01A37F51DCC924EE6B Content-Type: image/jpeg Content-ID: <part1.39A82329.6E0F0D36@Haeckel.Net> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="/tmp/nsmail39A8232A00304E6.jpeg" /9j/4AAQSkZJRgABAQEBLAEsAAD//gAXQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q/9sAQwAEAgMD AwIEAwMDBAQEBAUJBgUFBQULCAgGCQ0LDQ0NCwwMDhAUEQ4PEw8MDBIYEhMVFhcXFw4RGRsZ FhoUFhcW/9sAQwEEBAQFBQUKBgYKFg8MDxYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYW FhYWFhYWFhYWFhYWFhYWFhYWFhYW/8AAEQgArgBkAwEiAAIRAQMRAf/EAB0AAAEEAwEBAAAA AAAAAAAAAAcEBQYIAAMJAgH/xABOEAABAwMDAgMEBAgKBQ0AAAABAgMEBQYRABIhBzETIkEI FFFhFTJCcRYXI1JigZHSCSQlY3Oho7PB1ENyk7GyJiczNDZTdHWCg4WV0//EABoBAAMBAQEB AAAAAAAAAAAAAAMEBQIBBgD/xAA2EQABAgUDAgQFAgQHAAAAAAABAgMABBEhMQUSQVFhE3GB kRQiMqHwBrFCwdHhI0NSYnKy8f/aAAwDAQACEQMRAD8AuzbdKptvUGJSqZHahwKfHSyy0gYS 22kAAfsGkca6XZrKZNMtqsTYjnLMpvwG0PJ/OSHHUq2n0JSMjkcEHTV1DuYQ7ot2zWmWlSbq XIbK3kFTbbLTJW4SkEZJylIGR9Yn0wWdzqPJiQ7opCYkc1a2J7EBJQgpZdS82hbTm3ORhKzl OeSg4IyMSHXEttlxZsBX2gyElbgQnJtEtcuGqISSLLraj8A9D/8A31qbuWrqAzY1dSfm9C/z GqldTeq162D1zp9Sh1qVNakwEKnw5TpLMr8ovPk7IOAACkDH3ZBuDbNUarVAg1eOFIanxW5D aVDkJWkKAPzwdLSU43NtB1GDDc1JOyytq4TLuGrBPFj10+nD0P8AzGtSrjq+Rmx68n5l6F/m NSME4GSe2tDy8Ac6ahUCIH1H6mMWVasu4rjtetxKdDSC68XIiuSQkJAD+SSSAAB66F0f2yOm 7jRW3QLpKB9r3NnH97offwh/UqDXLhpvTimzEORYEj3irKQvKS9ghDXHfaCokfEj1B0CX6pH bozjcGK2lpCihAcHHPGTjv8AD07aTfmVIUEoTWGWmkqBKlUAi6Nh+1XYF13IxQadSq41OlHb HRLTGZS6r0SFqeCdx9Bnn00V2Lmq+0EWNXD9z8L/ADGuVbig3PLzzqglOCHEjYpKs8EY7EHn GfTV6PYV65TeoVLVadyL8Su0yKHETE8iY0CASrAwFgqSP0u/x00hwKHeFK1OYPUe46upPNj1 0fe/C/zGl9BrzFRnOwHocunT2UBxUSWlIWUE4C0qQpSFDPB2qOOM4yNLIh8g+WhlO6jOv2xe F+QoURUeyZsyAGnGcvSW2NhkYcz5NykkJGCPIknOcAlYyq0TG6bUgVaqe+OPSGVqQEq8F0oC iPUgdzjAz8hrNPFNmsVCmxp8clTMplDzZIwSlQBH9R1muVUOY3EB64fR1Joce95DajOth0vw Fpx9Z0eCptWfsKC8H4YBHI1F6m1SJnSFN60/et+7psOpynnUhCiVIQhCMAkJCUBKQMnsTkkk mRe0xZ0e9ujVXo8mY7FDbPvSXUPFtKVN+bK8JUVIGMlO0k44wcEU46qX3X7Yt6Z0WpsrxLeo 0tUdLs5G+U+pt3cSk9tu4cJAGE45PfQJhnxm1NKVQKFMY6n+0CVNplFpdKa0Nc5PT7Zjx7Vq 0fjJpqgtJ/k4Zwf5xert9GXd3Sa11A5zRYh+/wDIp1y3u9bsyro8UYKUHCUNgK7nuO39erY+ wz12uivXTTOnFaiw5MBqn+BCkx2yhbAZaG0LOcKylJHYHOOdCkdPTJtBtK9wAzSnXuf3hl/X Uz5TuRtJJOa59B0i2lx1in0Kgy6xVZSI0KCyp6Q8s8IQkZJP7NUI9oH2p+oF012RAs+U7QqE 5lDIYSBJeR2C1ud0k98Ixjtk99Gj+Eouy4aB04pdLp/5Oj1t51ipupQCVFISptvJ7A+ZXHJ2 fDOaVwwJbragSlLLQ8xGBjPr8OToq1kX4jCrnaDeNJI3KkvPNPSio7i48tSs+uU4/wAdGvoz 0Wl1YJq95uuRoISCxEQShbuQCDnGEpwR25J+GNQ/2fLat266/VW60hwGGnew4CQ2ncT5nFAY AHHfA5+7Vpqa9EW0ukvkJUjcqOUrG11nOUlB9duQkj0wPQjKU0taBQC/5iLGjyTUwre6QUjg de8Rep0GgWTGptNta32JSaio+9oU2XVLaSBvClq4HBOMnkgDHORnsodL6jZPtWz1OpmxIztK +kGWWkgNBLyU5ZdCT5dilLABHdsHUu6M2bXK7VGqkE+7UFh5tKg9MU8X1su5JaySdp2lJ3bT zkZ1YaHGisy3ZDcdpDz+PFcSkBTmBgZPc4HGjSbakjcrJjGpuNLWENfSMWx2/OsOkTIwPloS 3s1a9Lvw9M3UyW4HUSQ7KqDbaRt8VSDvSFZBSHQwrdgEgk4I3ZBZjHQS6pdGk3P7VFuXkq56 lARFj+8hluQSVOMLQA20MeRBCiVnPO7gckhw1JFDElZoMVg4ttNMMoZaQlDbaQlCUjASBwAB rNenOCBjPGs18TH0RjqTx06r6ieBS5Bz/wC0rQI9qn2cJt51Fd52S4yiqSmU+/095QQiWoJA CkL+yrAwRwD3yDnJ36lp3dN7gTnvSpPb+iVpTd9a/ByyJFaTTJ9SMSOFJhwGC6+8eAEpSOTy f1DJ9NaOIC80h0FK8Rzck9EOp9Sv/wDBFi01JqbEX3p1h2S0lttpSikL3FeCM8cE/do19P6b Z3swoVLueaiu3zU4+0x4y8NQGO5TvI8oOMlRGTgcAZJLVkM3JS6XeXWm+4jVFqdQp+2BTnFb vcIzSSW0r9d61bSU9844BOBUXq9RKjU3Wbhlz5MyoVshxRdOQlBfU1uPzK2nPkEqAAGln5nw 6JxXnpen84f0bRUupU8lJVtwOTZSvSyT7iCl1563sdVOnDlswrfYbZkqbcW4p4PlOCFIzlKS 3nnzYPAPbOhn7PFBodUv5+16m2h1moI3xVrSQUOJBISrOCptaeR6ZSOxOoDDXJjqq7UJ12M4 215VoOFJ2OpA5+IHGdSqzq3Gptxw65gtrpM1hwpSyc8eZIChxhXHw+t8Oyrb7rT+9R3Dp7ce tu8VnpSTmWElA8M3uTaoUsWJvhNTXAJzFkKX0dgWsiTUYHujLi073ktJ8HxEjJ25HbH7Mnnt qD0JHS9rqKlVcuKnmVHbd8N5+eyEJKsJwfDISF8q5PfAIxkgQvqZ1CrXUGaJFRqq4tO3qLVP iyEhltIWAkq/7xW0k5Pr2A03WpaIktrqAkuR4jDQdfWlaEnbzuA7ZwdpyeAO57aPMa0yg1pY elYCj9NTKGfEKkgEdanr7xYGuPsWvZBV09u1C61IW2imuR3mlhxO4BSXABsWkJzgqHHAB7DU v6G9UKxUq/ApF31SC5MlxiyW2WPCKJCCO4Jz5xu74BwnCRnVVrjvGm0yE9SbWwmCHg4mW40P HWsJxuSrGQSc+Y88gAAajnTi9pdArSVS1OqjS3w5L8E7nGyF5SpJ79gAcc8AjlIzpxjVHkib 27QLhH8ShzXpmwzaJjc3pzSvhiqt6Ff8KTxfnFzgVjqDHWMY001UZ6l0FR7iFNx+1jQn6I9a UVWJCg1xpcgvJaSipRRvaytewJd7YUDjOPjkgY0Vamr/AJx7ePPMSYP7nW2Jht9O5B8+3Yx8 +yto0WP7+USV7G4ZJHHprNfH87xj4fDWaITeBRHOoGPxfVvJz/JcjP8Aslae4Ct1OYUfVpJ/ q0y9Qjs6fVw9wKZIP9krWdPbhg3FbTMmIVIWwAzIYWfOysAcH9WCD6gg6LtJTWMVG+kQv2wW JL3QKtOR0LcEYsyHW0DlTaHkKV+oAFX6tU86rNzaLQrHjRV+/U+oQjUIkgJHi7FbVPRlY77H gpQ/1z2yddBLigMVahTKXKSFMzI62HEkcFKklJH7Dqg3tJ2BUOn9Eo1NrdzKk1hbKk0+FAUo ogs+MorUVKx5SFkDjJUT6J5QmGN6jQZFPz9/SLkhqiJNkKcVRKFbrZNuD6Uv1gXVRbceq3Kt IG1cJS2ufrbgklQ+WVDnSCJOaW9AKM+I7BaDm4cbk5HPxBAH7NNdwRnAW1EkPjDSFyHwvKSc Dv2A/wATqSWFZ1Vq3UiVQriaNPcpUzwagoDalog7UoTjjKjwPlk8jQyylhsuuGwF/QAfneJ8 5rKdUZWzKoIKlGmLVWV1rxStPKsP1jWizVIgr1WYMajxSlLzjeEhad2TtySTjkE8n0Tz2R3v ebk1LdLaZTHp8FIZYS0ylBcRnIUvb8x9XPGM8nnSnqhd8WSoU2ktMtMw20MJEZClNOqRkA47 4GSB64OfXAi1AgzJG6XKgr8Ja/CUwW1AvFRA2pSU5PmKVAjsfv4YlWEsITOzN3K1Sj/SO/8A u/b9lUNF5ZlGjsbpRblCNx7UH0+Va3p30xlyX2ZDq04U0g+GB83Ajd8sJ38+mM+mnKkx0Q2G 24jKXpT43qecHH3gfmjtnt8CTxpSl+HGLVPlSUlJkb1gtbg2eUgqO7zqO45SPKMHnO7CdmJ4 oVJmNyJRewpaErXyoDsoYAIHbHb5arabqDzs4rcKA3rc0GKYNPOnNs1js/pckNLQWjVSKjaS EhRJruuRX/iDgCp+WhnnSOW3TqzIhOuyJCqg2FNlEkNBb6NwIz2HkWs4/Q/bdXp5djN11K06 gh1tb4jTGpYbOQl1KWskfokEKHyUNc+Uu1BERAZpiGAlaTHDTuxSVA+UpG3Oc+mP26s17Gb1 Y/GrTkVtCY8l2luuBhpY8IJAQBhI9Rnn0G7A78qawyiW1QOtn5XhcGoIIGaHgjnrmB6MpT+m qacHzMnIoUkE4qKgEHjpjmLduYKuSe2s1rkK2qA5PHprNCJvBKRHOowJ6c15I+saVIH9krVW OinUSuWxcRhT0uiqQCWZcV47VTmU5y2c/wClRypKj3HyKibUdRM/i8rqs4/kuQR/slaDvtU9 Jna/bcW/LWYWK9T4rapTLA881pKQQpOO7qO49SBt5O3FXT32klTTw+VVL9M/br78ROnm3TRx o3Tx1H9ekGm3q5Tq/QY9ZpUpL0WQjclXbHoQoehByCD2II1Sb25JUio9fJv5NbzcCE0y2pCC oJSG/FVyPh4hJ+Wt9hdSKpDs2t05aX5ECqsLakoZXsS28pIDbyDgjKjtSpABKh9k8AtLVj3m 7TZNWcgpDCwCiM65seWjYnKik8JBwcp+IPBHJias4ZWYLTdFbc3+x7xRlZA6pKAqqmvbpz5Q Gfo9dyXPBt+INy315cUBkMtjzLcPwCUJUo/IaM3XS6vdZFReZachVKvH+NNBCBlkJSlByOSr akIzn0WeMjSnp5bjtPt78OHYsKEq4WzGhmYrw3JTCfDUtSlfZTlttAAHmCl+hBIkr9R+mrue lNJJRuxFYyVeG2nhGfkE4HcZPqOTr6Sa+Om0JdFENjcoZqo/SO+K05xCimjpkmpDKqrWdoOK AfUanGaVrbMNFOpD8h3c8htlLg8kdrjy/nLV9kfP/fp6gqprDSGIjCJhB2OyAkNgpAJKG8Dt wRnHPz5I3+4uGItJWkrVzhXKSfzlfnEfDsPQDvpOyyBU49NiocWGSHFYBW48s9gAOSfU8Y51 6Gf0dyYAdfV4aBgVv5k4HWgsKcmO6T+oZXTkKlZZHirWPmVS2MIGT03H5iTbaM6GAswgwELD T25xpKTnYoHGAcZPlyCDnIBx8NOlrQnZLiGYOH3XyBkKCUHPZS/RJwD25ODgHsFT0OFRoBkV 6e3Tmm5PMRSsyXAVblbQAcDCsDGe/dOmq57snppIi2rEMOml4vpB2qkg4A4OPL65wSrJOVHJ 1PTqTUpVGljco5WfpB5I5Uft968nErm0tq1hWxCfpQn6iOAeEi2Tftihj6M9Mqtc1XbFNYCp DLjjU+ZKazGipII2pIP1sHO1J3H7RSkg6sr0+sGhWFd9uw6YhTsl6NKEma9guvlKW8D4JSMn CRgDJ9SSYb7GvWS3b2tWJba48OkVqCzs9yYbDTMhKe62k+h9SjuOTyOxerCU/jGtpXGQ1M/4 EaRQwQ4XXVFTisqOfToO0PmabcZS2wkJbGEjjz6nqYlbxVuGFJ7eus15k8LH3eus105jMMd/ p3WHWk9/5NkD+zVobdeq5Mcp9Kp1sdRaFQ6jCbzKjyam2ytKylCkKWgnKkhIVlJ4IUDg4GiX f4P4CVrZ3+jX8ff4atB72mulk2qUdq9bZp4nVBiEgToKDtXJSlAAcQcHKwkY24OQBjkYVia8 TwTsFTbmkbly2HauGg8q/aAxW4023q1UpVs+5XLXpLqTGXEUyuAiS8rc6+hKCOQlQHoQBnCU qIDBH6m3XErL1udQzBiLmwVJgSIwCGnlnckFwknAVjg+XHqORqF0O+q9Sas4GKgtlxR2riuK /JupHYFKdufTOME450wdZLrqtyiI3UUMK8NwLKkJKSpQTtHyA+QwOE+oyQNS9TtcSKHnkRhH 6haSP8FagoYBFiPT+tsRav2kKvbNfjU2NSbrtp+HGhux5BRU4xXGSoJBUgKWPN5RgjOMdudV 0cpts0FoBy5YzSFPq8dSWS8sJGcLKkk7ieOB2zpmZt+qVCgOuOfxNllLYfekKAWM47IJByQc +baMdidKnKNbqXZTaTLq7qNqWpC1lhpKgMny4yfTHCh89ali+ZlRkVr3KzsAPuSKDPWALWp2 XSdQZQlArTeSD6AXOKYhPJuO1WWmvDkVCqPmRy0jDLTjeTgZ8qwTx8f16+x6hdE6OI9v0L3K M5OD22LGL7qMfzm30xwcZ576d1zGowkKiUqjwm3mgg7YvLYGeQrI555OllkXLOqd4IjNMsMs GOUrmMQ1FbO0EhaElRyd2AVEevfR9QktRabMxOoKgL/MsE+iRb2jEnMyTq/Ak3ggm1UNkV81 G/vEKvmhVeLBVVqtRqkplpW55x9tafEUSEp3uK9MkZPfsBjORN7a6bs1K1o9Sp9dQGnWSttb yMNqAwCSSQUJCsg53KzxjjJstf0iFUrCtG1ahKbnT5LXv0iG+5vWuP4DiQXc5OMuITk9z8cH QQmdHoFshl6o3vOaoxlJWulMoVl8hRU203hZJOfkT3PHfS7j7aRt3FNPX0pxFCT0PczVxAdS ScmhBteuSPzmGS0On9fpVcFUZiSnX2nN0d6D4oQFpCVJcDiduDggjHPpjPGrf9Gbmql1P20/ XoL8aqQ0SmZBdYU0HvI3hxIIHfPIHqD6Y0CelDt3XBXZlq21XmLckRnxN+iWnFNe+NqUdyUv II87aS2CBxye+3OrPQGJ8S5rQi1SUmTPbp0hEp5KcB1wIa3KHbuc+g767LJd3laiaEAiuL8j 8uI44zLsNeCyANqiDmtup+3alLRMJo/KjzEeX46zWTgkujcMnb/jrNHVmBAw2XmkrsuqoGMq gPDn+jOnGnEKo8VXABZSePu02XirFmVVfwp7x/szqtvWLrTUalbzNLpb8ii0JUYsiWgESZq0 pxjAIU2gnskeZQHJSMg5mJhDIFbk4AyT2Ebl5Zb6ztsAKkmwA6k8REvbis2yLhvAT7Lf21pl 4ite6M7oo/SKh/ps90pz8VbTyRCr6Ft5xyLCUiozmUpW1U3N3kSnBVsA4JyMeX0Iyo6W3HWk THRuSzCYLSWgykhHiJTz5sHHc52jgfPAOopUJDwmhTjaikKA2p5zngFBHx7YP2sfPVBGjOJY +J1I0SP8sH/sevQCg68wgJ2XXOCW0tNVmtXSMZqUg4HU3PI4hwrFUflTnn33S+840lxt4kc5 JB2gcDCQOw0iakbZLcGClTiWh4jm08uKPOVK+ynOSSe/pnOvMOPEV4wO51pKA2JKTsbYSSRn BP1lAlOO3CjjnI8XFUTTlKhRmG46UnzIUQtazjhS8HJ4wQOeO/wG29dWl1LEq2EJIAHQC5wK drGmBWgMUE/pmTXLuvzjxcWgncAfmWbCxNbA1+YVFzt3ER7qroS2FSVh1fdDYBCSfkPh8zyf TA7kT2f6MIsJ246tIegsv7x78lSUoZYb8zqlfFOAcAd/CIHcaGvTqjP3Jcjbcl+RtKgqTLWn yMIJCeAOyiTgcdzzwNEHqzWqE90OqLdDkMe9Rq/Fo1QaihQQGktLWFJyclKltISD/NH4nQdZ mkvKTJNHcTRSyb2BsDxc8CwHnEyQQtBXOupCEoqEJFgDS9OTQZJuTk2hGm8GrsuNy4kVCUxU 3HFJbcW4GS0hKAShvnCW0pBAyc8dsknRE6HWFWL2u1FTrMadVKa86thyaZJBZSplHKFjONuQ SknBIxzlQ0AKftRAbCQNu3tjV8PYhpZp/s+0p1aSg1B16UElOMJUshJ+4pSk/r1KRIgOlzca dPWDSGuOzILBQBTke3v3gB9QrGuTp9fCptPeVHqFJWmVGfYTjxWxwHkD7shaOftA5H1rF9Ge o9O6j1K2ai2EMVSI1KZqcMHllzYg7k+pQrGUn7x3B1NOpVmxLvoSWCoMVCKfEgywnJZX8D8U KxhSfX7wCAf7P1nu2x7TyHDHEXxKfKafinvHdBbJA+KD9ZJ+B44xr1Djzc5LVXZxA9x+e3rC CWXJWYoi6FG/Y9fzMWXn5LwKT9nWa8VVYRIAPqn/ABOs159RvFcCG+9Ug2TWMg809/8Au1ao n1ZsKoU0lcxiR41ObK1sMKcDaWSEqLiVA4yQrd8wOwKcavdeQ/5FVcds094f2atC72hbdbet CgXG1BRJejttR3W1ubErBRlsqPyX5QDwfFOhTq3ZcJm2fqbvTgjkH0g8qG3d8q6KpcFO4PBH rFHpLQjk+7RXn1KGVOre2oSPiTnJ+8A6QRluoW4t1acvoLTCUJ86wcEkKI3JB2jkklWSBweX y8qa7Rqm9FqBDVPbeWmKW1bxJQlRAO8cYAwCO+e+NRSVOXLrTTyWvDjxilTSD3UUq3E/+ogD 7gTr02qNy8/JpflqAG4oBUnpbF7GtyemYkaDOvafOql5vcqtiFE7QkckGx6jAAua4hbVJ0Zi atpDyS0jCYjqGtoYUCQlYTjPdJyT5lcH0ACC26PJq1caRGbdckPOANtIO7xD8Mn0GPrZ7AHO AdLLZtufWqwIMFhcqRICcoCcJTg/XJ+yO3J/VknUxlJh2PS/dKXGNRq1QaHvq1RVfxNQUDhO DwfKPL3J8yvROoj7rOkr2oO94jHA7np/P3h5CntZZ8NtopZSa1AJJ7Dk9unNaCm67Kq1YlpO 0SiuOorEplQqZ4AaGe4PcHHCRngHdwVZIbREdcdAjSXEKlvDw4qQSH9gPmPPcHIH3nkalT7x lPKdktPtyVpKnvGCggqUsJ+s5zzlKslR5J4HonojMf6coiNiQqDJkMOYIJzjcjJHf62pjSiw hS61WqpUepoT7cCHJCS+NnvAmE7WwEpQm4oFLSk9PmAJUa8+UaqOzKfYZqCYLCo7bgdkNSHl DxPDKSpJSMHzDGACOD6auD7OV6XbC6mWxR7vqiFU65LdS5SIrKUIYaSCoo4QAndsR6AcKAwO 2ql2uhM2h1WD4iUvKlJcbWTwkr8g/wBxGjnZ8eoudSOnNDp6lyY0JTEmlKWk+MwhTqS82o55 ShTEjH6IPJzxsTKvEIVwQKecW5bQ5VqSbXLiy0KUVG901FB0uK0/pF6Ix45Go1cFPhp6u25V UsJEtxiUyt0DBUgIBAPxwc/t07v1elQJcWHOqMSNImr2RWXnkoW+r81CScqPyGkVwkfjDtgf +L/uxqklRraPMOAQ81X/AKwnybvJ3/WdZr7U8B9Oc/V9Ek+p1mll/UY0MQhvLizaqe+IDx/s 1a3xYcWfbEWLMjNSGHIzYW06gLQryjuDwdJ7zS4uzashlClrXAeCUpGSo+GeBpfb6VJoMJKw QpMdsKB9DtGmSLQL+KK/e0r0ZpabZkVGlRx9GIQRIiL3KRDBWCp5sDnjn5pz+bkCrNv9Nqmq ry35BUinxUI2vFHndZJ4cQ2SDznJzgDae+NdLZ8ZmVDdjPtJcaebKFoUMhSSMEEfdoDXZ0Aq Ltw0et0u8VlyjqStUGTFSGJhQoKQFKT5gcDBJ34JJAHYzw3Nyzp+DXsSv6u3dI60r/7Di/hZ psCaTuKcdx0J6Vp+2IrhfLNRtOkLo9Gt6bGi+IHkVhynvb1kJ8pCgDkjJ83GM+UDg6iNj0W6 bukYt+iyJadxUh9yO60ycrCv+kWAn0+Oe/fVnb4um66RWalTF2+7JeYhqfbjNFHiJUc7AVbg gpJBwQSrA5APcf2VWK6zAamO0T6HKmwppxToV4ZxgguJ8pB5ylRT5u2CTnqNKk0ubSsqJuSS K178mvaHpfV9Tl2StgbE8UTx2sRQd4RXn0TNtdFplclOtz7gjIbcKWgfBZbSChSUZ7nCySs4 zt9B3B4ZbqNQjSYTzYfamhyVvSU7khWCM/n+Yd/Q9+NFJr2jHKw3Mp8unvyGVksLZfQlDK2z kKK15JGQTxjHp20IbVuCkxr8h06dPcTQ11NtC5TjW9YjbyB4iO52pUc85OPXtrs5KIJHw5Fa UpBJHXHN4M3cbt1eailfz2xDa21Kgy1xltOtqMlJUNpGUNK3FQ+RJ79spHx1cT2KbcuOoSmu otysswoTENUeA3jG5IG3cnP2cbyT6qWccDGp5UukPSG17VlXTMoCpESkQly175jziFobRvPk K9pB29sYPw1R3rd1Zu7qFUn1VGoOxKQ2SiHRobpbixGxwlJAwlZA7q5PwwMAbbYUpVV0r2hW a1ViUZLMvu2qtQ0sMkDPNb9zaLsezJQqZfFSf6z3E79I1ipS3k0tt1zc3S4zbikIQhHYK4Jz 889ySS7XlA35bSvgqV/da5adO69WrZei1W36tJpsppQ2PxnVIGfgUDzL+7sdXy9mDqjK6n0q 3KjVmkIq9NkyYs0tABLp8DKXQB9XcPT0IPpjTW0x5+Wm23CUUor94PE9aQ8AT9nWa8y9qnAT +b8PnrNLqN4oCBh7XtQuym9BqtPsyoCDPaLYdc2BSiypQQsIJ4SrzA7vQA4weRJvZ7TXm+jt AbuZ+M9UUxEhaozQbQE/YGBgZCdoJAAOOBps6p151m77UslLKCzdkmSzKdW0lwIZZjqdUkJU CklRCU8gjG7jOMK+lNyyp163dZspO8WpKjNx5IQlHisvR0upSQkBO5JKk8AcbeM50zQ1rxAv l3V5+3tE4kutMx3H33EttNJKlrWcBIAySSfTQw6ldQqbL6YsVeh1Ixmqq+ExpSlhsqYSdzjq echOxJG7gjcOx1OepipyenddVTPA98FNfMfx0bm9/hqxuGDkZ9MH7jrnN0jvmipoky1L8kPR 4kd7xaS6mKp1LSlKJdQoJzwrCQeORkZHGl5hRCVAdIblQkvJCiAK846388Qd7QgVWHN99kMi Uqc1vfqPvSlGZz5FrQocL29yCf18Yi/Xy+G7AZachQ2ZrtTePixPG2gKDZCioc4yFNH54+eo vdvtDulCqZaVEUUNo8CNOmvEqz2zswc/HlX36CN0zKzUKq7U6zOky5ZO5a1OEnOOBnHH3D+r UtDJUsleDxHoZvU20S4alsjkYHvmEHva8TnzHSyqQ+lzYtO3YTnOB6jOpF0YsV7qN1Do1rwj sVPKy6/4e/3ZKckrPyGPj69+dSnoX7P189Xo5qMdxml0dC9vvstalhZ9QhI5UR+ofPV1vZk6 E250ho60w3l1GrykhMqpOt7SpI52ITk7EZ5xkknuTgYqttgXMeXKio9v7xN2LTpbnThNm1BC pdOVTBTng4o7nWvD8M5I9SM865/+210YhdKblpkS2pk2fEqMdx5QmlBMchWAE7QkdvXGuk7T eE41Tr+E9a23Fb6gODAdHP8ArjXzzpbTuEMS0k1OPpbc7/YE/wAoB3R/pHXrh/B5UluRFg1V 6O2uajw1KbQ4sJyPPuxz2xo40mz706S+0nbFjWTOjSKJI8Opvrm8KfKiGHVu7QMqGSEAZA3Z POTp19ndG7p/ZP8ASQf75GiLPuF+r0i/+oKIzLFR6eSp8KkpcjoVlEdht1zeop3YdVkHaRhO 3GDklPTtSdnkuKUlKdiimwNwKZqTf8pGJzR5eQUjYSSpO6ppW/GMffvBmmpJcTyr6vprNI6D UPpu3KbWENqYTPhNSA0vujekKwfmM6zTSgdxjAIpGm56HCq7cWQ80r3ymOmTBfaUA4w7tUnK SQRylSkkEEEKORrV0vaoiqGutUzJfrLgk1B15QL6nwlKCl3AACkBARtwNu3GNMXs6XhNvzox bt2VFhtmXUoe59LZ8u9KihRHwBKScemcalM21bXqUtUufblKlSHB53n4Ta1q+8kEnTdKWgNj cQ9FSFI5KSD89Ug9uXoB+DLsnqDY8NblKkZ+k4DIKjCJ58ZH6Gc5H2c/mni4aLGstKcJtKiD Hwp7X7utEyw7JdQUuWlRFgjsae1+7rC0JVmO1PEcp7ZEX3loy3SEJOUpSnAUf0iSePkNSOLF F23fTrRt9vxZdWnNsB1KOE7lAFR/RA5PyTroy50d6Uk5/Fxauf8Aydj93W6ndJOmEKT7xE6f Wwy6BjeikshQ/Xt0sZVJdDijjiGEvLS14aQL8wvsW3qZa9q0+36S0hmJT46WWkjGSAO5+JJy SfUknT834Y+0n9umRuwbJByLRoeRxn6Oa/d1tTYVkg/9kaH/APXNfu6ZMBuIfUFAx5k/t0Mv ai6P0zqzaSI4lohVeCFqp8s8pGQMtrHqk4HI5BAIzyDNPwEskjBtGhnPf+Tmv3dfRYtlJb8M WlQwj836Oax/w6ypCVChjTbq21BaDQiBr7PHSufa9s0di6FxveKSylDcdhzekuJz+UKuMj1S PuJ54EvqtAt+bdMqgtRi41X2lSa9HZdAadSlKW0l1OCcrACMAp3JQc5CTp7NkWaDkWpRB/8A Htfu6daRS6ZSIimKZTosJlSt6m4zKW0k/HCQOdCl5ZphO1sUFSfU5MbffceVucNTj0Ea5YQy pDSNiEpQAlPYAazTfJoaLgWKk/NksJWna02yvaAgdt3zyT/UPTOs0yZVZvUQLeBH/9k= --------------77434D01A37F51DCC924EE6B-- --------------Boundary-00=_Q92XYDXEYFQ38Q686ADN--
Please! I would consider this one of the most important TODOs for developers. If I wasn't so busy right now, and if I knew more Qt I'd do it. I'm getting all these really cool HTML mails from people with inline images and backgrounds, but I can't enjoy them because I don't see the images except as attachments!
Is this the same as IE's .MHT format? IMHO, MHT is horribly useful for including an entire web page (html plus images) as a single file...
No, this is normal HTML in which the URLs use the cid: protocol, referencing elements by their Content-ID MIME headers.
Yes it is similar to the mhtml format. The difference is only one: in mhtml (*.mht) files in entry From: you have the name of program which saved this file, in email program From: entry contain email address of sender. Both files are pure MIME content. Most email clients in Linux have support for MIME. Kmail and mozilla have also. But mozilla can receive MIME email with html, pictures and render it correcly formatting text and showing pictures where they should be. KMail 1.5 receive correcly MIME, if you have html enabled will show you correct text formatting but PICTURES WILL NEVER BE DISPLAYED in their correct places, but you will see a list of attachments at the bottom of body of message. What a mess.
*** Bug 63746 has been marked as a duplicate of this bug. ***
*** Bug 50624 has been marked as a duplicate of this bug. ***
*** Bug 50076 has been marked as a duplicate of this bug. ***
*** Bug 43479 has been marked as a duplicate of this bug. ***
*** Bug 66207 has been marked as a duplicate of this bug. ***
*** Bug 51223 has been marked as a duplicate of this bug. ***
Looks like this feature is not going to be included in KDE 3.2, but personally I strongly wish it was. What are you development plans about this topic?
Subject: Re: Add support for multipart/related (esp. MHTML/rfc2557) There will be a separate KDE PIM release after KDE 3.2 containing the features they worked on but didn't make it past the string freeze start for KDE 3.2, see http://www.kdedevelopers.org/node/view/221
Subject: Re: Add support for multipart/related (esp. MHTML/rfc2557) It's on my TODO list for the separate release but I don't make any promises. Don.
Created attachment 4319 [details] A HTML mail with images For testing.
*** Bug 79336 has been marked as a duplicate of this bug. ***
*** Bug 89729 has been marked as a duplicate of this bug. ***
This feature works perfectly with Thunderbird. With the preview of the KDE-3.4 Kmail (KMail Version 1.7.92), this feature doesn't still work with KMail... Maybe for KDE 4........
*** Bug 93038 has been marked as a duplicate of this bug. ***
Hello, displaying images inline in HTML messages *still* does not work with KMail. This is a very annoying bug! Please have a look at it, if possible, to fix it within KDE 3.4 (maybe .1 or so). Thank you! :) Jens
Jens: multipart/related messages seem to be quite rare for me, and usually spam... so I'm not overtly surprised that this bug hasn't been given a very high priority (though apparently 684 votes worth of people disagree with me) Also, I'm pretty sure the 3.4 releases will only consist of bug fixes at this point, not any new features, so it will probably need to wait until at least 4.0.
I voted also 20 for this bug; many family mail has html with inline photo's also some business type email has it. So yes, it would really be nice and professional for me if KMail could display attached images inline in the HTML.
IMHO there's a difference between _external_ images (that load from a web server and may be web bugs) and _attached_ images (that have been downloaded anyway, and *are* displayed, but only *below* the actual mail, and not where they belong). The latter should not be too hard, the placeholders (empty boxes) for the pictures are already there and KMail uses (a subset of?) KHTML for its HTML display anyway (right)?. I vote 20 for this feature as well. Thank you! Jens
This bug is only about the latter case where the images are embedded (multipart/related; not attached, that's multipart/mixed). Externally linked images already work fine.
To comment on the ever-reappearing misconception that multipart/related is in any way "related" with SPAM: As has already been commented, spammers use web bugs to verify addresses (and professionally working legally compliant e-mail marketers use them to get response statistics). And as we all know, web bugs are already supported in KMail if you allow it to load external images. The BIG difference between a web bug and an inline binary (we're not only talking of images here, MIME supports other binary content, too) is that the inline binary is transmitted with the mail and can therefore be scanned for viruses etc. Yes, it does increase the mail size substantially, but this no point because they are already widely used and transferred eating your valuable bandwidth, only KMail doesn't show them. THEN it gets annoying! You literally pay for the image but you don't get the benefit. I personally receive around 10-20% of HTML mails which are mostly formatted with inline images (and external images which i have switched off), so i would greatly benefit from multipart/related support in KMail. Robert
Regardless, with the exception of hand-made multipart/related messages to myself, the only multipart/related I have ever received are spam.
Luke, Well, to what extent would missing support for multipart/related help you in *not* recieving these messages? Honestly, i fail to see the point. Spam and multipart/related are completely unrelated in my eyes. The spam/ham distinction is in the hand of you, i.e. the user and should not be in the hand of your mail program. [Well, this is of course not 100% true if you configure SpamAssassin support in KMail and configure SpamAssassin to block multipart/related, then your problem would be solved and you would no longer receive spam of this evil sort ;-) If you need help in configuring SpamAssassin to do this, go to www.spamassassin.org]. There is a large number of e-mail users out there who receive loads of non-spam which *does* contain multipart/related HTML, so why cripple the e-mail client? There are other good reasons why multipart/related support is still missing in KMail, and that is lack of developer resources. Yes, some people have already taken over responsibility of implementing this but i know from my own professional work experience that display of multipart/related content is not *too* trivial to implement. I don't speak C++ or Qt myself and am busy with other things, but if anyone who plans to work on this needs some technical ideas, feel free to contact me. Robert > -----Original Message----- > From: owner@bugs.kde.org [mailto:owner@bugs.kde.org]On Behalf > Of Luke-Jr > Sent: Friday, March 04, 2005 8:25 AM > To: Office.Robert@waczenski.de > Subject: [Bug 6710] Add support for multipart/related (esp. > MHTML/rfc2557) > > > ------- You are receiving this mail because: ------- > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=6710 > > > > > ------- Additional Comments From luke-jr+kdebugs utopios org > 2005-03-04 08:24 ------- > Regardless, with the exception of hand-made multipart/related > messages to myself, the only multipart/related I have ever > received are spam. >
Office.Robert: You've got my position backwards. I'm CC'd because I want multipart/related support. I've even been considering writing a patch for it, though I haven't checked out that part of the code yet so it might be too complex for me to mess with for now. I was merely commenting on how I didn't see this bug as being a major issue to me, just a minor annoyance.
I see. Thanks for rectifying this. But still: It is quite annoying if people continue to throw multipart/related support into the garbage can because they think about it as "ah, that's this small feature that all theses spammers would love to see implemented". So, i was commenting on that level. But your observation is correct, my posting truly sounded as if i was reading your position as "don't implement this". So i still think that lack of support for this is a MAJOR annoyance. It has been like this for me since i started to use KMail together with Linux/KDE at home a year back. A big part of the HTML mails in KMail look butt ugly due to this, so i'm trying to increase awareness of this feature hole. Robert > -----Original Message----- > From: owner@bugs.kde.org [mailto:owner@bugs.kde.org]On Behalf > Of Luke-Jr > Sent: Friday, March 04, 2005 10:10 AM > To: Office.Robert@waczenski.de > Subject: [Bug 6710] Add support for multipart/related (esp. > MHTML/rfc2557) > > > ------- You are receiving this mail because: ------- > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=6710 > > > > > ------- Additional Comments From luke-jr+kdebugs utopios org > 2005-03-04 10:08 ------- > Office.Robert: You've got my position backwards. I'm CC'd > because I want multipart/related support. I've even been > considering writing a patch for it, though I haven't checked > out that part of the code yet so it might be too complex for > me to mess with for now. > I was merely commenting on how I didn't see this bug as being > a major issue to me, just a minor annoyance. >
I, for one, receive a lot of HTML newsletters (that I actually want!) and many of these are only half readable without the embedded images. For example: newsletters from Apple, newsletters from Stayfriends, newsletters from GMX (alhough those *could* be considered SPAM ;-), and lots of order/purchase confirmations from dozens of companies, and so on. I would actually pay for this feature to be implemented. I have offered 10 EUR for the developer who fixes this bug at http://kontact.org/shopping/.
On Friday 04 March 2005 5:09 am, Luke-Jr wrote: > I was merely commenting on how I didn't see this bug as being a major issue > to me, just a minor annoyance. Just to add my $0.02 The reason this is a larger issue from my point of view, is that many companies (including my own) use small images of the company logo in the standard company HTML signature. Not being able to display these signatures makes KMail seem crippled in a corperate environment. Also, being unable to compose these signatures ( see bug #81989 ) hurts as well. These two issues drive me crazy every day.
First, this feature asks for support for a specific mime type where a message/file contains both an HTML document plus all of the related components, style sheets, images, etc. Ideally, this would not only be supported by Kmail, but by Konqueror (as both view _and_ save). This feature is useful for many reasons: - it is the only really clean way to save an entire look/feel for a given webpage, saving all of the related parts as links is brittle and saving them in a sub-directory is messy; using a zip file also isn't standard - systems I develop allow the user to create a "report" that has both images, css, and other media; they download as a _single_ file and can save to their desktop (I do this instead of making a PDF, since PDF creation is much harder) - often times you want to "save" how a web page looks, for reference - "like, dude, did you see how pretty XXX page was?" simply storing the link isn't sufficient, you want to capture the entire look and feel at that time for your portfolio (see above why directories suck) - a correlary to the one above, since most of the CSS/HTML/IMAGES in my system are _dynamically_ created based on who the user is, and the system state, the only way to "record" a bug is to save the current page as a complete whole... anything less prevents you from demonstrating the bug effectively In short, there is alot to be said about multipart/related; and these things have very little, IMHO, to do with Kmail. I created this bug report in konqueror quite a while ago, and I'm not sure why it seems to become a kmail problem; it's a konqueror feature request, IMHO. Cheers, Clark Evans report as a mhtml file (multipart/related) -- right now IE explorer is the only browser that handles this correctly - my system generates "reports" that it This is a very very useful feature, for not only Kmail but also for Konqueror.
Sidenotes: 1) Konqueror 3.4 now supports reading MHTML (multipart/related) files, such as those saved by IE. 2) Konqueror 3.4 will not create them. Our format is the Web Archive, which is a Zip file. It's easier to search in it (non-compressed binary index), and easier for the user to extract sections thereof, if wanted, using a program probably everyone has installed. Nonetheless, the mhtml plugin can list the contents of the multipart/related files -- something IE can't do. That said, this applies to files, not email messages. Hence, "sidenotes". (if you want to discuss this, please use the mailing lists)
> I would actually pay for this feature to be implemented. I have > offered 10 EUR for the developer who fixes this bug at > http://kontact.org/shopping/. It's definitely a desirable improvement, I would be surprised if the majority of the development team didn't agree with that. I've updated the web page ( http://kontact.org/shopping/sanders.php ) albeit the priority ranking is a little low. Don Sanders.
Hi, I have also voted for this bug to be implemented. All the discussions on using HTML for e-mails aside, the fact is, that many companies do so in order to embed their logo. It is indeed quite unprofessional of a modern mail client not to be able to display this correctly. More even, several companies sending news letters by e-mail use embedded images, and some of these mails are hardly readable without the images in place. I also believe this feature will be much more asked for when linux starts to pick up more and more as a desktop OS. Imagine people that now use Outlook/Express, if they suddenly have garbled mail messages in a linux environment, that used to display perfectly fine before ? I have a first customer with such a question already. Could any one please fix this ? Thank you.
I work with customers that usually send screenshots of their problems and said for example: As you can see, when I click here: [ big blank square ] and then go here: [ another big blank square ] this error happens: [ guess what? another big blank square ] So I think the problem...blah blah blah bunch of text more text even more text reply from previous emails [image 1] [image 2] [image 3] As you can see, it is very annoying scrolling back and forth to figure out what picture is what. I switched to Kmail (I was using sylpheed-claws) because I needed HTML support with *inline* image placement...and came to realize that kmail doesn't support it either :( Please fix it!!!
*** Bug 103879 has been marked as a duplicate of this bug. ***
Created attachment 10742 [details] multipart/mixed mail screenshot - works fine Hi, with KDE 3.4, multipart/mixed mails (created by Apple Mail) seem to work. Multipart/related does not - yet. PLEASE fix this. It really is a killer bug. Thanks!
Ok, here is another use case for this: I tried today to parse a local weather forecast service which uses nice graphics to show how the days gonna be. As I'm the kind of guy who likes the information to come to me I parsed the page, downloaded and included the images but was unable to compose emails which where displayd correctly by KMail (using Perls MIME::Lite Module). Apparently, this feature is still broken or only supports an Apple specific way. Anyway, I'd really like this to work ASAP, because it is usefull from time to time. BTW, it is quite annoying that there is only a global "external references" switch and not one by address or folder.
#40: I did exactly the same as you, using perl and MIME::Lite to parse a page that shows a picture everyday with a small explanation of it. So I decided it would be nice to have it sent to my mail, but I couldn't find any way to display right. I would really like this to work, my votes for this bug.
> Anyway, I'd really > like this to work ASAP, because it is usefull from time to time. Marcus, this is free software so if that feature is so important for you go ahead and implement it. It will need a bit to dig in the kmail code but you'll get help from the kmail developers of course. Carsten
Just noticed this bug in KDE 3.4 with kmail. the cid: should identify the files via Content-ID Tag in the email and display them. thunderbird emails are easy to check: they send their own smilies in the message, which are only visible as attachement but not in the HTML text. as this is one of the oldest missing features in Kmail, I really want to point out, that this feature should be implemented ASAP! with regards gab
On Sunday 12 June 2005 15:02, Cyb Org wrote: > as this is one of the oldest missing features in Kmail, I really want to > point out, that this feature should be implemented ASAP! Well, go ahead then. :) Till
BTW, Thunderbird really should be putting an ALT tag w/ some equivalent text.
Attached are two patches for this bug, one for KDE3.2.0 (the version I'm using at work) and one (untested) for the KDE 3.5 branch. Current limitations: - Does not work with IMAP, because we don't get the Content-Id header. - Embedded images are still included at the end of the message.
Created attachment 12356 [details] Fix for KDE 3.2
Created attachment 12357 [details] Fix for KDE 3.5 (untested)
[quote] Embedded images are still included at the end of the message. [/quote] Just realized this sentence was a bit ambiguous. What wanted to say was that images are correctly displayed at their respective place in the HTML message, but they are also displayed at the end of the message.
[quote] Embedded images are still included at the end of the message. [/quote] Some mail readers don't show those attached files, which can be understood because they are already shown in the body. Still, those file are really attached to the mail so I would consider it a normal behaviour to show them at the end like any attachment and let the user do as with any attached file. If someone thinks this is not good, I would suggest adding a way to easily show/hide all attached files, regardless of the mail being MHTML/rfc2557 or not. My two euro-cents...
I don't see the point of this remark since Kmail includes a view of the "structure" of the mail by default, under the Message Panel, when there is any part that is not Textual. So It's already in kmail.
Try View->Attachments-> - As Icons (incl MHTML content) - Smart (hide MHTML content) - Inline (incl MHTML content) - Hide (hide MHTML content) (part in parenthesis probably not implemented, but suggested functionality)
Both limitations could be fixed, but the patch is already quite big, so I am waiting for KMail developers feedback before I work on it any further.
SVN commit 454999 by kloecker: Fix displaying HTML messages with embedded images. Patch by Aurélien Gâteau. BUG:6710 M +5 -1 filehtmlwriter.cpp M +1 -0 filehtmlwriter.h M +6 -0 interfaces/htmlwriter.h M +29 -0 khtmlparthtmlwriter.cpp M +7 -0 khtmlparthtmlwriter.h M +7 -0 kmmessage.cpp M +5 -0 kmmsgpart.h M +5 -0 objecttreeparser.cpp M +5 -0 teehtmlwriter.cpp M +1 -0 teehtmlwriter.h --- branches/KDE/3.5/kdepim/kmail/filehtmlwriter.cpp #454998:454999 @@ -98,7 +98,11 @@ else mStream.setDevice( &mFile ); } - + void FileHtmlWriter::embedPart( const QCString & contentId, const QString & url ) { + mStream << "<!-- embedPart(contentID=" << contentId << ", url=" << url << ") -->" << endl; + flush(); + } + } // namespace KMail --- branches/KDE/3.5/kdepim/kmail/filehtmlwriter.h #454998:454999 @@ -52,6 +52,7 @@ void write( const QString & str ); void queue( const QString & str ); void flush(); + void embedPart( const QCString & contentId, const QString & url ); private: void openOrWarn(); --- branches/KDE/3.5/kdepim/kmail/interfaces/htmlwriter.h #454998:454999 @@ -33,6 +33,7 @@ #ifndef __KMAIL_INTERFACES_HTMLWRITER_H__ #define __KMAIL_INTERFACES_HTMLWRITER_H__ +class QCString; class QString; namespace KMail { @@ -106,6 +107,11 @@ virtual void queue( const QString & str ) = 0; /** (Start) flushing internal buffers, if any. */ virtual void flush() = 0; + + /** + * Embed a part with Content-ID @contentId, using url @url. + */ + virtual void embedPart( const QCString & contentId, const QString & url ) = 0; }; } // namespace KMail --- branches/KDE/3.5/kdepim/kmail/khtmlparthtmlwriter.cpp #454998:454999 @@ -37,6 +37,10 @@ #include <khtml_part.h> #include <khtmlview.h> +#include <dom/dom_string.h> +#include <dom/html_document.h> +#include <dom/html_image.h> +#include <dom/html_misc.h> #include <cassert> @@ -61,6 +65,8 @@ reset(); } + mEmbeddedPartMap.clear(); + // clear the widget: mHtmlPart->view()->setUpdatesEnabled( false ); mHtmlPart->view()->viewport()->setUpdatesEnabled( false ); @@ -75,6 +81,9 @@ void KHtmlPartHtmlWriter::end() { kdWarning( mState != Begun, 5006 ) << "KHtmlPartHtmlWriter: end() called on non-begun or queued session!" << endl; mHtmlPart->end(); + + resolveCidUrls(); + mHtmlPart->view()->viewport()->setUpdatesEnabled( true ); mHtmlPart->view()->setUpdatesEnabled( true ); mHtmlPart->view()->viewport()->repaint( false ); @@ -118,7 +127,27 @@ } } + void KHtmlPartHtmlWriter::embedPart( const QCString & contentId, + const QString & contentURL ) { + mEmbeddedPartMap[QString(contentId)] = contentURL; + } + void KHtmlPartHtmlWriter::resolveCidUrls() + { + DOM::HTMLDocument document = mHtmlPart->htmlDocument(); + DOM::HTMLCollection images = document.images(); + for ( DOM::Node node = images.firstItem(); !node.isNull(); node = images.nextItem() ) { + DOM::HTMLImageElement image( node ); + KURL url( image.src().string() ); + if ( url.protocol() == "cid" ) { + EmbeddedPartMap::const_iterator it = mEmbeddedPartMap.find( url.path() ); + if ( it != mEmbeddedPartMap.end() ) { + kdDebug(5006) << "Replacing " << url.prettyURL() << " by " << it.data() << endl; + image.setSrc( it.data() ); + } + } + } + } } // namespace KMail --- branches/KDE/3.5/kdepim/kmail/khtmlparthtmlwriter.h #454998:454999 @@ -46,6 +46,8 @@ class KHtmlPartHtmlWriter : public QObject, public HtmlWriter { Q_OBJECT public: + // Key is Content-Id, value is URL + typedef QMap<QString, QString> EmbeddedPartMap; KHtmlPartHtmlWriter( KHTMLPart * part, QObject * parent=0, const char * name = 0 ); virtual ~KHtmlPartHtmlWriter(); @@ -56,11 +58,15 @@ void write( const QString & str ); void queue( const QString & str ); void flush(); + void embedPart( const QCString & contentId, const QString & url ); private slots: void slotWriteNextHtmlChunk(); private: + void resolveCidUrls(); + + private: KHTMLPart * mHtmlPart; QStringList mHtmlQueue; QTimer mHtmlTimer; @@ -69,6 +75,7 @@ Queued, Ended } mState; + EmbeddedPartMap mEmbeddedPartMap; }; } // namespace KMail --- branches/KDE/3.5/kdepim/kmail/kmmessage.cpp #454998:454999 @@ -2903,6 +2903,12 @@ else aPart->setBody( "" ); + // Content-id + if ( headers.HasContentId() ) { + const QCString contentId = headers.ContentId().AsString().c_str(); + // ignore leading '<' and trailing '>' + aPart->setContentId( contentId.mid( 1, contentId.length() - 2 ) ); + } } // If no valid body part was given, // set all MultipartBodyPart attributes to empty values. @@ -2917,6 +2923,7 @@ aPart->setContentDescription(""); aPart->setContentDisposition(""); aPart->setBody(""); + aPart->setContentId(""); } } --- branches/KDE/3.5/kdepim/kmail/kmmsgpart.h #454998:454999 @@ -112,6 +112,10 @@ int subtype() const; void setSubtype(int aSubtype); + /** Content-Id */ + QCString contentId() const { return mContentId; } + void setContentId( const QCString & aStr ) { mContentId = aStr; } + /** Set the 'Content-Type' by mime-magic from the contents of the body. If autoDecode is TRUE the decoded body will be used for mime type determination (this does not change the body itself). */ @@ -213,6 +217,7 @@ QCString mCte; QCString mContentDescription; QCString mContentDisposition; + QCString mContentId; QByteArray mBody; QCString mAdditionalCTypeParamStr; QString mName; --- branches/KDE/3.5/kdepim/kmail/objecttreeparser.cpp #454998:454999 @@ -1765,6 +1765,11 @@ } } + QCString contentId = msgPart->contentId(); + if ( !contentId.isEmpty() ) { + htmlWriter()->embedPart( contentId, href ); + } + if( inlineImage ) // show the filename of the image below the embedded image htmlWriter()->queue( "<div><a href=\"" + href + "\">" --- branches/KDE/3.5/kdepim/kmail/teehtmlwriter.cpp #454998:454999 @@ -90,4 +90,9 @@ (*it)->flush(); } + void TeeHtmlWriter::embedPart( const QCString & contentId, const QString & url ) { + for ( QValueListIterator<HtmlWriter*> it = mWriters.begin(); it != mWriters.end(); ++it ) + (*it)->embedPart( contentId, url ); + } + } // namespace KMail --- branches/KDE/3.5/kdepim/kmail/teehtmlwriter.h #454998:454999 @@ -59,6 +59,7 @@ void write( const QString & str ); void queue( const QString & str ); void flush(); + void embedPart( const QCString & contentId, const QString & url ); private: /** We own the HtmlWriters added to us! */
Cool, patch works great in IMAP as well. Thanks Aurelien / Ingo, this is by far one of the biggest things KMail has been lacking from my daily use. Cool, patch works great in IMAP as well.<br> <br> Thanks Aurelien / Ingo, this is by far one of the biggest things KMail has been lacking from my daily use.<br><br clear="all"><br>-- <br>There are two major products that came out of Berkeley: LSD and UNIX.<br>We do not believe this to be a coincidence. ~Jeremy S. Anderson
THANK YOU! THANK YOU! THANK YOU! :-D This is one of the biggest things that KMail has been lacking so far. I originally promised some money for whoever fixes this bug. If you want I can send it to you, or donate it somewhere (UNICEF or so). Jens PS: does this patch apply to KDE 3.4.2 as well? I could perhaps patch the SuSE RPMs and provide them for download.
Just wanted to add my "WOOHOO, THANKS!!!" =:)
So since everyone else does it, my two unrelevant eurocents: thanks a lot :)
Le Mardi 30 Août 2005 14:01, Jens B.Benecke a écrit : > This is one of the biggest things that KMail has been lacking so far. > I originally promised some money for whoever fixes this bug. If you want I > can send it to you, or donate it somewhere (UNICEF or so). Thank you for this kind offer, but I don't need this money. If you want to donate money to promote KDE you can visit http://kde.org/support/#Money , (but donating to NGO like UNICEF is nice too) > PS: does this patch apply to KDE 3.4.2 as well? > I could perhaps patch the SuSE RPMs and provide them for download. It should, but I didn't test.
Created attachment 12458 [details] mailmessage Hi, Thank you for providing this functionality. However I found one bug. The background is not shown in a table cell in the attached mail. Regards, Edwin
*** Bug 105205 has been marked as a duplicate of this bug. ***
I am running KDE 3.5 (Kubuntu packages) and this patch is still not there. There are plans to add (definitively) this to kmail in the future? By the way, I tested the patch for 3.5 with another computer (runnung Debian sarge and KDE 3.3). I applyed the patch to the latest stable kdepim package (downloaded dec 2nd 2005) and it runs perfectly (except that I didn' tested the background problem related in the comment from Edwin). Thanks for the patch! Marcio
Op zaterdag 3 december 2005 19:33, schreef Marcio Rosa da Silva: > I am running KDE 3.5 (Kubuntu packages) and this patch is still not there. > There are plans to add (definitively) this to kmail in the future? Well, i run suse 10 with kde 3,5, and the patch works. No idea why your kubuntu-packages excluded this patch Regards, Rinse
I'm using SuSE 10 with Kde 3.5 as well, but for me it still doesn't work out of the box. Mails with embedded images (contrary to mails containing links to external images on the web somewhere), don't display the images inline. I only see a placeholder, and image icons at the end of the mail. So I'm not sure SuSE 10's Kde 3.5 does contain the patch. Regards, Geert
Op maandag 5 december 2005 14:49, schreef Geert Janssens: > I'm using SuSE 10 with Kde 3.5 as well, but for me it still doesn't work > out of the box. It works over here, so there must be a difference in our configuration I checked this, and i use this option: menu 'view->attachements->intelligent' With that option enabled the images are embedded If i change this to 'icons', the images are no longer embedded in the e-mails If i change this to 'embedded', the images are embedded in the e-mails If i chahge this to 'hidden', the images are gone again :) Regards, Rinse
Heh, My settings were on Smart, and it didn't work. After changing them to inline, it did work. Changing to Smart again now works sometimes, and sometimes not: If I have a message that only contains 2 images and no text, the Smart setting shows two icons, while the inline setting displays the images. All in all, I'm very happy with the improvement though. Thanks !
In addition to Edwin Schepers' comment (comment #60) I also found that a background image in the body tag, is not displayed correctly. Instead of behind the content, it's displayed next to it, and quite small also.
Le Lundi 5 Décembre 2005 16:11, Geert Janssens a écrit : > ------- In addition to Edwin Schepers' comment (comment #60) I also found > that a background image in the body tag, is not displayed correctly. > Instead of behind the content, it's displayed next to it, and quite small > also. That's right, only <img> tags are handled for now. Handling all possible places where an image could appear would be quite tedious with the current implementation. I tried to implement another way, but did not succeed. Aurélien
Since this bug is marked as resolved, I created a new one for embedded images other than in <img> tags. Just to keep track of this issue.
... and I should have mentioned its reference: bug #117752
For me it is like comment #66 from Geert Janssens. Now it seems to be working also in the packaged version. Good! :-) Thanks! Marcio
WRT comment #67: background is intentionally ignored. KMail always sets the background to a solid colour, depending on the encryption/signature state. This is a security feature, not a bug, and will probably not be changed.
*** Bug 142204 has been marked as a duplicate of this bug. ***