tablegear.css UTF-8 encoded by mistake?

[Paul Traina]

Andrew,
I noticed in both 1.6.1 and 1.6.2 that tablegear.css is UTF-8 and CRLF
encoded. This might have been deliberate in the past if you were
trying to encode funky characters like caret in the CSS, but it
doesn't seem to be necessary now.

I found this causing me a problem when generating e-mail versions of
the reports, where I had my .php including the .css file to make the e-
mail message self-contained, instead of just passing a link back to
the server to load the .css file.

I've fixed it in my local copy (tail -c+8 stylesheets/tablegear.css |
tr -d '\r' >stylesheets/tablegear.css.new) but it would be awesome if
you consider reverting your distribution copy back to standard ascii
like all the other files in future releases.

Much thanks for all your work on 1.6.2! Looking forward to seeing the
release notes. All the previous issues I reported (sorting,
pagination) have been fixed, I have not tested editable cell write
failures, is most likely my issue, but will follow-up in a separate
message.

Best,

Paul

[Andrew Plummer]

Well it's definitely my policy to have everything UTF8 encoded. There's no reason not to, and I'm always primarily concerned with multi-lingual multi-encoding issues.  If you need special encoding other than utf8 you'll just have to convert.  As for CRLF yeah I'd like to go with only unix line breaks but there's been some discrepancy probably because I was using windows before.. I'll get around to changing that when I get a chance...

Andrew