Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now.
The one I am concerned about is in repr-io.cpp, in sp_repr_read_file
I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.
On Fri, 4 Feb 2005, Jon A. Cruz wrote:
Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now.
The one I am concerned about is in repr-io.cpp, in sp_repr_read_file
I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.
After the Hard Freeze, bugfix patches can still be accepted but they'll need to be more rigorously reviewed than normal. So, if you think it's important for the 0.41 release, definitely go ahead with the work, but you will need to prepare it as a patch for Kees and Bulia to review and to check into CVS.
Bulia and Kees will have their own criteria for what to accept, but I expect they'll judge based on a) does it fix a real problem that users will encounter otherwise? b) is it a simple fix, or could it engender other bugs? c) is it well thought out, or just a hack?
Realize that we never promise users that any Inkscape release is bug-free, and that in addition to fixing bugs, we also have the ability to simply list them as "Known Issues" in the ReleaseNotes. So if you're uncertain about the fix, but understand the problem, just document it, and leave the fix for our next release. :-)
Bryce
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. Not sure quite what the evilness is of the code in question is, but unless its very clearly breaking things for people right now I'd let it wait until 0.42. btw, we dont rely on an external gzip binary on windows, we use the zlib dll, the problem we'd had was due to the libxml dll not being linked with the optons to use the zlib. I've tried getting the gzip route used int the inx to work and its pure unadulterated evil, as the extensions code has hardcoded linux style temp filenames in it. this is a potential issue for a bunch of extension related stuff. (src\extensions\script.cpp if anyones interested) Its been on my list of things to do some testing with, I just havent got round ot it.
Cheers
John
--- "Jon A. Cruz" <jon@...18...> wrote:
Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now.
The one I am concerned about is in repr-io.cpp, in sp_repr_read_file
I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
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.
On Sat, 05 Feb 2005 11:34:34 -0800, Jon A. Cruz <jon@...18...> wrote:
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.
And please do this only after 0.41 is out because:
The net result would be a) Windows users could load filenames that aren't in the 8-bit local encoding.
This seems like a very unfrequent operation to me. In fact I'm not even sure how to get such filenames on Windows.
b) Windows users would have .svgz working without relying on tricky link/build magic between libxml2 and zlib.
This tricky magic seems to work at this point of time, so let's not break it, at least not for the release.
On Sat, 2005-02-05 at 15:14, bulia byak wrote:
This seems like a very unfrequent operation to me. In fact I'm not even sure how to get such filenames on Windows.
Scenario: You send me a .zip file containing an SVG project with cyrilic filenames. I'm in a US-ASCII locale.
-mental
On Sat, 05 Feb 2005 17:53:11 -0500, MenTaLguY <mental@...3...> wrote:
On Sat, 2005-02-05 at 15:14, bulia byak wrote:
This seems like a very unfrequent operation to me. In fact I'm not even sure how to get such filenames on Windows.
Scenario: You send me a .zip file containing an SVG project with cyrilic filenames. I'm in a US-ASCII locale.
1) a rather far-fetched situation; 2) I think an archiver must store filenames in Unicode, otherwise it's bound to break without Inkscape's help; 3) Jon was speaking about Windows, and we are both using Linux :)
And 4) I'm not against this in principle, I just don't want to change anything for the release. We're in a hard freeze, remember?
bulia byak wrote:
And 4) I'm not against this in principle, I just don't want to change anything for the release. We're in a hard freeze, remember?
Since the fix was mainly a "for Bulia" thing to begin with, I'm happy to wait if he's satisfied with things at the moment.
(Oh, and a more likely scenario is a Japanese user having issues and following the GIMP Win32 FAQ to switch the GTK+ locale to English while still running on their Japanese XP system)
bulia byak wrote:
And 4) I'm not against this in principle, I just don't want to change anything for the release. We're in a hard freeze, remember?
BTW, fixing that the way I proposed is probably just the mirror of the work needed to fix this
[ 1074996 ] can't save svgz with non-latin names
So once we're unfrozen and 0.41 is out, I'll go ahead and address this too
On Sat, Feb 05, 2005 at 10:41:54PM -0800, Jon A. Cruz wrote:
BTW, fixing that the way I proposed is probably just the mirror of the work needed to fix this
[ 1074996 ] can't save svgz with non-latin names
So once we're unfrozen and 0.41 is out, I'll go ahead and address this too
This is still a problem in 0.41pre1. I think it's a simple fix, though.
(and, this does _not_ get fixed if I run against the gimp-installed GTK libraries)
On Sun, 6 Feb 2005 10:53:48 -0800, Kees Cook <inkscape@...62...> wrote:
[ 1074996 ] can't save svgz with non-latin names
So once we're unfrozen and 0.41 is out, I'll go ahead and address this too
This is still a problem in 0.41pre1. I think it's a simple fix, though.
(and, this does _not_ get fixed if I run against the gimp-installed GTK libraries)
OK, if it's simple, can you please send me a patch for review?
On Sun, Feb 06, 2005 at 02:58:35PM -0400, bulia byak wrote:
OK, if it's simple, can you please send me a patch for review?
Well, it turned less simple _looking_, but it is simple. :)
This separates "home dir" from "profile location". (But uses all the same code, it's just relocated.) And it fixes the three places where "g_get_home_dir()" is used (which isn't utf8-safe), and catches the gtk_file_selection_get_filename call (which isn't utf8-safe).
I'd really like to see this get in, as it would seem to close all our known locale/path bugs under win32.
On Sun, 6 Feb 2005 11:46:12 -0800, Kees Cook <inkscape@...62...> wrote:
I'd really like to see this get in, as it would seem to close all our known locale/path bugs under win32.
OK, I'll review it, but do you know of a win32 build with this patch in, so I could test it (I don't have windows cross compiling set up at the moment)?
On Sun, Feb 06, 2005 at 03:56:16PM -0400, bulia byak wrote:
OK, I'll review it, but do you know of a win32 build with this patch in, so I could test it (I don't have windows cross compiling set up at the moment)?
Okay, ignore the version on it (it's pre1 + the patch):
http://outflux.net/inkscape/Inkscape-0.41pre1.win32.exe
On Sun, 6 Feb 2005 14:58:35 -0400, bulia byak <buliabyak@...400...> wrote:
On Sun, 6 Feb 2005 10:53:48 -0800, Kees Cook <inkscape@...62...> wrote:
[ 1074996 ] can't save svgz with non-latin names
Kees, your patch does not fix this bug, and does not touch save code at all. What exactly does it fix?
On Sun, Feb 06, 2005 at 06:47:11PM -0400, bulia byak wrote:
On Sun, 6 Feb 2005 14:58:35 -0400, bulia byak <buliabyak@...400...> wrote:
On Sun, 6 Feb 2005 10:53:48 -0800, Kees Cook <inkscape@...62...> wrote:
[ 1074996 ] can't save svgz with non-latin names
Kees, your patch does not fix this bug, and does not touch save code at all. What exactly does it fix?
Fixed it for me under win2k, using a path with an umlaut in it. What's your usage case?
On Sun, 6 Feb 2005 15:14:27 -0800, Kees Cook <inkscape@...62...> wrote:
On Sun, Feb 06, 2005 at 06:47:11PM -0400, bulia byak wrote:
On Sun, 6 Feb 2005 14:58:35 -0400, bulia byak <buliabyak@...400...> wrote:
On Sun, 6 Feb 2005 10:53:48 -0800, Kees Cook <inkscape@...62...> wrote:
[ 1074996 ] can't save svgz with non-latin names
Kees, your patch does not fix this bug, and does not touch save code at all. What exactly does it fix?
Fixed it for me under win2k, using a path with an umlaut in it. What's your usage case?
Hmm, actually the original bugreport was about Linux, and it still fails with the same error:
Extension::Script: Unknown error attempting to open temporary file : Invalid or incomplete multibyte or wide character /tmp/ink_ext_CyX8M6: No such file or directory
Will test Windows now.
On Sun, Feb 06, 2005 at 06:47:11PM -0400, bulia byak wrote:
On Sun, 6 Feb 2005 14:58:35 -0400, bulia byak <buliabyak@...400...> wrote:
On Sun, 6 Feb 2005 10:53:48 -0800, Kees Cook <inkscape@...62...> wrote:
[ 1074996 ] can't save svgz with non-latin names
Kees, your patch does not fix this bug, and does not touch save code at all. What exactly does it fix?
Er.. sorry, I replied to totally the wrong email. My patch fixes THIS bug:
[ 1114714 ] "Invalid UTF8 string" error in bitmap export file name
On Sun, Feb 06, 2005 at 10:53:48AM -0800, Kees Cook wrote:
On Sat, Feb 05, 2005 at 10:41:54PM -0800, Jon A. Cruz wrote:
BTW, fixing that the way I proposed is probably just the mirror of the work needed to fix this
[ 1074996 ] can't save svgz with non-latin names
So once we're unfrozen and 0.41 is out, I'll go ahead and address this too
This is still a problem in 0.41pre1. I think it's a simple fix, though.
And here's the patch for 1074996. I'll get it built in a bit...
On Sun, 6 Feb 2005 16:43:56 -0800, Kees Cook <inkscape@...62...> wrote:
And here's the patch for 1074996. I'll get it built in a bit...
I'm thrilled that these bugs are being fixed, but I'm very concerned about the patches which look pretty complex. At this point in time we should only accept one-line fixes for critical bugs. Those bugs are certainly not critical. So, I appreciate your efforts, but let's play it safe and wait until 0.41 is out. I don't want the unpleasant experience of 0.38.1 to repeat.
Or, if we accept these patches, we need to wait at least a couple days more in the hard freeze mode.
On Sun, Feb 06, 2005 at 08:52:14PM -0400, bulia byak wrote:
I'm thrilled that these bugs are being fixed, but I'm very concerned about the patches which look pretty complex. At this point in time we
I'm fine with that. We'll just note it in the "known problems" section.
should only accept one-line fixes for critical bugs. Those bugs are
And in the interests of a one-line fix, how about this, which is a debug printf, it looks like. This happens when I looked at the new About screen that Andy posted to jabber. I like it, it's much more colorful, I'd like to see it in 0.41.
[01:18:47] <Andy> hey guys ... I noticed how slow / ugly the .41 about.svg is ..... would http://andy.fitzsimon.com.au/newabout.svg be any better ? similar style just faster rendering and more colour
see attached patch...
On Sun, 6 Feb 2005 17:03:14 -0800, Kees Cook <inkscape@...62...> wrote:
And in the interests of a one-line fix, how about this, which is a debug printf, it looks like.
This one is OK to apply.
This happens when I looked at the new About screen that Andy posted to jabber. I like it, it's much more colorful, I'd like to see it in 0.41.
Personally, I don't like it. Dirtyness and randomness don't seem to go well with the colorfulness. It's too loud, crude, and childish, and seems to be done in a haste. The previous one was at least consistent in its style, and I much prefer that consistency. (Sorry Andy, you know I love to criticize your work :)
On Sat, Feb 05, 2005 at 10:41:54PM -0800, Jon A. Cruz wrote:
BTW, fixing that the way I proposed is probably just the mirror of the work needed to fix this
[ 1074996 ] can't save svgz with non-latin names
So once we're unfrozen and 0.41 is out, I'll go ahead and address this too
Okay, sorry. I'm not even given the _option_ to save SGVZ under windows. :)
you need gzip in your path somewhere, and it needs to be named gzip not gzip.exe You may also need to have a c:\tmp folder.
--- Kees Cook <inkscape@...62...> wrote:
On Sat, Feb 05, 2005 at 10:41:54PM -0800, Jon A. Cruz wrote:
BTW, fixing that the way I proposed is probably just the mirror of
the
work needed to fix this
[ 1074996 ] can't save svgz with non-latin names
So once we're unfrozen and 0.41 is out, I'll go ahead and address
this too
Okay, sorry. I'm not even given the _option_ to save SGVZ under windows. :)
-- Kees Cook @outflux.net
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Fri, 04 Feb 2005 20:30:38 -0800, Jon A. Cruz <jon@...18...> wrote:
The one I am concerned about is in repr-io.cpp, in sp_repr_read_file
I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.
So what exactly you want to change? Where's the patch?
As for me, I tried replacing xmlParseFile with xmlReadFile for the purpose of reading external DTD subset, but this didn't quite work out, so I left it as is.
participants (6)
-
Bryce Harrington -
bulia byak -
John Cliff -
Jon A. Cruz -
Kees Cook -
MenTaLguY