Cannot reproduce.

I played with several options in the apache configuration 
(AddDefaultCharset, AddCharset) in order to force apache to serve the 
response in the correct encoding (utf-8). While this works for files 
stored on the local filesystem (a simple text .ics file), it doesn't 
affect the php's response produced by kronolith.
So, just to clarify your previous response, when you do the test with 
the 2 requests (one with an Accept-Charset header and one without) you 
still get the same valid UTF-8 encoded response? That shouldn't be 
happening...
I think that by default an HTTP text/* response is ISO-8859-1 and not 
UTF-8, unless otherwise specified. 
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
What I'm trying to say is that the request generated by kronolith 
should specify an Accept-Charset header in order to get the correct 
response from the server.

Thank you for everything and I wish you all a happy New Year :)

I get a valid UTF-8 encoded response back from the server, which is 
what you expect from a text/calendar response, if not specified 
otherwise. Maybe you don't have UTF-8 locale support on your system?

I can reproduce it using a command line to manually generate a similar 
request using curl.
Using the following command:

~# curl --basic -u calendar:XXXX -v 
"http://127.0.0.1/rpc.php/kronolith/calendar/calendar.ics"
* About to connect() to 127.0.0.1 port 80
*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 80
* Server auth using Basic with user 'calendar'
Authorization: Basic Y2FsZW5kYXI6Y0BsM25kQHI=
User-Agent: curl/7.12.2 (i686-pc-linux-gnu) libcurl/7.12.2 
OpenSSL/0.9.7l zlib/1.2.2
Host: 127.0.0.1
Pragma: no-cache
Accept: */*

< HTTP/1.1 200 OK
< Date: Wed, 29 Dec 2010 10:29:53 GMT
< Server: Apache
< Set-Cookie: Horde=9083da515b573f377284c524da38d192; path=/; domain=127.0.0.1
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, 
pre-check=0
< Pragma: no-cache
< X-Dav-Powered-By: Horde WebDAV Server
< Set-Cookie: imp_key=9083da515b573f377284c524da38d192; path=/; 
domain=127.0.0.1
< Set-Cookie: auth_key=9083da515b573f377284c524da38d192; path=/; 
domain=127.0.0.1
< Last-modified: Wed, 29 Dec 2010 10:29:53 GMT
< Content-length: 554
< X-WebDAV-Status: 200 OK
< Content-Type: text/calendar
BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:calendar's Calendar
PRODID:-//The Horde Project//Horde_iCalendar Library\, Horde 3.3.11//EN
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART:20101207T040000Z
DTEND:20101207T050000Z
DTSTAMP:20101229T102953Z
UID:20101207111532.10353qlamyyxehyc@213.140.132.32
CREATED:20101207T091532Z
LAST-MODIFIED:20101207T091532Z
SUMMARY:event ?? ????????
ORGANIZER;CN=calendar:mailto:calendar
DESCRIPTION:???????? ?????????.\n???????????\n???lalalslasl
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0

In this case the output is misformated... utf characters are converted 
to ? (An effort is made to convert the output to ISO-8859-1).
Adding an appropriate 'Accept-Charset' header fixes the problem and 
the server response is utf-8 encoded as it should :

~# curl --basic -u calendar:XXXX -v -H 'Accept-Charset: utf-8' 
"http://127.0.0.1/rpc.php/kronolith/calendar/calendar.ics"
* About to connect() to 127.0.0.1 port 80
*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 80
* Server auth using Basic with user 'calendar'
Authorization: Basic Y2FsZW5kYXI6Y0BsM25kQHI=
User-Agent: curl/7.12.2 (i686-pc-linux-gnu) libcurl/7.12.2 
OpenSSL/0.9.7l zlib/1.2.2
Host: 127.0.0.1
Pragma: no-cache
Accept: */*
Accept-Charset: utf-8

< HTTP/1.1 200 OK
< Date: Wed, 29 Dec 2010 10:30:24 GMT
< Server: Apache
< Set-Cookie: Horde=c8491bb24b20d1189241c065752bd59a; path=/; domain=127.0.0.1
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, 
pre-check=0
< Pragma: no-cache
< X-Dav-Powered-By: Horde WebDAV Server
< Set-Cookie: imp_key=c8491bb24b20d1189241c065752bd59a; path=/; 
domain=127.0.0.1
< Set-Cookie: auth_key=c8491bb24b20d1189241c065752bd59a; path=/; 
domain=127.0.0.1
< Last-modified: Wed, 29 Dec 2010 10:30:24 GMT
< Content-length: 595
< X-WebDAV-Status: 200 OK
< Content-Type: text/calendar
BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:calendar's Calendar
PRODID:-//The Horde Project//Horde_iCalendar Library\, Horde 3.3.11//EN
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART:20101207T040000Z
DTEND:20101207T050000Z
DTSTAMP:20101229T103024Z
UID:20101207111532.10353qlamyyxehyc@213.140.132.32
CREATED:20101207T091532Z
LAST-MODIFIED:20101207T091532Z
SUMMARY:event ???µ ?µ?»?»?·?½?????¬
ORGANIZER;CN=calendar:mailto:calendar
DESCRIPTION:???»?»?·?½?????® 
? ?µ????³??±???®.\n???£?????µ???????½?µ??\n?????»lalalslasl
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0

If you do this test, do you get different results?

The server's response is not the problem, server responds as it should 
according to rfcs 
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), but the 
problem is in the request.
When kronolith subscribes to the remote calender is making a request 
identical to the first one, and not the second one, and that's what's 
causing the problem.

Using a browser to make the same request works fine, cause the browser 
sends an Accept-Charset header in the request anyway.


Thank you for your consideration

I can't reproduce this. Special characters are handled perfectly fine 
when subscribe a Kronolith calendar from another Kronolith instance.

Updated horde installation to the latest Groupware Webmail edition 
v1.2.9 and the problem still exists. You are right, it's not the Git 
version of Kronolith, but I checked the Git version and didn't see any 
changes regarding this, that's why I chose this queue, which is 
probably wrong...
I can't see a way of changing the Queue Version... Should I report it 
again using a different Queue? Horde Groupware Webmail edition?

You are not using the Git version of Kronolith.

I found out that when retrieving the remote calendar, the generated 
HTTP request didn't specify any special headers, like the list of 
accepted character sets so I guess the response was served using a 
default encoding (ISO8859-1?) which breaks any unicode characters.
I applied the attached patch and the problem seems to be resolved...

When using kronolith to subscribe to a remote calendar that is also on 
kronolith (same or other server), all utf characters on events display 
incorrectly.

I am currently using Horde Groupware Webmail Edition 1.2.7

I attach a screenshot of the problem. The two events shown are, the 
one that is displayed corrently in the local calendar and the one that 
is displayed incorrectly is from the same calendar when subscribed on 
it as remote calendar.