John Cliff wrote:
Jon, was just reading the jabber logs of your conversation with mental wrt to this, and if i got what you were saying it sounded like the fix you were proposing was reverting to the svgz extension rather than using libxml's internal routines. I'm pretty much certain that that course of action would completely break svgz on windows, as the extension requires gzip which isnt available on 99% of peoples windows boxes.
Ahh... that was actually not what I was proposing, but what happened as a fall-back when I got half the linux changes in.
I'd done the initial work and gotten a base change from xmlParseFile to xmlReadIO. Since the latter no longer had the internal gzip detection and use, sp_repr_read_file then failed. Since it failed, the extensions were tried and the external gzip call kicked in.
So... what I was going to do was put gzip decompression in the loader I have feeding xmlReadIO. That will correctly handle .svgz files with no external calls. I'm just going to get it done with the cleanest code possible. (I already have the detection of compressed data in)
Additionally, since it is a very new change (and thus 'unsafe') I was going to make the behavior switchable using a preference and a run-time switch. Additionally, to keep the impact to a minimum, I'm planning on making it default to use the old loading on anything but windows.
On reason I want to use a switch is that sp_repr_read_file is used for loading the preferences, so if we can't load the prefs, then there's no point trying to fix loading in the prefs themselves. :-)
The net result would be a) Windows users could load filenames that aren't in the 8-bit local encoding. b) Windows users would have .svgz working without relying on tricky link/build magic between libxml2 and zlib.