New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sign in sheets are omitting some performances #592

Open
CHTJonas opened this Issue Jan 31, 2019 · 6 comments

Comments

Projects
None yet
3 participants
@CHTJonas
Copy link
Member

CHTJonas commented Jan 31, 2019

The HTML and CSV sign in sheet generators appear to be omitting any performances which occur on a Saturday eg. https://www.camdram.net/shows/2019-legally-blonde/signinsheet. Reported to me by Jacob Baldwin and posted on his behalf as he doesn't have a GitHub account 😛

Additionally, the CSV sheets when viewed in Microsoft Excel (which is probably the first application most people will turn to when wanting to edit/print them) contain a string of random garbage in the header eg. Sign-in sheet for The Children's Hour (16/10/2018–19/10/2018 – generated by Camdram that isn't present in the original eg. curl https://www.camdram.net/shows/2018-the-childrens-hour/signinsheet.csv. From what I can tell using the Excel import CSV dialogue (as opposed to simply opening the file with Excel directly from Windows Explorer) it's because the character encoding is detected as Windows-1252 and not UTF-8.

@GKFX

This comment has been minimized.

Copy link
Member

GKFX commented Jan 31, 2019

Re encodings: my view is that we should be using UTF-8 and Excel is just wrong! However that doesn’t really solve the problem; perhaps we could output to xlsx/ods and then we’d be able to benefit from proper cell merging etc too.

@CHTJonas

This comment has been minimized.

Copy link
Member Author

CHTJonas commented Jan 31, 2019

Yeah I agree. The file itself is detected as UTF-8 with LF new lines in my text editors so I'm not sure why Excel is throwing it's toys out of the pram. It's maybe possible we're not following the RFC quite as well as we should?

@CHTJonas

This comment has been minimized.

Copy link
Member Author

CHTJonas commented Jan 31, 2019

So it would appear that we should actually be using CRLF for line breaks in CSV files, but I tried that and it doesn't solve the Excel issue...

@philosophicles

This comment has been minimized.

Copy link
Member

philosophicles commented Jan 31, 2019

@CHTJonas

This comment has been minimized.

Copy link
Member Author

CHTJonas commented Jan 31, 2019

I managed to fix this in a somewhat hacky way using WSL:

echo -n "\xEF\xBB\xBF" > /mnt/c/Users/charlie.jonas/Downloads/bugfix.csv
cat /mnt/c/Users/charlie.jonas/Downloads/signinsheet.csv >> /mnt/c/Users/charlie.jonas/Downloads/bugfix.csv

Apparently there's some known Excel weirdness, and we need to include the UTF-8 byte order mark in the generated output:

CHTJonas added a commit that referenced this issue Jan 31, 2019

@philosophicles

This comment has been minimized.

Copy link
Member

philosophicles commented Feb 1, 2019

Ahhhhhhh this must be why I often find BOMs in various work third-party CSVs that are just a PITA for my non-spreadsheet workflow... 💡

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment