proper way to encode multi-line location field?

[pleasantone]

From looking at the code, it looks like newlines should be encoded in location as the 3-character literal "\\n" (backslash-backslash-lowercase-n). Unfortunately my ical output is not coming out correctly.

relevant line of code:

content = content.replace(/\\/g, '\\\\').replace(/(,|;)/g, '\\$1').replace(/\\\\n/g, '\\n');

ics file:

LOCATION:Peet's Coffee Northgate Mall\\5800 Northgate Dr. #146\\San R
 afael\, CA 94114

1. What is the right encoding?
2. Would you consider adding code to allow "[br]" as a substitute for newline to eliminate this class of silliness?

<add-to-calendar-button
  name="Fort Ross Road Ramble"
  description="A twisty ride up to Guerneville and north featuring Fort Ross Rd. and Kruse Ranch Rd.[br]Expect up to 4 miles of well groomed dirt roads.[br]"
  location="Peet&#39;s Coffee Northgate Mall\\n5800 Northgate Dr. #146\\nSan Rafael, CA 94114"
  startDate="2023-07-30"
  startTime="08:45"
  endDate="2023-07-30"
  endTime="14:45"
  url="http://localhost:1313/events/2023/07/fort-ross-road-ramble/"
  options="'Apple','Google','iCal','Outlook.com','Microsoft 365','Microsoft Teams','Yahoo'"
  icalFileName="fort-ross-road-ramble"
  timeZone="America/Los_Angeles"
  buttonStyle="date"
  size="5"
  lightMode="bodyScheme"
></add-to-calendar-button>

[jekuer]

Can you share more details on your use case behind this?
We are currently not allowing for line breaks in the location, as this is not supported by calendar providers (at least almost all of them).

[pleasantone]

Here's what I'm trying to reproduce, this was generated by my existing code, and I'd like to move to yours since you support many calendar providers:

.ics file:

LOCATION:Peet's Coffee Northgate Mall\n5800 Northgate Dr. #146\nSan Rafael
 \, CA 94114
GEO:38.0044923;-122.5445852
DESCRIPTION:A twisty ride up to Guerneville and north featuring Fort Ross 
 Rd. and Kruse Ranch Rd.\nExpect up to 4 miles of well groomed dirt roads.\
 n
URL;VALUE=URI:http://localhost:1313/events/2023/07/fort-ross-road-ramble/

This is perfectly legal, per the RFC on the standard, and is preferred by Mac/iOS calendar and 3rd party calendars like Fantastical.
Location uses the two-character sequence backslash-n to indicate newlines breaks. [Additionally, I get the opportunity to also provide a GEO field of lat/lon which is part of the ICS standard and allows these clients to quickly put up a map of the location. Also, I'm allowed to fill in a separate URL field different from a URL in location, which may indicate the URL of the page that generated the calendar entry (or a URL for the event, such as a zoom links).]

In the code here, it looks like it was your intent to allow backslash-backslash-n \\n to be a newline separator for the .ICS file

content = content.replace(/\\/g, '\\\\').replace(/(,|;)/g, '\\$1').replace(/\\\\n/g, '\\n');

However, due to HTML escaping, there is no sequence of characters that will allow that to be generated. One would think:
\\\\n would (\\ + \\n) but I think it gets translated internally into \\\\\\\\n in the first replace. (If you just do \\\n you get an actual newline in the .ICS file which is illegal. I was asking this question to figure out your intent on what the proper character set would be, and suggested allowing [br] in location as an alternate just so we could eliminate all the escaping craziness.

Well, for calendar providers that can't handle line breaks in that field, we could substitute ", " for a line break, it seems silly to hamstring everyone for the lack of ability in one.

So I guess I'm asking you to consider:

1. write the escape replace code to allow '\\n' to work
2. allow '[br]' to be an alias for newline
3. for providers that can't handle newline, translate newline to comma-space ,
4. [optionally] support the GEO field in ICS
5. [optionally] support the URL field in ICS separate from location

[pleasantone]

As a workaround, I have moved to using ", " as a substitute in my own generator, so all of this is nice-to-have, for producing better parsable calendar entries, not critical.

[jekuer]

As said, line breaks are currently not supported for location at all. The replacements are there to sanitize the input (basically explicitly blocking what you were trying to do 😉). We block any line break intents even earlier in the code.

I tested your case in multiple scenarios. The thing is, even outlook (which would be the main case for ics usage) does not support line breaks within the location, which leads to wrong output.
So, bottom line, unfortunately, we need to reject that part, as it would come with a huge overhead of problems for almost all users (especially since we cannot make sure which tool the user uses to open the ics file), only benefiting a very niche use case. The way forward would be rather to add Fantastical as calendar type and then maybe offer this functionality only for them.

Will still have a look at GEO and URL for future releases.

[pleasantone]

Understood, thank you.

…

On Jan 22, 2024 at 11:13 AM -0800, Jens Kuerschner ***@***.***>, wrote: As said, line breaks are currently not supported for location at all. The replacements are there to sanitize the input (basically explicitly blocking what you were trying to do 😉). We block any line break intents even earlier in the code. I tested your case in multiple scenarios. The thing is, even outlook (which would be the main case for ics usage) does not support line breaks within the location, which leads to wrong output. So, bottom line, unfortunately, we need to reject that part, as it would come with a huge overhead of problems for almost all users (especially since we cannot make sure which tool the user uses to open the ics file), only benefiting a very niche use case. The way forward would be rather to add Fantastical as calendar type and then maybe offer this functionality only for them. Will still have a look at GEO and URL for future releases. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>