- Inkscape Devel - Inkscape Mailman

How to fix Aligning stroked and strokeless items & bounding box issues?
by Эльдар Файзуллин 10 Feb '12

10 Feb '12

Here: https://bugs.launchpad.net/inkscape/+bug/473608 It came from 0.47

3 2

Inkscape and XML whitespace handling
by Andi McClure 10 Feb '12

10 Feb '12

I am trying to create a patch to Inkscape and it isn't working very well, I was hoping I could ask for some help. I have been using Inkscape for creating resources for a video game I'm writing. As part of this I often attach custom attributes to XML nodes in the "XML Editor" window. When I do this, Inkscape gives me a nice big multiline editor window to enter my attribute text. Sometimes, I find myself needing to enter many lines of text or code into one of my custom attributes; when I do this, Inkscape handles newlines in a way that strikes me as incorrect and makes it very hard for me to get work done. Inkscape will allow me to enter, set and save multi-line attributes; however then later when I try to open the file, all the newlines will be erased, replaced with spaces. Although I understand newlines are rarely relevant in normal SVG, it seems very wrong to me that Inkscape allows me to enter content, save a file, and then reopen the file and it has been silently altered. I have been trying to fix this behavior on my own. What I found is that if you put a newline into an attribute and then save, Inkscape will actually write the newline raw into the file, like-- <example:example attribute="one two three four" /> When the file is opened the next time, Inkscape silently turns all newlines into spaces. The convert-newline-to-space behavior is apparently not only correct, but required for a conformant XML parser: http://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize So my conclusion is that if Inkscape is doing something wrong here (which I think it is), the mistake is that it should not be writing newlines raw into the file, rather it should be saving the appropriate XML entity (
 or 
). I have a local branch (patch attached) where I have attempted to implement this change. I can't get it to work. I found four separate places in the source code where strings are escaped into XML entities for storage; I added a '\n' -> 
 rule to each, and taught xmlreader.cpp to convert 
 back into '\n'. The reader change seems to have worked (I can manually write a &#xA into a file, and when loaded in Inkscape it becomes a newline) however, when I write a newline into an attribute and then set and save, Inkscape is still writing raw newlines instead of my escaped attribute. While making this change, I noticed two things that seem problematic: - XML entity escaping is done in at least four separate places in the code! - The XML reader in dom/xmlreader.cpp appears to only recognize a small number of hand-entered entities. At the moment there is no provision for loading any kind of &# style entity, which if I'm not missing something means Inkscape could choke on valid SVG XML produced by a different program. Should either of these two things be fixed? And would anyone know why my attempts to add '\n' to the escaper are having no effect? When you enter text into the attribute-value box in the XML editor, what path does it take in being entity-escaped (i.e. " becomes " and so on)? One more question-- other than this one problem the XML editor in Inkscape is quite nice, are there any examples of standalone programs for Mac or Linux that allow you to edit general XML in this manner? Thanks. - mcc http://runhello.com/

2 1

keyboard uneable with inkscape
by Rosa Alonso Garcia 09 Feb '12

09 Feb '12

Only I can to work with mouse. version inkscape 0.46.0 Keyboard uneable. MACOS Tiger. thanks. Rosa M. Alonso Garcia Il.lustradora gràfica http://rosailustradora.com http://rosailustradora.blogspot.com

1 0

libcroco
by Alex Valavanis 08 Feb '12

08 Feb '12

Hi All, Just wondering what the status of our libcroco fork is at the moment. Upstream development has restarted, and version 0.64 was released yesterday. It appears that Abhishek Sharma pushed some of our changes upstream, but then reverted them. Can anyone shed some light on this? Thanks, Alex

2 2

inkscape on a G5
by Drechsel Wolf 05 Feb '12

05 Feb '12

Hi everyboy, yesterday I succeeded it repairin an imac G5 1,8GHz. On this brand new machine I'm making an entierly new inkscape experience. Did some professional work - wow, it rocks. Compared to my slightly outdated G4 - what a difference… Therefore - what is said too seldomly: THANKS FOR MAKING INKSCAPE !! - I love it! BTW.: Can someone give me a quick hint: How can I find out on which (probabely locked) layer an object resides? - Couldnt google an anser for that. Greetings, Wolf

3 5

Inkscape tiling interface redesign proposal
by Valerie 05 Feb '12

05 Feb '12

Ah well, I have no idea if the wiki image upload issue will be fixed, so I just made everything into an image and uploaded it somewhere else: http://postimage.org/image/7f9ms5kw3/ As you can see, central concepts include: 1. Transformations separated into groups that people other than tile mathematicians understand 2. And moved to a dedicated dialogue. Basically: - One-time filters -> floating boxes - Properties that may need future editing -> side-dialogues By the way, radial transformations to use polar coordinates. 3. Top level interface to address most common use cases, while more advanced options (clutter) are moved to an extra button that you can access. 4. Guides can be edited on canvas... 5. ...and locked or unlocked to objects, so you can create half a vase, stick a symmetry on it, then move the whole thing around as though it were one object. 6. Stacking symmetries or tilings as you would LPEs I'm probably missing a lot of things, but it doesn't hurt to make a few proposals to see what people's thoughts are. :) So what do the rest of you think? Is this a direction you think can lead somewhere, or do you think the interface should be taken in a completely different direction?

5 12

support multiple extension locations
by Tim Cuthbertson 05 Feb '12

05 Feb '12

I was looking into how one might provide inkscape extensions using 0install[1], which basically amounts to adding extensions _without_ touching any well-known paths, typically using environment variables. I've done the same thing for gnome-shell, by essentially adding each extension's location to $XDG_DATA_DIRS. So for example to run gnome-shell with the shellshape extension[2], $XDG_DATA_DIRS might contain the following dir: /home/tim/.cache/0install.net/implementations/sha256=2437376cd245ee4f09b0738e1cc7392a04750a9cec4b0875bf71606703d9ee01/xdg which contains a `gnome-shell` directory with the files you would normally put in /usr/share/gnome-shell if you were installing them system-wide. I wondered if this would work for inkscape as well, but after having a look at the source, it doesn't seem likely. Based on the `profile_path` function in inkscape.cpp: - inkscape seems to assume that there will be at most one folder for each of (user, system) level preferences - it assumes preferences and extensions will all live in the same location. These both go against the XDG spec[3], which recommends that config and data live in different locations and should be able to be looked up in a cascading fashion (i.e supporting multiple paths in $XDG_DATA_DIRS). These restrictions also make it very difficult to use 0install to distribute extensions since that would require: - readonly `extensions` directories - all 0install implementation directories must be read-only as they can be shared between users (among other reasons) - cascading lookup of extensions in _all_ paths in $XDG_DATA_DIRS - adding or removing plugins must be possible by affecting what is in XDG_DATA_DIRS, rather than modifying folders in the filesystem. So, I guess my questions are: - am I wrong about my conclusions here? I've looked at the source, but may have missed something. - is there any interest in extending the extension loading mechanism to support loading extensions across all $XDG_DATA_DIRS? Presumably this would be implemented for _all_ data types (gradients, icons, etc) as well as just extensions. Cheers, - Tim. [1]: http://0install.net/ [2]: http://gfxmonk.net/dist/0install/shellshape.xml [3]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

3 3

Inkscape with OpenMP support on OS X Lion: First attempt at build script (WIP)
by ~suv 04 Feb '12

04 Feb '12

On 03/02/2012 23:03, ~suv wrote: > >> due to license restrictions in MacOs X, there are problems with compile >> Inkscape with OpenMP support. > > The underlying issue is the rather old version of GCC Apple provides > with Xcode [1] . Due to license changes in GCC, Apple will never upgrade > to a later GCC version than 4.2.1, and eventually drop GCC completely in > favor of CLANG. Building Inkscape with a custom-installed newer GCC > version doesn't work out-of-the-box due to ABI conflicts in linked > C++interface libraries [2]. > > Update: Since the time I had discussed the details impeding OpenMP > support on Mac OS X with Kris on irc, I did manage to produce stable > builds of 0.48.2, 0.48.x and current trunk with full OpenMP support > (64bit builds with GCC 4.6.2 (MacPorts) on OS X 10.7.2 Lion). I'm > currently working on a shell script as 'proof-of-concept' and to allow > easier testing of the build setup on other systems. The script does not > create a bundled osx application yet (this might be added later on). > > [1] <http://article.gmane.org/gmane.comp.graphics.inkscape.devel/36355> > [2] <http://wiki.inkscape.org/wiki/index.php/FAQ#On_Linux.2C_Inkscape_crashes_wi…> > quoted from <https://bugs.launchpad.net/inkscape/+bug/200415> Attached is an initial attempt (WIP) of a build script which allows to compile the following Inkscape versions on OS X 10.7.2 Lion in 64bit with OpenMP support (using GCC 4.6.2): - Inkscape 0.48.2 (from tar ball) - Inkscape 0.48.x (from lp:inkscape/0.48.x) - Inkscape trunk (from lp:inkscape) with cairo devel 1.11.2 - Inkscape mesh (from lp:~tavmjong-free/inkscape/mesh) with cairo master What the script basically does: ------------------------------- - rebuilds all C++ interfaces outside of MacPorts with GCC 4.6.2 (libsigc++, glibmm, atkmm, cairomm, pangomm, gtkmm) - builds cairo-devel (+ cairomm, pangomm, gtkmm) for trunk - builds cairo-master (+ cairomm, pangomm, gtkmm) for mesh branch - builds inkscape with GCC 4.6.2, linking to the new libs What it does not (yet): ----------------------- - create universal binaries or - create an osx application bundle - build with Quartz backend of GTK+ - fancy error handling: if something fails and you can't figure out how to fix it, you might simply delete $localSRC and $inkPREFIX and try again (or use './osx-build-inkgcc46.sh del_all) - optimize to the max (ATM everything is compiled with -02) - ... Prerequisites are: ================== - OS X Lion (tested on 10.7.2 with Xcode 4.2.1) - MacPorts (up-to-date), gtk2 with X11 backend (!) - port 'inkscape' installed in MacPorts (for all dependencies) - ports autoconf, automake and dbus-glib installed in MacPorts - port 'gcc46' installed in MacPorts (for the compiler) - $PATH is set up accordingly for MacPorts (the script does not override nor try to verify it in any way) How to use it: ============== 1a) edit the script file and adjust the paths for: LIBPREFIX (MacPorts install prefix) localSRC (directory to unpack the sources and compile) inkPREFIX (top-level dir for installation of inkscape+dependents) 1b) optionally reuse (clone or branch) local repos for inkscape 0.48.x, trunk, pixman, cairo and / or inkscape mesh branch (see script) 2) use a build target as command line argument: release | branch | trunk | mesh for example: $ ./osx-build-inkgcc46.sh trunk 3) grab a cup of coffee and wait for the build to finish 4) launch the inkscape binary with its full path name Note: DYLD_LIBRARY_PATH is needed for trunk and mesh (as displayed in a note if the installation was successful), for example: $ DYLD_LIBRARY_PATH=$inkPREFIX/cairo-devel/lib $inkPREFIX/trunk/bin/inkscape 5) updating local source trees of inkscape branch, trunk and mesh: you can update from parent branch and rebuild by rerunning the script with the same target. The script ought to test and detect already installed libs as well as the local repo, pull new revisions and rebuild as needed. Alternatively, you can cd into '$localSRC/inkscape-trunk/build' (or '$localSRC/inkscape-mesh/build'), and use 'bzr pull', 'make && make install' as usual. Note: you can install multiple targets without changing $inkRPEFIX (the builds install into different sub-directories) Feedback, comments, improvements, test and bug reports about the script (to me personally, or here on the list - not in the bug tracker) would be welcome :) ** (inkscape:79650): WARNING **: the script is unstable and buggy in its current state - use at your own risk ;-). It was _not_ written with regular Mac users in mind - ideally it would be improved/reworked and extended to allow to create precompiled osx application bundles of trunk (and experimental feature branches), which then could be uploaded and shared for testing. ~suv

1 0

Re: [Inkscape-devel] Mesh gradient status
by Valerie 03 Feb '12

03 Feb '12

Speaking of the mesh gradients, can someone describe to me different types of mesh gradients and how they're supposed to be edited so I can try to design a toolbar for it? I have no idea how to compile it, and I don't want to risk breaking my system dependencies again either (if it involves that)... That said, I'm not sure what functions should go into the toolbar and what guides could be edited by the other editing tools. For example, can tweak tools be used to edit the meshes? I'm adding mesh gradient to the list of tools I'm doing at the same time as thoughts on toolbar rework. Since I plan to add a few toolbar suggestions for a few other tools at the same time, I might as well do one for mesh gradients too.

1 0

Mesh gradient status
by Tavmjong Bah 02 Feb '12

02 Feb '12

Hi, I've gotten a number of queries as to when mesh gradients will be available in Inkscape. Some people seem to think that it is a project that is close to being ready... it is not. There is still a lot of work to do and several major issues to be resolved. So I though I would give a status report: At the moment, you can create, edit, save, read in both Coons Patch meshes and tensor meshes (the latter have not been approved by the SVG working group). There are a few nice editing features available: Conical gradients, sampling color from beneath the mesh, toggling between straight edges and curves, etc. However, the code is very buggy. Expect frequent crashes. Save often. Undo does not work for most things. Revert is a poor person's substitute. Before the mesh code can be merged with trunk the following issues MUST be resolved: 1. Meshes have been approved for SVG 2 but the syntax has not been finalized and will not likely be finalized for some time. For meshes to be included in Inkscape we will need to keep them in the Inkscape namespace for the moment and include a fallback mechanism. (Note, there are quite a few nice SVG 2.0 features that we could adopt quickly if we had a way of handling fallbacks: markers that inherit stroke color, solid colors that will eliminate the need for the one-stop gradient hack for creating a palette, etc.). 2. Meshes rely on Cairo trunk. We need an official Cairo release with the mesh rendering code. The last new Cairo release was in Sept of 2010. Who knows when a new release will be made. 3. My code is a hack. There are multiple issues that need to be resolved. The most important one is how do meshes fit into the Private/Vector structure used by linear and radial gradients (Inkscape gradients are broken up into two gradient elements, one that handles the geometric layout and the other that handles the color vector. This allows reuse of the same gradient to be applied to multiple objects. It may not make sense for meshes.) Of course all the crashes must be eliminated. 4. GUI: How should meshes fit into the GUI? Should meshes have their own tool bar? The gradient chooser is not really applicable for meshes and meshes will have lots of their own options: * Mesh creation: * Mesh type: Normal, conical, ? * Number of rows/columns. * Mesh editing: * Show/hide handles. * Make handle smooth/symmetric. 5. Saving to PDF/PostScript needs to be implemented. (Export to PNG works.) I am sure I've missed some. Issues that would be nice to address: 1. Node editing. Gradients implement their own dragger code. It would be nice to be able to use the code from path editing. This would enable things like editing the paths by dragging or selecting a group of nodes and rotate/scale/etc. them together. 2. Auto generating an initial grid based on path shape. 3. Auto fitting. It would be the nice to be able to layout a rough mesh and have Inkscape adjust the mesh to match an underlying drawing. My branch can already set the mesh corner colors by sampling the image underneath which is a real time saver. 4. Auto smoothing of patch boundaries. I have an initial implementation that attempts to make color transitions across patch boundaries smooth. This can certainly be improved. Tav

4 4