Inkscape and XML whitespace handling
by Andi McClure
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 
 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/
11 years, 9 months
libcroco
by Alex Valavanis
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
11 years, 9 months
inkscape on a G5
by Drechsel Wolf
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
11 years, 9 months
Inkscape tiling interface redesign proposal
by Valerie
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?
11 years, 9 months
support multiple extension locations
by Tim Cuthbertson
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
11 years, 9 months
Inkscape with OpenMP support on OS X Lion: First attempt at build script (WIP)
by ~suv
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_...>
>
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
11 years, 9 months
Re: [Inkscape-devel] Mesh gradient status
by Valerie
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.
11 years, 10 months
Mesh gradient status
by Tavmjong Bah
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
11 years, 10 months
