Status - Inkscape 0.46.0-1 Windows Package
I. Rygle, that round-up of Windows issues is quite handy!
II. Patches included so far
#179988 01_win32_printing.patch ?????? 02_win32_print_dialog_parent_window.patch (from Joel; no LP#) #183646 03_vista_turn_off_dashes.patch #168896 05_save_as_xaml.patch:
III. Patches/bugs not included due to problems
#165726 04_win32_remove_dialogs_on_top_preference.patch Fails to apply. See bug for details. #204779: ?? Not sure what to do here. A late comment refs to a patch in #187290 so maybe that patch needs inclusion? #187290: ?? I'm unclear if the patch here (comment #34) is ready, or needs additional testing/fixing.
IV. New Windows patch packaging system
I've added a debian-like patch setup for managing Windows patches. In other words, rather than apply patches directly, they are placed in inkscape/packaging/win32/patches/ and listed in the 'series' file in that directory. I've also written a simple script to apply the patches:
cd /packaging/win32/ && ./apply_patches.sh
This will need to be done by the Windows packagers when building 0.46.0 Windows packages (perhaps some scripts could be updated to include this step). Please someone update the Win32 docs to reflect this.
This may seem weird compared with just committing the patches directly onto the stable branch, however this is standard operating procedure on Linux distros, and makes managing the patches and future updates easier. By keeping the patches only applied for Windows, it also completely avoids the risk of windows patches breaking linux code (these patches look safe, but you never know...)
This also gives the windows packagers the flexibility to do 0.46.0-2, -3, etc. releases with more patches later on if they wish.
So the basic rule is that we should have one common 0.46.0 tarball, and then each distro (including the Windows package as a distro), applies their packaging patches against it before building their packages.
When we prepare for 0.46.1, we can look into incorporating some/all of the windows (and other distro) patches.
V. Packaging and Release Announcements
As mentioned before, March 24th is the day for sending out release announcements. This means we need to get all packages (including Windows) posted ASAP. Please let me know if anyone needs additional time for packaging, in case we need to delay the PR a bit.
Bryce
On Mon, Mar 24, 2008 at 08:30:29AM -0700, rygle wrote:
A few minor improvements have been made to the Win32 printing patch, and it's as ready as I think it will get for 0.46 release. Can someone please commit it? https://bugs.launchpad.net/inkscape/+bug/179988/comments/139
Here's the latest information on printing under Win32;
Non-printing - FIXED
Default page size problems - FIXED
Print Scaling problems - FIXED
White or black boxes over printing - FIXED - GTK uses the wrong call in
Cairo (create_win32_surface, not the create_win32_printing_surface). There is a patch in the GTK bug tracker to fix this, but in the meantime we have bypassed that part of GTK. The code will revert to GTK automatically when GTK itself fixes the problem.
- All known crashes - FIXED
Adrian Johnson has patched the Cairo libs to fix a rare crash with radial gradients.
- There are two patched libs here (needs both) -
http://annarchy.freedesktop.org/~ajohnson/cairo/
- A patch has also been submitted to the Cairo git repository -
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=ae9635bf33cb989f5c525800b8...
- If the cairo dlls for inkscape are built by patching 1.5.14 instead of
building from git head Adrian recommends also getting the PostScript bug fix as well: http://gitweb.freedesktop.org/?p=cairo;a=commit;h=13e05bffd5cae5690fada24c7a...
Remaining problems with Windows printing are;
- Some blurs are misaligned/mis-scaled - see
https://bugs.launchpad.net/inkscape/+bug/205732 The workaround is to print to bitmap (under rendering in the print dialogue)
- When printing falls back to bitmap, the bitmap is not always an ideal
resolution. Again the workaround is to print to bitmap (Print -> Rendering -> Bitmap).
-- View this message in context: http://www.nabble.com/Win32-libs-tp16033417p16254450.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Bryce, I brought down the latest win build 0803241523 and tested the printing on some random scribbles.
Result: Sounds, lights, action but only a blank sheet of paper fed out. While this is better than an error message it is still not printing.
Is there a particular up-to-date build that win people can use to test the printing? Or is there something else I need to know to get printing?
PS. I also opened a pdf and tried to print it. Got an internal error message and Inkscape closed.
There must be other users such as myself who are willing to check the state of play but cannot help with the coding.
My system is win200. cheers, Erik kaver@...68...
----- Original Message ----- From: "Bryce Harrington" <bryce@...1798...> To: inkscape-devel@lists.sourceforge.net Sent: Tuesday, March 25, 2008 8:31 AM Subject: [Inkscape-devel] Status - Inkscape 0.46.0-1 Windows Package
I. Rygle, that round-up of Windows issues is quite handy!
II. Patches included so far
#179988 01_win32_printing.patch ?????? 02_win32_print_dialog_parent_window.patch (from Joel; no LP#) #183646 03_vista_turn_off_dashes.patch #168896 05_save_as_xaml.patch:
III. Patches/bugs not included due to problems
#165726 04_win32_remove_dialogs_on_top_preference.patch Fails to apply. See bug for details. #204779: ?? Not sure what to do here. A late comment refs to a patch in #187290 so maybe that patch needs inclusion? #187290: ?? I'm unclear if the patch here (comment #34) is ready, or needs additional testing/fixing.
IV. New Windows patch packaging system
I've added a debian-like patch setup for managing Windows patches. In other words, rather than apply patches directly, they are placed in inkscape/packaging/win32/patches/ and listed in the 'series' file in that directory. I've also written a simple script to apply the patches:
cd /packaging/win32/ && ./apply_patches.sh
This will need to be done by the Windows packagers when building 0.46.0 Windows packages (perhaps some scripts could be updated to include this step). Please someone update the Win32 docs to reflect this.
This may seem weird compared with just committing the patches directly onto the stable branch, however this is standard operating procedure on Linux distros, and makes managing the patches and future updates easier. By keeping the patches only applied for Windows, it also completely avoids the risk of windows patches breaking linux code (these patches look safe, but you never know...)
This also gives the windows packagers the flexibility to do 0.46.0-2, -3, etc. releases with more patches later on if they wish.
So the basic rule is that we should have one common 0.46.0 tarball, and then each distro (including the Windows package as a distro), applies their packaging patches against it before building their packages.
When we prepare for 0.46.1, we can look into incorporating some/all of the windows (and other distro) patches.
V. Packaging and Release Announcements
As mentioned before, March 24th is the day for sending out release announcements. This means we need to get all packages (including Windows) posted ASAP. Please let me know if anyone needs additional time for packaging, in case we need to delay the PR a bit.
Bryce
On Mon, Mar 24, 2008 at 08:30:29AM -0700, rygle wrote:
A few minor improvements have been made to the Win32 printing patch, and
it's
as ready as I think it will get for 0.46 release. Can someone please
commit
it? https://bugs.launchpad.net/inkscape/+bug/179988/comments/139
Here's the latest information on printing under Win32;
Non-printing - FIXED
Default page size problems - FIXED
Print Scaling problems - FIXED
White or black boxes over printing - FIXED - GTK uses the wrong call
in
Cairo (create_win32_surface, not the create_win32_printing_surface).
There
is a patch in the GTK bug tracker to fix this, but in the meantime we
have
bypassed that part of GTK. The code will revert to GTK automatically
when
GTK itself fixes the problem.
- All known crashes - FIXED
Adrian Johnson has patched the Cairo libs to fix a rare crash with
radial
gradients.
- There are two patched libs here (needs both) -
http://annarchy.freedesktop.org/~ajohnson/cairo/
- A patch has also been submitted to the Cairo git repository -
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=ae9635bf33cb989f5c525800b8...
- If the cairo dlls for inkscape are built by patching 1.5.14 instead of
building from git head Adrian recommends also getting the PostScript bug
fix
as well:
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=13e05bffd5cae5690fada24c7a...
Remaining problems with Windows printing are;
- Some blurs are misaligned/mis-scaled - see
https://bugs.launchpad.net/inkscape/+bug/205732 The workaround is to print to bitmap (under rendering in the print
dialogue)
- When printing falls back to bitmap, the bitmap is not always an ideal
resolution. Again the workaround is to print to bitmap (Print ->
Rendering
-> Bitmap).
-- View this message in context:
http://www.nabble.com/Win32-libs-tp16033417p16254450.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Mar 25, 2008 at 09:42:45AM +1100, kaver wrote:
Bryce, I brought down the latest win build 0803241523 and tested the printing on some random scribbles.
Result: Sounds, lights, action but only a blank sheet of paper fed out. While this is better than an error message it is still not printing.
Is there a particular up-to-date build that win people can use to test the printing? Or is there something else I need to know to get printing?
Ishmal will need to take this patchset and produce a windows package. AFAIK this is still TBD.
Bryce
PS. I also opened a pdf and tried to print it. Got an internal error message and Inkscape closed.
There must be other users such as myself who are willing to check the state of play but cannot help with the coding.
My system is win200. cheers, Erik kaver@...68...
----- Original Message ----- From: "Bryce Harrington" <bryce@...1798...> To: inkscape-devel@lists.sourceforge.net Sent: Tuesday, March 25, 2008 8:31 AM Subject: [Inkscape-devel] Status - Inkscape 0.46.0-1 Windows Package
I. Rygle, that round-up of Windows issues is quite handy!
II. Patches included so far
#179988 01_win32_printing.patch ?????? 02_win32_print_dialog_parent_window.patch (from Joel; no LP#) #183646 03_vista_turn_off_dashes.patch #168896 05_save_as_xaml.patch:
III. Patches/bugs not included due to problems
#165726 04_win32_remove_dialogs_on_top_preference.patch Fails to apply. See bug for details. #204779: ?? Not sure what to do here. A late comment refs to a patch in #187290 so maybe that patch needs inclusion? #187290: ?? I'm unclear if the patch here (comment #34) is ready, or needs additional testing/fixing.
IV. New Windows patch packaging system
I've added a debian-like patch setup for managing Windows patches. In other words, rather than apply patches directly, they are placed in inkscape/packaging/win32/patches/ and listed in the 'series' file in that directory. I've also written a simple script to apply the patches:
cd /packaging/win32/ && ./apply_patches.sh
This will need to be done by the Windows packagers when building 0.46.0 Windows packages (perhaps some scripts could be updated to include this step). Please someone update the Win32 docs to reflect this.
This may seem weird compared with just committing the patches directly onto the stable branch, however this is standard operating procedure on Linux distros, and makes managing the patches and future updates easier. By keeping the patches only applied for Windows, it also completely avoids the risk of windows patches breaking linux code (these patches look safe, but you never know...)
This also gives the windows packagers the flexibility to do 0.46.0-2, -3, etc. releases with more patches later on if they wish.
So the basic rule is that we should have one common 0.46.0 tarball, and then each distro (including the Windows package as a distro), applies their packaging patches against it before building their packages.
When we prepare for 0.46.1, we can look into incorporating some/all of the windows (and other distro) patches.
V. Packaging and Release Announcements
As mentioned before, March 24th is the day for sending out release announcements. This means we need to get all packages (including Windows) posted ASAP. Please let me know if anyone needs additional time for packaging, in case we need to delay the PR a bit.
Bryce
On Mon, Mar 24, 2008 at 08:30:29AM -0700, rygle wrote:
A few minor improvements have been made to the Win32 printing patch, and
it's
as ready as I think it will get for 0.46 release. Can someone please
commit
it? https://bugs.launchpad.net/inkscape/+bug/179988/comments/139
Here's the latest information on printing under Win32;
Non-printing - FIXED
Default page size problems - FIXED
Print Scaling problems - FIXED
White or black boxes over printing - FIXED - GTK uses the wrong call
in
Cairo (create_win32_surface, not the create_win32_printing_surface).
There
is a patch in the GTK bug tracker to fix this, but in the meantime we
have
bypassed that part of GTK. The code will revert to GTK automatically
when
GTK itself fixes the problem.
- All known crashes - FIXED
Adrian Johnson has patched the Cairo libs to fix a rare crash with
radial
gradients.
- There are two patched libs here (needs both) -
http://annarchy.freedesktop.org/~ajohnson/cairo/
- A patch has also been submitted to the Cairo git repository -
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=ae9635bf33cb989f5c525800b8...
- If the cairo dlls for inkscape are built by patching 1.5.14 instead of
building from git head Adrian recommends also getting the PostScript bug
fix
as well:
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=13e05bffd5cae5690fada24c7a...
Remaining problems with Windows printing are;
- Some blurs are misaligned/mis-scaled - see
https://bugs.launchpad.net/inkscape/+bug/205732 The workaround is to print to bitmap (under rendering in the print
dialogue)
- When printing falls back to bitmap, the bitmap is not always an ideal
resolution. Again the workaround is to print to bitmap (Print ->
Rendering
-> Bitmap).
-- View this message in context:
http://www.nabble.com/Win32-libs-tp16033417p16254450.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mar 24, 2008, at 3:46 PM, Bryce Harrington wrote:
Is there a particular up-to-date build that win people can use to test the printing? Or is there something else I need to know to get printing?
Ishmal will need to take this patchset and produce a windows package. AFAIK this is still TBD.
Do we have any progress on others being able to do the win32 stuff? I really hate to keep such a strong bottleneck on Ish.
I've pulled a few things onto a Vista PC to try to get a start myself, but my scheduling will keep me from being able get productive anytime sooner than a week or so.
Of course in the long term I have ulterior motives for getting this simple enough for a child to maintain... buahahaha!! time to get the kids to work ;-)
On Mon, Mar 24, 2008 at 07:34:15PM -0700, Jon A. Cruz wrote:
On Mar 24, 2008, at 3:46 PM, Bryce Harrington wrote:
Is there a particular up-to-date build that win people can use to test the printing? Or is there something else I need to know to get printing?
Ishmal will need to take this patchset and produce a windows package. AFAIK this is still TBD.
Do we have any progress on others being able to do the win32 stuff? I really hate to keep such a strong bottleneck on Ish.
He's not the only one that does windows packaging, but I do agree it seems to be rather bottlenecked. A number of people pulled out all the stops getting patches generated to fix the issues, so it's too bad that it got stuck today waiting on packaging. Hopefully someone can generate the package soon? It's time to get moving ahead with the release announcements.
Bryce
If this attachment works in nabble, this is a master patch of the 5 Windows patches in SVN at the moment.
http://www.nabble.com/file/p16271925/Inkscape%2B046%2BWin%2BMaster%2BPatch%2... Inkscape+046+Win+Master+Patch+-+SVN+1-5.patch
Forgot to say, I haven't built on that yet, but I have tested most of those individually, and I think I've merged them correctly.
rygle wrote:
If this attachment works in nabble, this is a master patch of the 5 Windows patches in SVN at the moment.
Has anyone been able to look at bug 187290 recently? It's pretty serious, and should stop the Win32 dist going out. Running any extensions causes a showstopper crash.
It seems this is partly a libs problem, because going back to the March 3 libs stops the problem. Any thoughts there Ishmal?
But Adib says he's also been able to fix it with a patch found here; https://bugs.launchpad.net/inkscape/+bug/187290/comments/34
I had problems building with the patch. Here's the error I get. I'm just taking an educated guess, but it seems the fail to build might be caused by some undeclared variables - the _wspawn... ones mentioned on line 11-17 below (??).
======= Make error line 195: problem compiling: src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extension::Implementation::read_helper_report(i nt, gint*, GError**)': src/extension/implementation/script.cpp:982: warning: comparison between signed and unsigned integer expressions src/extension/implementation/script.cpp:1018: warning: comparison between signed and unsigned integer expressions src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extensi on::Implementation::do_spawn_directly(gint*, gboolean, GSpawnFlags, gchar**, cha r**, char**, void (*)(void*), void*, void**, GError**)': src/extension/implementation/script.cpp:1248: error: '_wspawnvpe' was not declar ed in this scope src/extension/implementation/script.cpp:1250: error: '_wspawnvp' was not declare d in this scope src/extension/implementation/script.cpp:1253: error: '_wspawnve' was not declare d in this scope src/extension/implementation/script.cpp:1255: error: '_wspawnv' was not declared in this scope src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extensi on::Implementation::do_spawn_with_pipes(gint*, gboolean, const gchar*, gchar**, char**, GSpawnFlags, void (*)(void*), void*, void**, gint*, gint*, gint*, gint*, GError**)': src/extension/implementation/script.cpp:1384: warning: deprecated conversion fro m string constant to 'gchar*' src/extension/implementation/script.cpp:1386: warning: deprecated conversion fro m string constant to 'gchar*' src/extension/implementation/script.cpp:1436: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1441: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1451: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1455: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1465: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1469: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1478: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1480: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1483: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1485: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1488: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1490: warning: deprecated conversion fro m string constant to 'char*' src/extension/implementation/script.cpp:1547: error: '_wspawnvpe' was not declar ed in this scope src/extension/implementation/script.cpp:1549: error: '_wspawnvp' was not declare d in this scope src/util/glib-list-iterators.h: In member function 'T* const& Inkscape::Util::GS ListConstIterator<T*>::operator*() const [with T = SPItem]': src/extension/implementation/script.cpp:557: instantiated from here src/util/glib-list-iterators.h:47: warning: dereferencing type-punned pointer wi ll break strict-aliasing rules =========
Can this be fixed with something as simple as this (taken from http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/vmaid/vmaid/w32loader/msvcrt.h... Could this be dropped in the top of the code? ========= #define wspawnv _wspawnv #define wspawnve _wspawnve #define wspawnvp _wspawnvp #define wspawnvpe _wspawnvpe =========
Oops!! So much for "I think I've merged them correctly"!
My master patch missed out two files and caused a build problem. Please ignore the last one and use this one. Sorry about any hassle!
Please note: This installs over a clean SVN checkout of 0.46 branch revision 18013, and only includes the SVN patches 1-5 from \packaging\win32\patches http://www.nabble.com/file/p16274398/Inkscape_046_Win_Master_Patch_SVN_1-5_f... Inkscape_046_Win_Master_Patch_SVN_1-5_fixed.patch
rygle wrote:
If this attachment works in nabble, this is a master patch of the 5 Windows patches in SVN at the moment.
Forgot to say, I haven't built on that yet, but I have tested most of those individually, and I think I've merged them correctly.
After fixing the patch and trying to build again, I'm getting the same build error relating to patch 3 - "03_vista_turn_off_dashes.patch", which is a fix for bug 183646.
If you're able, you may want to help Albin and others figure out the problem.
In the meantime if you're trying to build on windows either don't apply patch 3, or using the master patch file and Tortoise, don't select the 3 gdl related patches; - src\libgdl\gdl-dock-master.c - src\libgdl\gdl-win32.c - src\libgdl\gdl-win32.h
If you try to revert using Tortoise, it won't show anything for the last two, because they are complete new files rather than patches to existing files in the codebase. Therefore Tortoise doesn't consider that those files have changed from the codebase. You will have to delete or rename them yourself.
The files src\libgdl\gdl-win32.c src\libgdl\gdl-win32.h seems to be missing from the last compound patch rygle sent. I think the easiest way to create a big patch file is to just
c:\RELEASE_0_46_BRANCH\packaging\win32\patches>type 01*.patch > all.patch c:\RELEASE_0_46_BRANCH\packaging\win32\patches>type 02*.patch >> all.patch c:\RELEASE_0_46_BRANCH\packaging\win32\patches>type 03*.patch >> all.patch c:\RELEASE_0_46_BRANCH\packaging\win32\patches>type 05*.patch >> all.patch that is no number 4...
I have tried to clean and compile myself again, and when I apply the 03_vista_turn_off_dashes.patch correctly it compiles on my Vista machine.
Any gdl-win32.c:62: error: redefinition of 'is_os_vista' src/libgdl/gdl-win32.c:20: error: previous definition of 'is_os_vista' was here kind of errors is because the src\libgdl\gdl-win32.c src\libgdl\gdl-win32.h files gets patched several times and then contains the method definifinitions several times. If that happen, remove all but the first definition (43 lines should remain in gdl-win32.c)
rygle skrev:
After fixing the patch and trying to build again, I'm getting the same build error relating to patch 3 - "03_vista_turn_off_dashes.patch", which is a fix for bug 183646.
If you're able, you may want to help Albin and others figure out the problem.
In the meantime if you're trying to build on windows either don't apply patch 3, or using the master patch file and Tortoise, don't select the 3 gdl related patches;
- src\libgdl\gdl-dock-master.c
- src\libgdl\gdl-win32.c
- src\libgdl\gdl-win32.h
If you try to revert using Tortoise, it won't show anything for the last two, because they are complete new files rather than patches to existing files in the codebase. Therefore Tortoise doesn't consider that those files have changed from the codebase. You will have to delete or rename them yourself.
Rename is not good, since the renamed files will be built also, delete (or move far away from the src-tree) is the only working thing to do.
// Albin
Back again with the last version of master patch 1-5 (I hope) http://www.nabble.com/file/p16275284/Inkscape_046_Win_Master_Patch_SVN_1-5_f... Inkscape_046_Win_Master_Patch_SVN_1-5_fixed.patch
Turns out the problem with the gdl stuff was a patching problem with Tortoise. I tested my patching file a few times, but it ended up duplicating the content inside two of the gdl files. Because two files were new Tortoise didn't have anything to compare new code to and kept pasting the same content repeatedly.
Sorry about the confusion! Just trying to help.
Last time. Apologies. Tortoise handles existing files really well, but new files really badly. Sorted. http://www.nabble.com/file/p16275315/Inkscape_046_Win_Master_Patch_SVN_1-5_f... Inkscape_046_Win_Master_Patch_SVN_1-5_fixed.patch
Here's the latest information on printing under Win32. Some of these will need a new patch, which I'll get out tomorrow.
Existing Fixes: (Thanks Ulf and Adrian for many of these) * Non-printing - FIXED * Default page size problems - FIXED * Print Scaling problems - FIXED * White or black boxes over printing - FIXED * Known crashes - FIXED
New Fixes: * Linux build problems caused by missing #ifdef WIN32 - FIXED * Bad resolution on bitmap fallback - FIXED - Adrian Johnson, our resident cairo expert, has patched a scaling fault in Cairo, but in the meantime we have a workaround. We can have the patch or the workaround but not both.
Ishmal: can you let us know if you can add this in to the win32 cairo libs? Otherwise we will have to do the workaround until the next libs with this patch, but both is bad (huge prints and memory problems) - https://bugs.launchpad.net/inkscape/+bug/179988/comments/138
Remaining problems with Windows printing: (Probably all for 0.46.1)
* Blurs are misaligned/mis-scaled - see https://bugs.launchpad.net/inkscape/+bug/205732 The workaround is to print to bitmap (under rendering in the print dialogue).
* Found that masks are not working on printing, so sometimes masked objects disappear from the page. Workaround is to print to bitmap. Don't know if we can enable on cairo printing just yet, but there is some stuff about cairo_mask in cairo-render-context.cpp Currently masks are outputting to screen and bitmap export properly. PDF ignores the mask and prints the object (like it ignores blur), printing ignores the mask and the object altogether.
* Print files are too large - no larger than 0.45.1, but still larger than they should be, eg: 100Mb+ for an A4 page @ 300dpi. Should be much less.
rygle skrev:
If this attachment works in nabble, this is a master patch of the 5 Windows patches in SVN at the moment.
http://www.nabble.com/file/p16271925/Inkscape%2B046%2BWin%2BMaster%2BPatch%2... Inkscape+046+Win+Master+Patch+-+SVN+1-5.patch
The files src\libgdl\gdl-win32.h and src\libgdl\gdl-win32.c is missing from this patch
// Albin
Bug 187290 has patches still waiting to be committed, and I think this is also pretty important for 0.46. This bug is about extensions not running on Win XP SP2 (and maybe Vista).
This bug has two patches by Ulf, Simon & others ready to be committed. These patches got overshadowed because the spawn problem (see my last post) confused the issue and we ended up with a patch for bug 204779 in bug 187290.
I have previously tested these and they seem to work for me.
Path\Environment fixes to get extensions working https://bugs.launchpad.net/inkscape/+bug/187290/comments/30
Temp file fixes for extensions https://bugs.launchpad.net/inkscape/+bug/187290/comments/31
I have tested these previously and they seem to work.
Can someone commit these?
Thanks, Bryce. And thanks to everybody who put in the long hours to resolve these issues.
Bryce Harrington wrote:
I've also written a simple script to apply the patches:
cd /packaging/win32/ && ./apply_patches.sh
Shell script for applying windows patches. Hehe. I wonder if there is a slightly less humorous method for applying patch sets on windows. As long as there is a small number of patches they can be easily applied using TortoiseSVN.
Aaron Spike
On Mon, Mar 24, 2008 at 06:19:14PM -0500, Aaron Spike wrote:
Thanks, Bryce. And thanks to everybody who put in the long hours to resolve these issues.
Bryce Harrington wrote:
I've also written a simple script to apply the patches:
cd /packaging/win32/ && ./apply_patches.sh
Shell script for applying windows patches. Hehe. I wonder if there is a slightly less humorous method for applying patch sets on windows. As long as there is a small number of patches they can be easily applied using TortoiseSVN.
Yeah, call it a proof of concept. Basically it just foreach's the contents of the series files, applies each patch in turn, and prints out a friendly status list at the end. Could likely be reimplemented in any scripting language without breaking a sweat.
The key thing is enabling a system for storing and managing windows patches separate from the main code. The philosophy here (used by debian, redhat, and other distros) is to keep the original tarball "pristine", and all distro/platform specific patches independent.
As it turns out, it's good that I did this - the windows printing patch in fact causes failure to build on Linux. Seems to be depending on the existance of FontFactory.h.
Anyway, I hope the window package can be generated and posted ASAP. We'll be putting out the PR probably this evening, and it would be nice to have the windows .exe's posted by then. (The earlier the better, to give folks time to test.)
Bryce
Bryce,
I made a fresh checkout of 0_46_BRANCH and patched 01, 02 and 03. I applied patch Nr 04 manually and did a diff against a directory patched until Nr 03
The resulting diff is not so nice as an "svn diff" but patches fine on the second directory.
I attach the patch. (Same name different size).
HTH,
Adib. ---
Bryce Harrington schrieb:
I. Rygle, that round-up of Windows issues is quite handy!
II. Patches included so far
#179988 01_win32_printing.patch ?????? 02_win32_print_dialog_parent_window.patch (from Joel; no LP#) #183646 03_vista_turn_off_dashes.patch #168896 05_save_as_xaml.patch:
III. Patches/bugs not included due to problems
#165726 04_win32_remove_dialogs_on_top_preference.patch Fails to apply. See bug for details. #204779: ?? Not sure what to do here. A late comment refs to a patch in #187290 so maybe that patch needs inclusion? #187290: ?? I'm unclear if the patch here (comment #34) is ready, or needs additional testing/fixing.
IV. New Windows patch packaging system
I've added a debian-like patch setup for managing Windows patches. In other words, rather than apply patches directly, they are placed in inkscape/packaging/win32/patches/ and listed in the 'series' file in that directory. I've also written a simple script to apply the patches:
cd /packaging/win32/ && ./apply_patches.sh
This will need to be done by the Windows packagers when building 0.46.0 Windows packages (perhaps some scripts could be updated to include this step). Please someone update the Win32 docs to reflect this.
This may seem weird compared with just committing the patches directly onto the stable branch, however this is standard operating procedure on Linux distros, and makes managing the patches and future updates easier. By keeping the patches only applied for Windows, it also completely avoids the risk of windows patches breaking linux code (these patches look safe, but you never know...)
This also gives the windows packagers the flexibility to do 0.46.0-2, -3, etc. releases with more patches later on if they wish.
So the basic rule is that we should have one common 0.46.0 tarball, and then each distro (including the Windows package as a distro), applies their packaging patches against it before building their packages.
When we prepare for 0.46.1, we can look into incorporating some/all of the windows (and other distro) patches.
V. Packaging and Release Announcements
As mentioned before, March 24th is the day for sending out release announcements. This means we need to get all packages (including Windows) posted ASAP. Please let me know if anyone needs additional time for packaging, in case we need to delay the PR a bit.
Bryce
On Mon, Mar 24, 2008 at 08:30:29AM -0700, rygle wrote:
A few minor improvements have been made to the Win32 printing patch, and it's as ready as I think it will get for 0.46 release. Can someone please commit it? https://bugs.launchpad.net/inkscape/+bug/179988/comments/139
Here's the latest information on printing under Win32;
Non-printing - FIXED
Default page size problems - FIXED
Print Scaling problems - FIXED
White or black boxes over printing - FIXED - GTK uses the wrong call in
Cairo (create_win32_surface, not the create_win32_printing_surface). There is a patch in the GTK bug tracker to fix this, but in the meantime we have bypassed that part of GTK. The code will revert to GTK automatically when GTK itself fixes the problem.
- All known crashes - FIXED
Adrian Johnson has patched the Cairo libs to fix a rare crash with radial gradients.
- There are two patched libs here (needs both) -
http://annarchy.freedesktop.org/~ajohnson/cairo/
- A patch has also been submitted to the Cairo git repository -
http://gitweb.freedesktop.org/?p=cairo;a=commit;h=ae9635bf33cb989f5c525800b8...
- If the cairo dlls for inkscape are built by patching 1.5.14 instead of
building from git head Adrian recommends also getting the PostScript bug fix as well: http://gitweb.freedesktop.org/?p=cairo;a=commit;h=13e05bffd5cae5690fada24c7a...
Remaining problems with Windows printing are;
- Some blurs are misaligned/mis-scaled - see
https://bugs.launchpad.net/inkscape/+bug/205732 The workaround is to print to bitmap (under rendering in the print dialogue)
- When printing falls back to bitmap, the bitmap is not always an ideal
resolution. Again the workaround is to print to bitmap (Print -> Rendering -> Bitmap).
-- View this message in context: http://www.nabble.com/Win32-libs-tp16033417p16254450.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Only in .: 04.patch diff -r -u4 -x .svn ..\inkscape_46_patch-1/src/dialogs/dialog-events.cpp ./src/dialogs/dialog-events.cpp --- ..\inkscape_46_patch-1/src/dialogs/dialog-events.cpp 2008-03-27 16:03:57.953125000 +0100 +++ ./src/dialogs/dialog-events.cpp 2008-03-27 16:13:30.593750000 +0100 @@ -156,13 +156,10 @@ #endif
gint transient_policy = prefs_get_int_attribute_limited ( "options.transientpolicy", "value", 1, 0, 2 );
-#ifdef WIN32 // FIXME: Temporary Win32 special code to enable transient dialogs - if (prefs_get_int_attribute ( "options.dialogsontopwin32", "value", 0)) - transient_policy = 2; - else - transient_policy = 0; +#ifdef WIN32 // Win32 special code to enable transient dialogs + transient_policy = 2; #endif
if (transient_policy) {
@@ -185,13 +182,10 @@ SPDesktop *desktop, win_data *wd ) { gint transient_policy = prefs_get_int_attribute_limited ( "options.transientpolicy", "value", 1, 0, 2);
-#ifdef WIN32 // FIXME: Temporary Win32 special code to enable transient dialogs - if (prefs_get_int_attribute ( "options.dialogsontopwin32", "value", 0)) - transient_policy = 2; - else - return; +#ifdef WIN32 // Win32 special code to enable transient dialogs + transient_policy = 2; #endif
if (!transient_policy) return; diff -r -u4 -x .svn ..\inkscape_46_patch-1/src/ui/dialog/dock-behavior.cpp ./src/ui/dialog/dock-behavior.cpp --- ..\inkscape_46_patch-1/src/ui/dialog/dock-behavior.cpp 2008-03-27 16:04:56.906250000 +0100 +++ ./src/ui/dialog/dock-behavior.cpp 2008-03-27 16:14:34.421875000 +0100 @@ -215,13 +215,10 @@ DockBehavior::onDesktopActivated(SPDesktop *desktop) { gint transient_policy = prefs_get_int_attribute_limited ( "options.transientpolicy", "value", 1, 0, 2);
-#ifdef WIN32 // FIXME: Temporary Win32 special code to enable transient dialogs - if (prefs_get_int_attribute ( "options.dialogsontopwin32", "value", 0)) - transient_policy = 2; - else - return; +#ifdef WIN32 // Win32 special code to enable transient dialogs + transient_policy = 2; #endif
if (!transient_policy) return; diff -r -u4 -x .svn ..\inkscape_46_patch-1/src/ui/dialog/floating-behavior.cpp ./src/ui/dialog/floating-behavior.cpp --- ..\inkscape_46_patch-1/src/ui/dialog/floating-behavior.cpp 2008-03-27 16:04:57.093750000 +0100 +++ ./src/ui/dialog/floating-behavior.cpp 2008-03-27 16:15:15.703125000 +0100 @@ -96,13 +96,10 @@ FloatingBehavior::onDesktopActivated (SPDesktop *desktop) { gint transient_policy = prefs_get_int_attribute_limited ( "options.transientpolicy", "value", 1, 0, 2);
-#ifdef WIN32 // FIXME: Temporary Win32 special code to enable transient dialogs - if (prefs_get_int_attribute ( "options.dialogsontopwin32", "value", 0)) - transient_policy = 2; - else - return; +#ifdef WIN32 // Win32 special code to enable transient dialogs + transient_policy = 2; #endif
if (!transient_policy) return; diff -r -u4 -x .svn ..\inkscape_46_patch-1/src/ui/dialog/inkscape-preferences.cpp ./src/ui/dialog/inkscape-preferences.cpp --- ..\inkscape_46_patch-1/src/ui/dialog/inkscape-preferences.cpp 2008-03-27 16:04:56.687500000 +0100 +++ ./src/ui/dialog/inkscape-preferences.cpp 2008-03-27 16:19:14.843750000 +0100 @@ -488,19 +488,17 @@ _("Dockable")); _page_windows.add_line( true, "", _win_floating, "", _("Floating"));
- _page_windows.add_group_header( _("Dialogs on top:")); -#ifndef WIN32 // FIXME: Temporary Win32 special code to enable transient dialogs +#ifndef WIN32 // non-Win32 special code to enable transient dialogs + _page_windows.add_group_header( _("Dialogs on top:")); + _page_windows.add_line( true, "", _win_ontop_none, "", _("Dialogs are treated as regular windows")); _page_windows.add_line( true, "", _win_ontop_normal, "", _("Dialogs stay on top of document windows")); _page_windows.add_line( true, "", _win_ontop_agressive, "", _("Same as Normal but may work better with some window managers")); -#else - _page_windows.add_line( false, "", _win_ontop_win32, "", - _("Whether dialogs should stay on top of document windows. Read the ReleaseNotes on this issue! (Rightclick the taskbar button and press 'Restore' to bring back a minimized document window)")); #endif
_page_windows.add_group_header( _("Miscellaneous:")); #ifndef WIN32 // FIXME: Temporary Win32 special code to enable transient dialogs diff -r -u4 -x .svn ..\inkscape_46_patch-1/src/ui/dialog/inkscape-preferences.h ./src/ui/dialog/inkscape-preferences.h --- ..\inkscape_46_patch-1/src/ui/dialog/inkscape-preferences.h 2008-03-27 16:04:57.125000000 +0100 +++ ./src/ui/dialog/inkscape-preferences.h 2008-03-27 16:19:42.250000000 +0100 @@ -131,13 +131,8 @@ PrefRadioButton _win_ontop_none, _win_ontop_normal, _win_ontop_agressive; PrefRadioButton _win_save_geom_off, _win_save_geom, _win_save_geom_prefs; PrefCheckButton _win_hide_task, _win_zoom_resize , _win_show_close;
-// FIXME: Temporary Win32 special code to enable transient dialogs -#ifdef WIN32 - PrefCheckButton _win_ontop_win32; -#endif - PrefCheckButton _calligrapy_use_abs_size; PrefCheckButton _calligrapy_keep_selected;
PrefCheckButton _connector_ignore_text;
participants (7)
-
Aaron Spike -
Adib taraben -
Albin Sunnanbo -
Bryce Harrington -
Jon A. Cruz -
kaver -
rygle