Closed (duplicate)
Project:
Event
Version:
4.7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
18 Sep 2006 at 10:08 UTC
Updated:
5 Mar 2007 at 12:39 UTC
Jump to comment: Most recent file
Comments
Comment #1
solipsist commentedHere's a copy of the ical feed. As you can see it contains non-English characters and I wonder whether they are correctly encoded and whether that could be why it doesn't work. Any ideas? Anyone who knows the iCal-spec?
Comment #2
killes@www.drop.org commentedplease look at the ical RFP to find out what encoding is required.
Comment #3
solipsist commentedFrom:
http://tools.ietf.org/html/rfc2445#page-10
Comment #4
karens commentedWhat's needed is to encode the description like:
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:
Not sure if there is already a drupal function somewhere that can do a quoted-printable encoding. I used to have one that worked, but can't find it right now. Maybe some else has one, but I'll keep looking for it...
Comment #5
karens commentedHere is the PEAR function for quoted printable encoding (from PEAR mail/mimePart.php):
You need to run the text through that function, and put DESCRIPTION;ENCODING=QUOTED-PRINTABLE: in front of it in the ical file instead of just DESCRIPTION; You should do the same on SUMMARY.
If I have time, I'll try to make this into a patch.
Comment #6
solipsist commentedThanks Karen! I'll try this!
Comment #7
karens commentedTry this patch... (need quoted printable on the location, too, I think. It should be anywhere there could be text).
Comment #8
killes@www.drop.org commentedis the PEAR code GPL? I know they use a variety of licenses.
Comment #9
karens commentedNot sure, but we have PEAR code included in other modules (rightly or wrongly). If the license is a problem, I guess we have to write our own function that does the same thing.
Comment #10
karens commentedHere's what the PEAR file says. I don't know how to interpret it.
Comment #11
killes@www.drop.org commentedA non-GPL compatible license would be a problem yes. Drupal core doesn't use any PEAR code, so it is the task of module maintainers to ensure they not breach somebody's license.
If the code is GPL, we should at lease rename the function in order to avoid a namespace conflct should somebody use PEAR and Drupal.
Comment #12
karens commentedI had my own version of a function to do this. I'll dig it out and use it instead, then this won't be an issue.
Comment #13
karens commentedHere's a patch with a function I put together from code I have used before, named appropriately for the module so there are no name clashes.
Comment #14
karens commentedUploaded wrong file, use this patch instead.
Comment #15
killes@www.drop.org commented:)
solipsist, cab you test this latest patch?
Comment #16
solipsist commentedSure thing! Thanks Karen and Killes for your time and efforts!
Comment #17
solipsist commentedHoolabaloola! It seems to work! I've confirmed it works with Google Calendar.
Here's the output:
Thanks a million Karen! Great work! Killes, I'm so happy we can finally harness the full power of this module!
Comment #18
killes@www.drop.org commentedapplied
Comment #19
solipsist commentedApparently my initial report was wrong. Google Calendar shows an error message when I try to add this iCal-calendar:
webcal://www.kogvet.se/event/ical/all/all
It may be the character encoding or it may be something else. I stripped the calendar of any non-English chars before and that was when it worked. I didn't realize that until later. Now the character encoding may actually be wrong here, I don't know. Any theories?
Comment #20
solipsist commentedFollow-up: I've attached a screenshot of the error message I get at Google Calendar when trying to add the ical feed as a public calendar. The error message is a change because before the patch et c, when the calendar was added there was no error message, but nothing showed either.
Comment #21
karens commentedI'll take another look at this when I have time, but can't do it right now. The use of quoted-printable is definitely needed here, just need to see what else might be the problem (could be some problem in the conversion of certain special characters). In the meantime, could you post an example of something that did not work that could be used to test it?
Comment #22
karens commentedI mean an example of text that did not work, rather than a screen shot.
Comment #23
solipsist commentedI wish I knew what doesn't work. Your text-encoding was definitely needed but like you wrote, there's something else going on here. I've attached a copy of the feed which Google Calendar cannot parse. I tried opening it in Sunbird and Lightning but couldn't, not sure if it was because of the feed itself or them not supporting the format.
Been looking around for a spec and a way to validate the feed but haven't come up with anything. Maybe someone else knows?
Comment #24
solipsist commentedGood documentation of the format: http://en.wikipedia.org/wiki/ICalendar
Comment #25
solipsist commentedI have a theory... iCal uses CRLF to separate data, but several of our posts have linebreaks in then. Karen, can you BASE64 code these CRLFs so that the file doesn't break the standard?
Comment #26
solipsist commentedHere's an example:
should be:
I tried changing it to HTML to rid if of the additional CRLFs, replacing them with
but it didn't seem to work. I'll need a code solution to this.
Comment #27
solipsist commentedHere's an exampel of a wel-formed entry:
A simple string replacement should do the job. I'm gonna try it.
Comment #28
solipsist commentedAfter changing the code back, using the replacement function in ical.inc to replace CRLFs (\r\n) with \\n, it works, at least in Sunbird. It likes the .ics files now, it imports it right but it doesn't recognize or get the character encoding right.
Google Calendar can't even parse it now.
Comment #29
solipsist commentedAccording to my friend who runs iCal on a Mac with a Swedish version of Mac OS X, he can import and subscribe to the ical feed, but the characters do not appear as they are instead he sees the encoded characters instead of the actual. Apparently iCal fails to recognize the encoding.
Comment #30
solipsist commentedLots of posts today! :)
Anyway, line breaks should be okay now that I replaced all "\r\n" with "\\n". Character encoding may be the actual problem here, issues with UTF-8 et c.
Found this which may be of some help:
http://phpicalendar.net/forums/archive/index.php/t-1252.html
Also worth looking into for code and ideas:
http://phpicalendar.net
Comment #31
solipsist commentedStrange, it works now with Google Calendar as well but with one problem, it shows characters in BASE64, doesn't get the encoding right either so I think the BASE64 encoding Karen implemented needs tweaking. Tomorrow I'm gonna look at how phpicalendar does it.
Comment #32
solipsist commentedAfter investigating by
1) adding the feed to Google Calendar, seen it work except for the BASE 64 encoding, and also learnt that GCal doesn't update very frequently which is why I haven't been able to see the results of my changes right away
2) and used an application called eventSherpa to try parsing the feeds
3) and comparing the ical feed from my Google Calendar to the one generated by the event module and the RFC and comments found in Wikipedia
I have three theories:
- The RFC says lines should be terminated by CRLF, in escaped chars that's \r\n, the event module terminates the lines with \n, I am now rewriting it to follow the RFC.
- The RFC also says that CRLFs and CRs within fields should be replaced by \n, this is what Google Calendar does and eventSherpa parses this feed correctly
- By comparing a google ics file with the events module ics file I've noticed there are discrepancies what fields are concerned, fields determing time zone and calendar (gregorian or julian) to mention two. Whether these fields are required for an ical feed to be parsed correctly by most calendar applications, I cannot say, but missing fields could be one reason.
- Character encoding doesn't seem to be done with BASE 64, Google uses regular UTF-8 and it works with eventSherpa, which is what the event module does without Karen's code
So there's a lot of detective work left to do. I'll have to read the RFC more carefully now.
I've attached the ics from Google Cal with my calendar with a demo event with non-English chars and linebreaks, this ical feed IS parsed by eventSherpa.
I've also attached an ics from our site (see next post), generated by the event module with my modifications, this feed is NOT parsed by eventSherpa.
Comments and ideas are most welcome!
Comment #33
solipsist commentedThis is the second file, the one that DOES NOT parse.
Comment #34
solipsist commentedHere are the error messages iCal generates with the feed I've got now (the ICS attached above):
Comment #35
solipsist commentedApple's documentation, may be of use:
http://developer.apple.com/internet/appleapplications/icalendarfiles.html
Comment #36
markstos commentedI think I've found a definite bug in ICal feed generation with 1.3.2.4 of ical.inc. First, it seems that 1.3.2.3 worked better for me with Google Calendar. With it, I was able to see complete descriptions, while 1.3.2.4 only shows the first line, ending with "=". The following may explain way.
In the spec ( http://www.ietf.org/rfc/rfc2445.txt) , we find this:
"Lines of text SHOULD NOT be longer than 75 octets, excluding the line
break. Long content lines SHOULD be split into a multiple line
representations using a line "folding" technique. That is, a long
line can be split between any two characters by inserting a CRLF
immediately followed by a single linear white space character (i.e.,
SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
of CRLF followed immediately by a single linear white space character
is ignored (i.e., removed) when processing the content type.
For example the line:
DESCRIPTION:This is a long description that exists on a long line.
Can be represented as:
DESCRIPTION:This is a lo
ng description
that exists on a long line.
"
However, "ical.inc" current does follow this spec, as this example shows:
##
Using the "ENCODING=QUOTED-PRINTABLE" does not allow you to avoid the line-wrapping rule above. For example, since this spec description:
http://www.kanzaki.com/docs/ical/encoding.html
Here they provide an example of a BASE64 encoding that still has the line wrapping in place.
There may be other bugs lurking, but I hope this is enough to solve the line-wrapping issue!
###
One more thing! The 72 character rule seems to apply to /any/ data, including parts like:
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:
That should be figured into line-wrapping as well, I think. It least, it seems to be in the examples I found.
I hope that's enough detail to solve this bug!
Mark
Comment #37
markstos commentedThis might be helpful. It's some GPL'ed code that handles ical folding, and in particular has some comments related to QUOTED printable.
The funtion is "sub _fold" from here:
http://search.cpan.org/src/JESSE/Data-ICal-0.11/lib/Data/ICal/Property.pm
Here's the juicy part. (Yes, it's Perl, not PHP, but should be easy to translate. )
Comment #38
westbywest commentedI've been working with this problem myself and found that the hosting webserver (i.e. Apache) may need to be configured to correctly handle .ics format.
For linux, add the following to /etc/mime.types:
Otherwise, you could add the following to Apache's httpd.conf:
This fixed my problem importing the event module's ical feed into Google calendar.
Comment #39
killes@www.drop.org commentedthere indeed seems to be some kind of error. While all the Umluats were correktly displayed in sunbird, the colons weren't. Each colon is displayed surrounded by double quotes. Very strange.
Comment #40
geodaniel commentedThis could go back to issues introduced by the patch I suggested back in May last year as well... http://drupal.org/node/61830
Comment #41
geodaniel commentedWe should probably also be stripping HTML from the feeds and replacing paragraphs with \n\n, right?
Comment #42
karens commentedSee a patch posted at http://drupal.org/node/61830. That got import into Google Calendar working for me and it would be good to have others test it. Actually one of these issues should probably be posted as a duplicate of the other, but not sure which should be the one to survive.
Comment #43
geodaniel commentedLets set this as a duplicate now that killes has applied your patch in the other issue this morning. Thanks for your work on this!