Status of priority-6 bugs for 0.36 release
All of the priority 9 bugs and all of the bugs listed on the roadmap for required the 0.36 release have been resolved and closed.
(It's been pretty amazing how much intensity was placed into bug fixing this last week; 20 bugs closed!)
The remaining priority-6 bugs are listed and commented on below. My thought was that the priority-6 bugs "would be nice to close" but were not required. We've closed a number of them, and I think the remainder can be left for a future release. If anyone feels differently on any of these, speak up now.
Bryce
[ 851467 ] Export selection bounds too small
There is a patch for this that John Stracke is developing for Sodipodi. If we wait a tad longer it might become more matured. See Sodipodi Bug#758775 for the patch.
[ 841633 ] Icons problem for win32
I'd like to get confirmation that this still occurs, as I suspect the GtkButton rework may have resolved it. It doesn't cause a crash and sounds like its platform dependent, though. If the problem still exists, then it should be made high priority for the next release.
[ 850936 ] .32 crashes when setting printer destination
It no longer crashes but it does emit an ERROR message. This should receive high priority in the next release but may be acceptable for 0.36.
[ 853804 ] SVG COMPLIANCE: Paths shown will fill when fill:none
The issue is that "file: none;" and "fill:none;" behave differently for the given case. This is important for importing SVG but perhaps one we can leave 'til next release as it doesn't impact general use.
[ 852619 ] XML editor crash
There are a couple XML editor related bugs, but they appear unrelated. This particular bug is uncovered after a sequence of steps that may not be encountered by most users in general usage.
[ 50549 ] spiral crash
This is an easy bug to reproduce, however the spiral shape does not seem like one that would normally get heavy use.
[ 847886 ] transformation inaccuracies
The change from float to double addressed part of the bug, the remainder appears to be a legitimate issue but may not be noticeable to regular users.
[ 851937 ] Postscript file output does not respect document size
More of a feature request than a bug, I think.
[ 851131 ] Print preview does nothing
I'm not sure if print preview is implemented, as it's never worked for me. I've commented out the menu item. If this *does* work for anyone, let me know so we can leave it in but mark it a 'known issue', and get it fixed. Otherwise we should list high on the feature request list.
[ 853858 ] errors when copying objects between docs
Bulia estimates this will require too much effort to fix for 0.36. It's listed as a known issue on the release notes page.
[ 850971 ] Crash while deleting too much using the XML editor
This bug is in regards to deleting the sodipodi namedview element via the XML editor. I looked into the code to see if there was an easy way to trap it but to do it right it looks like it would take some research. Since it's an unusual error I don't think a quick fix would be appropriate, and some time should be taken during the next release cycle to find a good solution.
[ 851779 ] Style property "currentColor" not used properly
This is another compliance issue for importing SVG files. Specifically, from gnuplot.
Hello,
[ 841633 ] Icons problem for win32
I'd like to get confirmation that this still occurs, as I suspect the GtkButton rework may have resolved it. It doesn't cause a crash and sounds like its platform dependent, though. If the problem still exists, then it should be made high priority for the next
release.
It still exists for some icons (ex. for join/cap, and tab icon for fill,stroke,..). As a quick fix for my own build I've added code to save and restore current dir before and after an open or save file.
But there are two more annoying and *very visible* bugs with win32 , at least for non english users with a comma as decimal separator (too bad I'm in this category :)
1- When the regional setting uses comma instead of dot for decimal separator (ie numbers are 234,23 instead of 234.23) inkscape appears totally broken (random lines when drawing, gradient fill not functionning..). There is a " setlocale (LC_NUMERIC, "C"); " that is supposed to fix this but somewhere later the program switch back to the locale setting ..(I can see it still uses comma in the console output)
2- Font problem. See previous posts about this one and the possible cause
M
On Tue, 2003-12-09 at 02:32, Mael wrote:
Hello,
[ 841633 ] Icons problem for win32
I'd like to get confirmation that this still occurs, as I suspect the GtkButton rework may have resolved it. It doesn't cause a crash and sounds like its platform dependent, though. If the problem still exists, then it should be made high priority for the nextrelease.
It still exists for some icons (ex. for join/cap, and tab icon for fill,stroke,..). As a quick fix for my own build I've added code to save and restore current dir before and after an open or save file.
I think the best fix is probably to move the logic into SPIcon rather than having the path explicitly specified everywhere at all. That will touch a lot of code in the process.
But there are two more annoying and *very visible* bugs with win32 , at least for non english users with a comma as decimal separator (too bad I'm in this category :)
1- When the regional setting uses comma instead of dot for decimal separator (ie numbers are 234,23 instead of 234.23) inkscape appears totally broken (random lines when drawing, gradient fill not functionning..). There is a " setlocale (LC_NUMERIC, "C"); " that is supposed to fix this but somewhere later the program switch back to the locale setting ..(I can see it still uses comma in the console output)
It looks to me like the printf() family on Win32 doesn't respect Unix-style locale environment variables. The only fix is to replace them with our own non-locale-dependent code.
2- Font problem. See previous posts about this one and the possible cause
The font problem is likely the result of the strings "italic" etc. being improperly localized, so they don't match the "style" font property as returned by nr_typeface_w32_attribute_get.
Alternately, if we ditch Sodipodi's libnrtype in favor of Pango, we can at least be assured that Pango gets it correct in the first place.
This is a difficult situation. I've filed high-priority bugs on these, but it looks like the fixes for them are fairly invasive and we're getting overdue for another release.
How do you all feel about this? Should we:
1. Delay the release until these are fixed
2. Release anyway, but don't do a win32 release build for this version
3. Go ahead and release builds for all platforms
In any case, if we don't fix these bugs for this release, they should be mandatory fixes for 0.37, which is designated for bugfixing and code cleanup.
-mental
On Tue, 9 Dec 2003, MenTaLguY wrote:
On Tue, 2003-12-09 at 02:32, Mael wrote:
Hello,
[ 841633 ] Icons problem for win32
I'd like to get confirmation that this still occurs, as I suspect the GtkButton rework may have resolved it. It doesn't cause a crash and sounds like its platform dependent, though. If the problem still exists, then it should be made high priority for the nextrelease.
It still exists for some icons (ex. for join/cap, and tab icon for fill,stroke,..). As a quick fix for my own build I've added code to save and restore current dir before and after an open or save file.
I think the best fix is probably to move the logic into SPIcon rather than having the path explicitly specified everywhere at all. That will touch a lot of code in the process.
Okay then let's make it high priority for 0.37 but leave it as is for this coming release.
But there are two more annoying and *very visible* bugs with win32 , at least for non english users with a comma as decimal separator (too bad I'm in this category :)
1- When the regional setting uses comma instead of dot for decimal separator (ie numbers are 234,23 instead of 234.23) inkscape appears totally broken (random lines when drawing, gradient fill not functionning..). There is a " setlocale (LC_NUMERIC, "C"); " that is supposed to fix this but somewhere later the program switch back to the locale setting ..(I can see it still uses comma in the console output)
It looks to me like the printf() family on Win32 doesn't respect Unix-style locale environment variables. The only fix is to replace them with our own non-locale-dependent code.
I have some code that we may want to consider using, that would also help us with better rounding capabilities and such. I'd be happy to dig it out and add it to the codebase for the next release, although I'd appreciate it if someone could code-review it.
2- Font problem. See previous posts about this one and the possible cause
The font problem is likely the result of the strings "italic" etc. being improperly localized, so they don't match the "style" font property as returned by nr_typeface_w32_attribute_get.
Alternately, if we ditch Sodipodi's libnrtype in favor of Pango, we can at least be assured that Pango gets it correct in the first place.
Hmm, fixing the localization should not be too difficult, should it? It sounds like that might be a better solution than moving up the change over to Pango; I'm sure that'll open a variety of other issues for us. ;-)
This is a difficult situation. I've filed high-priority bugs on these, but it looks like the fixes for them are fairly invasive and we're getting overdue for another release.
How do you all feel about this? Should we:
Delay the release until these are fixed
Release anyway, but don't do a win32 release build for this version
Go ahead and release builds for all platforms
In any case, if we don't fix these bugs for this release, they should be mandatory fixes for 0.37, which is designated for bugfixing and code cleanup.
Actually 0.37 is just code cleanup and C++-ification; 0.38 will be the big Bug Hunt release. But I agree these should be high priority for 0.37.
I don't think we should hold up 0.36; our goal was to introduce a lot of change, which we've done, not to be perfect. We'll make a line in the sand here, and over the next few releases work at ratcheting up quality notch by notch. With the bug management work done for this release we have a handle on what needs to be done. It might take several releases but I'm confident that Inkscape is going to become extremely robust.
Bryce
MenTaLguY wrote:
I think the best fix is probably to move the logic into SPIcon rather than having the path explicitly specified everywhere at all. That will touch a lot of code in the process.
Or...
It might be best to have it in some factory method. It might be that SPIcon shouldn't know about the context of how it is used, but also that the current using code shouldn't know about path details either. Thus often a factory method in the middle can give the best encapsulation.
participants (4)
-
Bryce Harrington -
Jon A. Cruz -
Mael -
MenTaLguY