What is the status of the inkboard feature ? Is it considered stable ?
More importantly, is it considered safe (from a security standpoint) ?
We had requests in Fedora to have the feature enabled and so am doing
some testing on my side. It was originally turned off because it was
pretty unstable and would often crash in the loudmouth library, but that
was a while ago...
In the past I have found inkview to be a very handy tool for quickly
looking at svg, but lately it seems horribly broken
(see bug 1592467). Then I discovered that "inkscape -s" seems to be more
or less the same thing... but it doesn't crash.
What's the difference between inkview and "inkscape -s"? Do we really
need the maintenance and bloat of two separate binaries?
Sorry if I've missed any on-going discussion on this.
Sorry, my first message was meant to be addresed to the list.
> >Could you try with the latest svn version of the extension script and
> >give us feedback?
> It is better, I have now a window message :) :
> dvips: ! DVI file can't be opened.
Yes, it's better!
Now I guess you got this message because the formula input you gave to
the extension was either not valid LateX, or it became invalid because
of a shell expansion which occured when the script was called by the
extensions manager (this is a bug).
Can you try with a simple "\( \cos(x) \)" LaTeX input?
To know how your imput will be expanded you can use the following
$ echo -E "$$\cos(x)$$"
For example '$$' is expanded to the pid of the processus.
As a workarround, try not to use '$' or '$$' but '\(' and '\[' instead
to enter math mode.
PS: I'll also try to improve error reports when the given input is not
Dear Inkscape developers.
Myself and some other folks are currently working on some icons for
Inkscape , but have ran into some issues.
Apparently my build (13378 ...the latest one I got to work) wants to use
16x16 images for the icons in both the topmost (although the ones it
gets from the desktop theme is 24x24) and the secondary toolbar. The
tools toolbar however still use 24x24 images (and that is the correct
behavior I suspect).
However, other peoples toolbars use the 24x24 size (and so did mine
until recently), this leads to the problem that I don't know what size
to aim at. If I use 24x24 images for the toolbar, they get blurry on my
system, and if I use 16x16 it gets blurry on others.
What is the correct size used by these toolbars, and is there some way I
can have icons in several sizes?
The several sizes issue is even more troublesome, as the icons from the
tools toolbar gets all blurry in the undo history dialog among other
(this is about the current SVN-trunk version)
I've been busy implementing the find dialog as a c++ dialog
(ui\dialog\find.cpp). I hope it inspires others to spend some off-time on
implementing the other old (non gtkmm) dialogs! It's pretty lame work
though. Maybe good work for new people to get started? But very very
unexciting I guess. But refactoring is a noble cause! (Mail me if you need
If you have time to test the find dialog for bugs, please go to
src/verbs.cpp:1618 and remove the comment //.
I know the UI is not what it should be. When I tried adding the HSeparator
as in the old find dialog, Inkscape would crash so I gave up on the issue at
Mental or Bulia,
I've got a question... In looking at where marker stuff is hooked in I
notice a lot of stuff in nr-arena-shape.cpp, which appears to be special
casing marker elements as shape children. I'm attempting to add some
documentation, but it's a little confusing to me. Could either of you
explain what the design intent is for this?
In particular, I'm wondering why markers have this special case; it
feels like an odd fit in nr-arena-shape since everything else is so
generalized, and I'm wondering if there could be a way to generalize the
markers so no special case is needed for them?
you have committed the "g2png" extension. It has many problems.
1. It wasn't added to Makefile.am and so ignored during installation.
2. We don't use capital letters in filenames so G2Pngs.py had to be
renamed to g2pngs.py.
3. The python file had some French Unicode symbols on which my Python
interpreter choked. Please translate the comments to English.
4. It was added to a "Recursive actions" submenu which makes little
sense from the user viewpoint. I changed that to "Export".
5. It has a wrong copyright statement. You are not Aaron Spike, are you? :)
6. The URI should also be changed - don't use org.ekips, use
org.inkscape or your own domain.
7. Most importantly, this extension just goes and exports ALL groups
in the document, recursively. This does not seem to make sense to me.
In most documents, it results in an awful lot of pngs, most of which
are not needed. To be useful, instead, it should just export _all
selected objects_ (not just groups!) without any recursion.
Correspondingly, rename it to "Export selected objects" or something
8. It ignores the filename and resolution hints stored for objects,
always exporting them at the default resolution with the filename from
the id. This is not acceptable. See the man page for how to use export
I have fixed problems 1 to 4 in SVN, but the rest are for you to fix.
I'd suggest that you should have submitted this as a patch to our
patch tracker, or at least have it discussed on the list, before
committing to SVN.
Inkscape. Draw Freely.
I think it is generally agreed that PDF output is the last outstanding
blocker on the release process. Anyone who can spare a few cycles to
help perfect PDF output will be much appreciated. It would be nice if
the wise could supply some commentary on the state of PDF output to
taper off the learning curve for newcomers to the field (like myself).
As I sit here staring blankly at the files in src/extension/internal, I
could really use an atlas that explains which files are important to pdf
output, which particular effort they are part of, how they relate to
each other, and where my effort should be focused.
> Date: Sat, 25 Nov 2006 15:41:16 +0000 (GMT)
> From: Alan Horkan <horkana@...44...>
> > Date: Fri, 24 Nov 2006 22:23:31 +0100
> > From: Johan Engelen <goejendaagh@...1571...>
> > To: inkscape-devel(a)lists.sourceforge.net
> > Subject: [Inkscape-devel] NEW: RadioButtons for extensions (.INX)
> > I've added radiobuttons to the parameter types for
> extensions :) They are
> > called: 'optiongroup'; English is not my native tongue
> which makes it often
> > difficult to come up with a label..., please rename if desired.
> > A developer example is available as a placeholder until a
> real extension
> > uses it.
> Have you seperated the option group concept from the
> imlementation as a radio list?
I've thought about that (since the last discussion about enums), and it is
the reason that the syntax is exactly equal to enums. I think it is safe to
answer 'Yes'. (I will rename <item> to <option>)
> For example you might want to take the same options and
> reformat them as
> drop down list rather than a radio list depending on how much
> space you
> have available or how important that option really is.
Yes that is possible (for example: if the number of choices is more than 3,
display dropdown, otherwise radiobuttons. However I must say that at this
moment I prefer to give full control to the extension developer.