- Inkscape Devel - Inkscape Mailman

Linux Build broken?
by Henning Meyer 22 Dec '08

22 Dec '08

Hello, I'm trying to experiment with the tracing, but unfortunatly I cannot even build inkscape from SVN/Trunk. This is the error I get: extension/internal/bitmap/level.cpp &&\ mv -f $depbase.Tpo $depbase.Po extension/internal/bitmap/level.cpp: In member function »virtual void Inkscape::Extension::Internal::Bitmap::Level::applyEffect(Magick::Image*)«: extension/internal/bitmap/level.cpp:23: Fehler: »class Magick::Image« hat kein Element namens »level« make[2]: *** [extension/internal/bitmap/level.o] Fehler 1 make[2]: Verlasse Verzeichnis '/home/hmeyer/devel/inkscape/trunk/inkscape/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/hmeyer/devel/inkscape/trunk/inkscape' make: *** [all] Fehler 2 For more details look at: http://drop.io/5y9sjps/media The same happens with SVN/Release_0_46_0. What am I doing wrong? Thanks for your help, Henning

1 0

"Shape" suggestion: draw simple path when there's nothing on the clipboard
by Valerie 22 Dec '08

22 Dec '08

Right now, when you have Shape: Clipboard enabled, but nothing on the Clipboard, then you literally draw a blank. It can be very confusing upon start-up, especially since the warning message isn't in a very visible position. Users are bound to get confused if they're unfamiliar with the Shape feature, I thought there was something wrong with my development build at fist. Here's a rather simple solution: when there's nothing on the Clipboard, then have a default where the resulting path is a normal path with no shape applied. Problem solved. The warning message (Nothing on the Clipboard) can still be displayed.

1 0

rendering performance regression
by Thomas Holder 20 Dec '08

20 Dec '08

I see a significant regression in rendering speed for some days now. I have build backups from Nov 07 and Dec 08, when I open the same file, the newer build needs approximately 4 times more time to display the file, zoom, scroll etc. than the older build. This makes editing of large files almost impossible. Operations like selecting or moving items on canvas likewise behave very slow. What could be the reason for this? Any ideas? Thomas

1 1

Gradients disappearing
by Jasper van de Gronde 20 Dec '08

20 Dec '08

Running the rendering tests again this week I encountered a regression in the rendering of filters-comptran-01-b (from W3C SVG test suite). This test contains four rectangles with the same gradient, one without any filter and three with three different component transfer filters. Last week the four rectangles in the filters-comptran-01 test were still rendered with the wrong colours, but they were rendered. This week two of them are not rendered anymore... As far as I can tell the component transfer code wasn't touched during that time though, so I have absolutely no idea why this suddenly happens. Now the question is, should a bug be reported? And if so, what is this the actual bug? As far as I can tell feComponentTransfer isn't supposed to work anyway, so filing a bug seems a bit pointless at this point. However, as it doesn't appear to be related to a change to the component transfer filter it might actually be an unrelated bug in disguise. So, any ideas on what could be causing this?

2 4

Picking a shape when Alpha=0%
by Yann Papouin 18 Dec '08

18 Dec '08

Hi, I have a question about picking. Actually it's not possible to pick a shape when it's alpha value is 0. It is a design choice, a bug or implementation limitation? Have a good day!

2 1

Sudden surge of regressions/changes in (filter) rendering
by Jasper van de Gronde 18 Dec '08

18 Dec '08

I just ran the rendering tests again, and compared to last week there were suddenly 16(!) new results. I've had a quick look at some of them and they all seem to be regressions related to filter rendering (affecting quite a lot of different filters). Could anyone who has touched the general filtering code in the last week please recheck their work? (I'm currently swamped with work, so I have no time to go after this myself.)

3 5

Re: [Inkscape-devel] Changing the gtk2 theme for a self-built OSX nightly
by jiho 17 Dec '08

17 Dec '08

Hi, Sorry I did not answer earlier. On 2008-December-01 , at 23:05 , André Berg wrote: > I compiled and uploaded numpy and lxml for Python 2.6 (i386) so that > you guys can include them into the PythonModules.dmg on Modevia. > Here's the link where you can download if you like: > > http://www.sendspace.com/file/plht64 Thanks, that will be useful. I will update the .dmg on Modevia ASAP (which might not be before a while though). > I also gave the build-system (mostly osx-app.sh) a few fair runs > trying out the site-packages dir inside the Inkscape.app bundle. > The inclusion of Arch and Python Version within site-packages made > it somehwat difficult to get it working out-of-the-box with that > build script. > I have three Python distributions installed: > > 1. Leopard Default > 2. MacPorts 2.5.x, 2.4, 2.6. (2.5.x being the active one with > MacPorts) > 3. MacPython 2.6 (being the overall systems active python. symlinks > from /usr/local/bin point to /Library/Frameworks/Python.framework/ > Versions/Current/bin > > My PATH (~/.bash_profile) looks like this: > > export PATH="/Library/Frameworks/Python.framework/Versions/Current/ > bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/ > sbin:/sbin:/usr/X11/bin:/sw/bin:/sw/sbin:${PATH}" > > So you can see MacPython comes first, then MacPorts, then /usr/ > local, Leopard Default and finally remnants of a Fink installation. > > The problem I had was that in the Inkscape shell script that > ultimately resides within Inkscape.app/Contents/Resources/bin a path > is exported that has almost the same entries but in another order. > > Which led to the strange effect that even though I modified osx- > app.sh to copy my numpy and lxml dirs automatically from /Library/ > Frameworks/Python.framework/Versions/Current/lib/python2.6/site- > packages into Inkscape.app/Contents/Resources/python/site-packages/ > i386/2.6 the modules where never found when the program was started > by double-clicking its dock icon. They were however found when I > started Inkscape by double-clicking the Inkscape shell script > mentioned earlier. > It took me quite a while to find out what was happening: > > Somehow the ScriptExec loader makes it so that Inkscape is started > within a virgin /bin/sh with no PATH whatsoever set. The Inkscape > shell script takes this into account by exporting its own PATH with > a hardcoded order which for my system had the wrong order of > importance. That's why I had this behaviour. The question now is, > how can we make sure that when the user specifies a directory to use > as the source for the Python modules, that we also start Inkscape > with the proper shell environment that has the correct order of its > PATH as set by the user for the Python install he/she selected to > use as Python module root. > In my opinion it is reasonable to assume that if the user has a > custom PATH variable set in his/her default shell that he/she should > know better than hardcoding/guessing what order the PATH components > need to be in. However, unfortunately I failed modifiying the > scripts involved in getting Inkscape to start up, so that the PATH > in use by the user's default shell is set as the PATH to use for > starting Inkscape. I completely agree: we should read the PATH of the user and use that. However, as you, I was not able to find a solution. First, on Mac OS X, the "PATH" used by double clickable, bundled applications is the one defined in ~/.macosx/environment.plist. See the comment in packaging/macosx/resources/bin/inkscape: # Brutally add many things to the PATH. If the directories do not exist, they won't be used anyway. # People should really use ~/.macosx/environment.plist to set environment variables as explained by Apple: # http://developer.apple.com/qa/qa2001/qa1067.html The usual PATH variable, declared in the shell of the user, is used only on the command line. This is why we do this: # but since no one does, we correct this by making the 'classic' PATH additions here: # /usr/local/bin which, though standard, doesn't seem to be in the PATH # newer python as recommended by MacPython http://www.python.org/download/mac/ # Fink # MacPorts (former DarwinPorts) Instead of proceeding this way however, we could (should?) read the PATH variable set in the shell of the user and use that. The problems are: - we could probe for the existence of .bashrc, .cshrc or similar files depending on the $SHELL variable of the user and use what's in that. but the modifications could also be in .profile or .bash_profile or... So we need a clean solution to get the environment a regular shell script would get, and I don't know how to do that - Inkscape would behave differently from other graphical, bundled applications. - and another reason that I forgot... There is, IMHO, a fundamental design flaw in the system, which makes scripts and regular applications use different PATHs (the things set in ~/.macosx/environment.plist, for applications are not available to shell scripts, and the PATH set in .bashrc for bash scripts for example, is not available for applciations). The only way to circumvent it is to set the same thing in ~/.macosx/environment.plist and in ~/.bash_profile (which is what I do), but I don't think Inkscape can do that for you. If you can find a way to concilate all these sources of PATH variables and detect/sort that in the launcher script, it would be very much welcome and will be included. > If it interests you I can include my modified osx-app.sh script. I > also made a osx-keymap.sh script for setting the not so well- > known .xmodmap hack until the Alt-Key behaviour is sourted out for > X11. I'll include both with this e-mail. I'm not sure what the modifications of osx-app.sh are intended for? Thanks for the other one. We need to decide whether it is better to include that (which would affect all X11 applications) or to sort it out for Inkscape only by using keys.xml in the appropriate way. > I also updated the wiki, but you may want to see it over, as there > maybe some things in my edits that may go against the philosophy of > the build teams involved. I can't check now but I'm sure it's fine. JiHO --- http://jo.irisson.free.fr/

2 1

Inkscape spray tool
by Pierre-Antoine MARC 17 Dec '08

17 Dec '08

5 4

Re: [Inkscape-devel] [Bug 179085] Re: new feature for 0.47 Multiple Pages Support
by the Adib 14 Dec '08

14 Dec '08

we need to focus on this feature to get this done. I think this is an important feature for all technical based drawings. There is a blueprint on this: http://blueprints.launchpad.net/inkscape/+spec/mutiple-pages-support and there is a reference page in the wiki: http://wiki.inkscape.org/wiki/index.php/MultiplePages those pages are recently created. HTH, Adib. --- On Sun, Dec 14, 2008 at 9:25 PM, mahfiaz <mahfiaz@...400...> wrote: > *** This bug is a duplicate of bug 170369 *** > https://bugs.launchpad.net/bugs/170369 > > ** This bug has been marked a duplicate of bug 170369 > Multiple Pages Support - SVG 1.2 Compliance > > -- > new feature for 0.47 Multiple Pages Support > https://bugs.launchpad.net/bugs/179085 > You received this bug notification because you are a member of Inkscape > Bug Team, which is subscribed to Inkscape. >

2 1

CharTypes.h et al
by Michal Svoboda 13 Dec '08

13 Dec '08

Hello, for the second day I'm trying to compile inkscape and growing more and more desperate. Compilation fails with: In file included from extension/internal/pdfinput/svg-builder.cpp:19: extension/internal/pdfinput/svg-builder.h:32:23: error: CharTypes.h: No such file or directory In file included from extension/internal/pdfinput/svg-builder.cpp:20: extension/internal/pdfinput/pdf-parser.h:29:24: error: goo/gtypes.h: No such file or directory extension/internal/pdfinput/pdf-parser.h:30:20: error: Object.h: No such file or directory (and ~3 more pages of induced errors). I've tried to google and stuff, but to no avail. What do I need to have installed to get those header files? (I've seen that they come with xpdf, but that's not quite it - and they don't get installed to /usr/include anyway.) So either some horrible hack is required on my part or these include files come with something very basic that is auto-assumed, and nobody bothers to check for it in ./configure. Can someone shed some light into this? Thanks, Michal

2 1