However, the downloaded source has white space in front of the initial text of the listing, which causes Google calendars to reject the file:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//iCal title//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:20140309
DTEND:20140314
SUMMARY: Protein Transport Across Cell Membranes
LOCATION:Galveston, TX, United States
END:VEVENT
Hmm, we are on 4.18.2 and have a identical iCal Design asset that works correctly with no whitespace.
Did you make sure to NOT have a hard return after the body design area?
As far as I can tell - I assiduously deleted anything that might have been whitespace at the end of the quoted design. I've also generated a parse file with no final linefeed and imported that into a new Design - same result.
On looking a little more closely, that whitespace is actually two TAB characters. I've checked that all whitespace in my parse file is single space characters.
Might it have anything to do with my web server (Apache 2.2.3 on CentOS)? Nothing obvious in its .conf file. My primary website sits behind a Squid reverse proxy, but applying the same design to another site that serves content directly also shows the same behaviour.
The only thing that I can think of is that our iCal Parse File has been around for years and never changed, so maybe we created it years ago when there was no bug, and it has never been re-parsed since.
(note that spurious "X" xharacter just before the BODY design area), then the result I get begins:
0000000 X \n \t \t B E G I N : V C A L E N
i.e. a newline after the "X" (though there's none in the parse file) and then again those two tabs. Doesn't this suggest that they're being introduced in the rendering of the BODY design area?
Not sure why this would be happening, can't replicate on my end. The last thing would be to try and crate a brand new parse file, just add the body tag, don't add a paint layout, and apply it to a standard page and test.
What database software and version are you running on this system?
Not sure why this would be happening, can't replicate on my end. The last thing would be to try and crate a brand new parse file, just add the body tag, don't add a paint layout, and apply it to a standard page and test.
What database software and version are you running on this system?
Sorry for the delay in replying - been away for a few days. As expected (almost), I get two tabs and a newline before the <DOCTYPE> tag.
The DB/PHP version shouldn't really be relevant to this type of problem due to the way it compiles.
@Brian Can you try a completely fresh site asset (on an alternate domain name, doesn't have to really exist) with only this design applied, public permission granted, everything live and then use curl/xxd to render the contents, e.g I get:
You'll need to execute the curl on the server running Matrix and connect to the port apache (not Squid) is running on, the custom header is supplied to let you connect to whatever domain you create.
Basically I'm just trying to isolate it from everything as there's a chance you're still inheriting a paint layout from somewhere or something else we're missing.
The DB/PHP version shouldn't really be relevant to this type of problem due to the way it compiles.
@Brian Can you try a completely fresh site asset (on an alternate domain name, doesn't have to really exist) with only this design applied, public permission granted, everything live and then use curl/xxd to render the contents, e.g I get:
You'll need to execute the curl on the server running Matrix and connect to the port apache (not Squid) is running on, the custom header is supplied to let you connect to whatever domain you create.
Basically I'm just trying to isolate it from everything as there's a chance you're still inheriting a paint layout from somewhere or something else we're missing.
Sorry for the delay in replying to this - I had noticed the reference to an apparently relevant bug fix in 4.18.6 but had experienced some difficulties in upgrading. Finally got this done today.
After the upgrade, I did perform your suggested test, and was initially disappointed to get the same result as before (two leading tabs). However, on reopening the existing barebones design parse file, ensuring (yet again) that there was no extraneous whitespace, and then saving, I now find that the problem has gone away. Looks like that upgrade has cured this.
Many thanks to you and Bart for your interest in pursuing this.