Closed triemstr closed 14 years ago
I took another look and the binary encoded output was almost identical between the versions, but upon close inspection 0.5.1 did have a few different characters.
That's awfully strange. What browser is this? It would be great if you could link to a screenshot of the splotchy purple image.
Here's a link to the combined diff from 0.4.4 to 0.5.1:
http://github.com/documentcloud/jammit/compare/0.4.4...0.5.1
There isn't any special library we're using to encode the images. It's a simple matter of reading the contents of the file in, and base64 encoding it. Nothing fancy, and that process didn't change.
I tried it tonight on a Windows Vista, 32 bit dev box. Once again, 0.4.4 works fine.
For both my Windows machines, it looks funny in Firefox 3.6.7 and IE 8.
vs
-removed link since no longer valid-
See Lines 202-204ish:
http://github.com/documentcloud/jammit/commit/855a4a39fc8a86f5437a1b6a54d169a85bd0bd6e
When using 0.4.4, if I change those lines to this 0.5.1 version, then it gets screwed up. If you are not seeing this problem on linux, then it must be the lack of the 'b' for 'binary' that we have lost which only works on windows/dos according to: http://www.techotopia.com/index.php/Working_with_Files_in_Ruby
Yikes. That's a nasty windows bug indeed. Here's the patch:
http://github.com/documentcloud/jammit/commit/eb3ecae70deb92bfcb587de4792122ebd0918f64
Closing the ticket. My apologies.
Thanks...
I installed jammit 0.5.1, re-created assets, and loaded up my server.
Unfortunately, the embedded css images no longer load correctly. What used to be a brown image is now splotchy and purple. Was something changed with the embedded encoding? Perhaps a library was removed that was supposed to help?
I downgraded to 0.4.4 and jammit worked correctly again.
BTW, I'm running this on Windows 7, 64 bit, but 0.4.4 works fine.