Poppler internal API problem
by Krzysztof Kosiński
We are still using the internal Poppler API to import PDFs. This is
very bad, since the internal Poppler API is not stable, and will keep
breaking. (We already don't build with poppler > 0.12.1)
How about using the public Glib API to render to a Cairo SVG surface
instead? This is how pdf2svg works, and to be honest I had to use that
utility several times to augment Inkscape, because it handles text
much better. What are the advantages to using internal Poppler API
directly?
Regards, Krzysztof
12 years, 8 months
Re: [Inkscape-devel] [Inkscape-user] Filters Not Saved with PNG
by Jasper van de Gronde
Chris Lilley wrote:
> On Saturday, January 16, 2010, 10:32:16 PM, knowone wrote:
> ...
> k> How can I save the file as PNG with the drop shadow intact?
>
> Make sure you are exporting as PNG. Do not 'Save As' Cairo PNG.
>
> (I came across this a couple of days ago, and the symptom was that blur filters were not being applied. Also, the pixel dimensions of the two methods differ, if the graphic bleeds over the edge of the 'page').
Can someone tell me why we have a non-vector format in the save as list?
One that seems redundant and apparently with less functionality than the
normal export. Is this for testing purposes?
12 years, 10 months
NEW: mouseover cursors in Selector
by bulia byak
Selector tool has a new mouse cursor (arrow with an open hand) for
when your mouse is over a selectable object, and another (arrow with
clinched hand) for when you're dragging an object. This improves
precision of selection and UI consistency (previously, the mouse
cursor over a selectable object was different across platforms, e.g.
hand icon on Linux or four-way arrow on Windows).
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12 years, 11 months
Status of dbus awareness
by Kent Tenney
Howdy,
I just built the inkscape trunk from bzr and ran this script
#!/usr/bin/python
import dbus
bus = dbus.SessionBus()
inkdoc1 = bus.get_object('org.inkscape', '/org/inkscape/desktop_0')
doc1 = dbus.Interface(inkdoc1, dbus_interface="org.inkscape.document")
im = doc1.image(100 ,100, '/home/ktenney/Firefox_wallpaper.png')
Which worked on a dbus branch a while back.
Now it starts inkscape, but does not place the image
- was the dbus code merged?
- if so, how do I enable/use it?
- if not, where is dbus capable code?
Thanks,
Kent
12 years, 12 months
gradient mesh
by sid datta
Hi,
Are we still waiting for the SVG standards before we can implement gradient
meshes ?
I have a ( pretty simple and obvious ) method of rendering gradient meshes
that is simpler than blurring multiple beziergons and is quite fast ( 100 ms
in Java rendering 500x500px approx ), I was wondering if we start putting a
basic gradient mesh in inkscape and we can conform/export to the SVG format
when it comes out.
I believe we are trying to get a triangle gradient primitive approved from
SVG. Do we have any plans of getting a quadrilateral primitive ? It will be
more accurate for gradient mesh. This paper I found explains some
quadrilateral rendering techniques :
http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf
Thanks
-Sid
13 years, 4 months
NEW: Pseudo unified console / GUI app on Windows
by Krzysztof Kosiński
Hello
Starting with revision 9251, it's possible to open cmd.exe, type
"inkscape" while having Inkscape's installation directory in PATH, and
get a working console-mode executable. This is done by shipping a
slightly modified version of the well-known inkscapec.exe helper,
renamed to inkscape.com and placed in the same directory as
inkscape.exe. This approach looks a bit hacky, but it's used by
several of Microsoft's tool that also implement both GUI and command
line mode.
Regards, Krzysztof
13 years, 4 months
node tool testing
by bulia byak
Krzysztof,
I finally found time to test the new node tool. Overall it feels
great, but of course I found many small and not so small things to fix
:) #1 is my personal pet peeve, if you can't see it please just give
me pointers to the code which passes events up and I'll have a look
myself.
I'll probably have more as I do more testing, but here's the fist batch:
1. Bug: Middle-button dragging and Shift-middle button zoom rubberband
still do not
work. Are you using a mouse with a middle button to test? They work in
Selector but not
in Node.
2. Lost feature: when rotating/scaling nodes by keys and one node is
mouseovered, it is
used as center of rotation and scaling.
3. Lost feature: when ctrl+alt+dragging a node, it should slide along
the handles _and
their perpendiculars_.
4. Lost feature: when ctrl+alt+dragging a node, and it has a linear segment on
one side, it should slide along the continuation of that segment.
5. Lost feature: node sculpting. Will you work on it, or do you want
me to work on porting it?
6. Bug: select a single node and rotate it by [] with or without Alt:
it rotates around
some random center far away, instead of around itself.
7. Lost feature: When rotating a handle with Ctrl, it now snaps to the original
position and 15 deg increments from that original position. The
previous behaviour was:
snap to origin, its opposite and perpendicular, to
vertical/horizontal, and to 15 deg
steps from vertical. This is much more useful because more often, I use Ctrl to
snap it to vertical or some simple angle like 60 deg.
8. Lost feature: create a cusp node next to a linear segment; press Shift+S; it
becomes semismooth, aligned with the segment (correct); now press
Shift+S again; old
behavior is to make it fully smooth, extending the second handle, but
your tool does nothing.
9. Lost feature: Rotating a handle with Shift before allowed to rotate
the second handle
by the same angle, thus rotating a cusp node as a whole; now it does nothing.
10. Suggested feature: now that we can edit multiple paths, Ctrl+A when nothing
selected should do the same in Node tool as in Selector, instead of
doing nothing as
now.
11. Performance: Create a path with thousands of nodes (paste text,
convert to path,
combine), select it in Node tool: notice how slow it all becomes,
freezing for many
seconds, as you simply move your mouse over the path. My guess is that
it calculates
something on each motion event and does not cache the results. The old
tool also wasn't
very snappy in such situation but it was much better, only freezing
for a couple seconds
at most with the same file (test it!) partly because it cached the livarot
representation of the path it used for proximity/over the path calculations.
12. Lost feature: the statusbar used to say how much total nodes are
there ("2 of 5
nodes selected") and, for a single node, its type (smooth, cusp,
auto). For multiple
subpaths it said e.g. "2 of 9 nodes selected in 2 of 3 subpaths". Now
it only says
"Selected 2 nodes" (which is also a wrong word order, suggesting an
action instead of a
state). Could you please just copy this part from the old node tool?
13. Suggested feature: now that we can select multiple objects, the
statusbar hints must
reflect that, in the same way as subpaths, e.g. "2 of 9 nodes selected in 2 of 3
subpaths in 1 of 2 selected paths", or simply "2 of 9 nodes selected
in 1 of 2 selected
paths" if there are no subpaths involved.
14. Bug: when dragging a node handle, statusbar erroneously says "Move
by" instead of
"Node handle:" as did the old tool.
15. When mouseovering a node, it says "click to select" even if it is already
selected. I'd like to copy this from the old tool as well, which
suggested various
modifiers for dragging instead.
16. On the node deletion discussion, I found the current behavior
satisfactory: if you
Del, you get curved approximation; if you Ctrl+del you get linear segment from
linears. I think this is logical (unless I miss something).
17. UI suggestion: since the show/hide seltrans handles button belongs
to visualization,
it should be moved to the right end of the controls bar, next to node
handles and node
outline toggles.
18. Crash: draw a path; draw a path and apply it as mask; draw another
and apply as
clippath; go to node tool; enable both mask and clippath editing; drag
a mask node; drag
a clippath node; drag a node of the path itself; undo 4 times - crash.
19. UI bug: create with Pen a Spiro path; now switch to Node tool -
the green outline of
the source path is visible always, even when "show outline of path"
toggle is off and
"show path parameter" was never pressed. Also, as we discussed in the summer, I
suggested a purple color for LPE parameter paths, so they are not confused with
clippaths.
20. Crash (somewhat hard to reproduce): With Pencil in Spiro mode,
create a path with
just two nodes (click, click). Now create a curved doodle path
(unrelated bug in Pencil:
you need to deselect first path before drawing second, otherwise they
will become
joined!). Now select both paths, go to Node. Select the end node of
the linear path and
start node of the curved path. Mouseover the latter and press Shift+J.
Then press Ctrl+Z
while still mouseovering the joined node. Crash:
Program received signal SIGSEGV, Segmentation fault.
Inkscape::UI::NodeList::closed (this=0xbfffe3dc) at ui/tool/node.cpp:1060
1060 {
(gdb) bt
#0 Inkscape::UI::NodeList::closed (this=0xbfffe3dc) at ui/tool/node.cpp:1060
#1 0x085fc574 in Inkscape::UI::CurveDragPoint::_getTip
(this=0xb8d57c8, state=4) at ui/tool/curve-drag-point.cpp:152
#2 0x085fadc1 in Inkscape::UI::ControlPoint::_updateTip
(this=0xb8d5790, state=4) at ui/tool/control-point.cpp:470
#3 0x085fb914 in Inkscape::UI::ControlPoint::_setMouseover
(p=0xb8d5790, state=4) at ui/tool/control-point.cpp:460
#4 0x085fc122 in Inkscape::UI::ControlPoint::_eventHandler
(this=0xb8d5790, event=0xaf56a80)
at ui/tool/control-point.cpp:411
#5 0x085faad8 in Inkscape::UI::ControlPoint::_event_handler
(event=0xaf56a80, point=0xb8d5790)
at ui/tool/control-point.cpp:298
#6 0x0824dd28 in sp_marshal_BOOLEAN__POINTER (closure=0xb5c0270,
return_value=0xbfffe80c, n_param_values=2,
param_values=0xad41600, invocation_hint=0xbfffe6b0,
marshal_data=0x85faac0) at helper/sp-marshal.cpp:352
#7 0x0056a072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#8 0x0057f7a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#9 0x005809b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#10 0x012b38ee in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x081c66df in emit_event (canvas=<value optimized out>,
event=0xb8d57c8) at display/sp-canvas.cpp:1348
#12 0x081c68e3 in pick_current_item (canvas=0x985c060, event=<value
optimized out>) at display/sp-canvas.cpp:1491
#13 0x081c9431 in sp_canvas_motion (widget=0x985c060, event=0xaf58340)
at display/sp-canvas.cpp:1603
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
13 years, 5 months
Mac OS X: osx-dmg.sh - osascript: dmg_set_style.scpt
by Wolf Drechsel
Hello everybody,
I tried to dmg inkscape 047 X11 - but ended up with an image, which
contains a link to /Applications and a folder called "Contents" -
which seems not to be a .app bundle.
When running the osx-dmg.sh, I get the message:
osascript: dmg_set_style.scpt: No such file or directory
In fact, the dmg_set_style.scpt cannot be found on my machine, it
looks as if it were contained by earlier source packages and dropped
recently.
Could somebody be so kind and mail me the script - or - in the case -
guide me to another solution of that problem.
Yours, Wolf
13 years, 5 months
Adaptable UI problems
by Krzysztof Kosiński
I have some doubts about the adaptable UI feature.
Part 1: UI issues
- The UI mode selection combo box (called "Task" for some reason) has
usability problems: 1. it jumps around when changing mode, so every
time I change it, I have to find it again to try another mode; 2. when
the main commands toolbar is vertical, it causes a very large
horizontal padding on it, even when it's hidden in the overflow menu.
- Tearing off toolbars does not adjust their size to fit the controls.
If I tear off a toolbar from a small window, I get a toolbar with an
overflow menu. If I tear off from a maximized window, I get a toolbar
with lots of unused space. This makes tearing off highly useless.
- Toolbars can be torn off but can't be attached in a location
different that the original one. This is because they use
GtkHandleBox, for which the docking position is fixed. At the same
time GDL has a widget named GdlDockBar which sounds like a true
dockable toolbar (but it might as well be something else, I don't
know).
Part 2: UxManager class
- UxManager::setTask: Magic constants in switch.
- UxManager constructor: "tags" is created but doesn't do anything.
- What is the point of having several desktops attached to one UxManager?
Part 3: util/ege-tags.h, util/ege-tags.cpp
- ege-tags.h: It supposedly implements
http://create.freedesktop.org/wiki/ResourceTagging but at present I
don't see any place in Inkscape that could make use of tagging.
- Even if the aforementioned specification was good, the UxManager
class apparently tries to do two completely unrelated things: manage
external resources and change the UI mode.
- TagSet: if I understand correctly what this class attempts to do, it
should use std::tr1::unordered_map<Tag, int> with appropriate hash and
equality predicates instead of the combination of std::vector<Tag> and
std::map<std::string, int>.
Part 4: other problems
- toolbox.cpp:1578: code related to changing the UI layout uses a
switch to assign function pointers. Polymorphism should be used
instead.
Regards, Krzysztof
13 years, 5 months
New memebr and a bug (maybe)
by CoD
Hello, I'm a 31 years old developer from Italy and I've been using
Inkscape for years.
I've just subscribed to this mailing list and.. yeah... I'm already here
with a bug report :P
Recently I experienced a strange behaviour with KDE 4 preview system and
svg/svgz files saved with the last version of inkscape (both stable and
devel version) so I decided to contact you.
I hate duplicate/unclear bug reports so I would like to discuss this
thing a bit with you before filing a bug to launchpad.
So, let's try to explain what I've found
System: Kubuntu 9.10 with KDE 4.3.2
Inkscape: devel version and 0.46 (See below)
Reproducible: yes
These are the steps I did:
1) I drew a simple icon with inkscape (a circle and a polygon)
2) I save it as svg or svgz (get the file here [1])
3) The preview on my kubuntu 9.10 looks crazy (get the preview here [2])
as if nodes position has been screwed
4) I open the svg file with Inkscape 0.46
5) I change the color of an element and save again
6) The preview still looks crazy
7) I open the file again with Inkscape 0.46 but this time I move the
polygon around, then I place it in the old position and save
8) The preview looks perfect, as if nodes position has been restored (get
the file and the preview here [3][4])
I can't really understand what's going on here but seems that KDE 4 has
troubles when previewing svg/svgz files saved with inkscape > 0.46
This happens also using ksvgtopng to convert an svg file to a png
Could this possibly be related to bug 170049 [5] ?
If you need more experiments just ask :-)
Thank you
Claudio Canavese (CoD)
1: http://cod-web.net/inkscape/devel.svgz
2: http://cod-web.net/inkscape/devel.png
3: http://cod-web.net/inkscape/046.svgz
4: http://cod-web.net/inkscape/046.png
5: https://bugs.launchpad.net/inkscape/+bug/170049
13 years, 5 months
