sourcesimian / uICAL

Lightweight C++ and Python library for reading ICAL calendar format
MIT License
18 stars 9 forks source link

Support line folding #4

Open ducky64 opened 1 year ago

ducky64 commented 1 year ago
DESCRIPTION:This is a lo
 ng description
  that exists on a long line.

should be interpreted as

DESCRIPTION:This is a long description that exists on a long line.

per https://icalendar.org/iCalendar-RFC-5545/3-1-content-lines.html, where newline plus whitespace should effectively be discarded.

Currently, the parser tries to interpret these as VLINEs and errors out.

This gets generated by Google Calendar exports.

For anyone trying to just get something to work, a hack solution to discard the extra lines is:

diff --git a/src/vline.cpp b/src/vline.cpp
index 9f86607..81ff1ec 100644
--- a/src/vline.cpp
+++ b/src/vline.cpp
@@ -11,16 +11,18 @@
 namespace uICAL {
     VLine::VLine(const string& line) {
         if(line.empty()) {
+            this->name = string::none();
+            this->value = string::none();
             log_error("%s", "VLINE is empty");
-            throw ParseError("VLINE is empty");
         }

         size_t colon = line.find(":");
         size_t semicolon = line.find(";");

         if (colon == string::npos) {
+            this->name = string::none();
+            this->value = string::none();
             log_error("VLINE does not have a ':' \"%s\"", line.c_str());
-            throw ParseError(string("VLINE does not have a ':' \"") + line + "\"");
         }

         if (semicolon != string::npos && semicolon < colon) {

In general, the parsing is very strict, which would seem undesirable for embedded applications and deployments which should probably prioritize uptime and availability.

DrJohannessen commented 7 months ago

any update on that? i ran into the same pproblen, espacially the heavy use of throw.

ducky64 commented 7 months ago

If you just need it to run and parse calendars, the above diff / patch is sufficient. It will truncate multiline entries. Tested on a ESP32-S3, not sure it will run on something much weaker.

Ultimately, I think this library's structure is too brittle (non-recoverable validation) for my application, I instead chose to offload processing to a external server running Python that has a more robust parser.

DrJohannessen commented 7 months ago

yeah, im building an e paper calendar, i also thought about that, but i dont think im giving up yet. i also saw there are some forks, but my cpp knowledge is not good enough to check if they acutally work / improve stuff, but certainly seems so.

sourcesimian commented 6 months ago

Thank you @ducky64, I'm not currently working in uICAL, but feel free to submit a pull request with new and passing tests.