Re: [Inkscape-devel] [Inkscape-user] Slow performance on 4.5 MB file [SOLVED]
by Jasper van de Gronde
And please be sure to file a bug/feature request at
http://bugs.launchpad.net/inkscape/
In the end there will obviously always be cases where Inkscape is too
slow, but Inkscape could most definitely be faster in some cases. And
just locking/unlocking the layer should (from an intuitive standpoint)
NOT cause such a big pause.
Dave M G wrote:
> Donn,
>
> Thank you for responding.
>
>> I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs
>> of RAM. It makes no difference. I think it's all the looping through those long
>> lists of nodes....
>>
>> You are doomed. Unless you can simplify or chop-up your comic page into frames
>> and assemble them later in Gimp.
>
> Okay. While it's a little disappointing that there isn't a way to
> optimize the file for better performance, it's good to know that at
> least I'm not doing something wrong.
>
> I'll export the paths into a PNG and handle the colouring in Photoshop
> or GIMP. It means committing to rasterizing the images sooner in my
> process than I had hoped, but hey, life is full of compromises.
>
13 years, 3 months
File Export (Save-As) Tests for v0.47
by Tavmjong Bah
Hi,
I've tested all the various file export options under the Save As
command. Would the relavent experts for each type please review my
comments/questions below? All test were done with Fedora 9 Linux and
0.46+svn updated within the past couple of days. Thanks.
Tav
General comment: I am having trouble getting Uniconvertor to work from
within Inkscape. It won't process files with text (error message about
not finding correct font). Files without text produce SVG output
(Uniconvertor 1.1.4), independent of which file type is selected. Or
error message about not finding SVG file in /tmp (Uniconvertor 1.1.3). I
may have screwed something up but Uniconvertor does work when used via
the command line (as in "uniconv test.svg test.plt") to directly convert
SVG files to other types. Does anybody have it working from within
Inkscape under Linux?
File Format:
.ai: Missing. Failed to load message in extension-errors.log (same error
for DXF and ESPI). Works in v0.46.
.dfx: Generic AutoCAD export failed to load (see .ai). Plotter version
updated. Question: what is the target if the "ROBO-Master output" option
is not checked?
.emf: Does this still only work on Windows? Uses Uniconvertor.
.eps: This is using the same export dialog as PS. Is this appropriate
given that the bounding box is handled differently? Speaking of which,
while the specifications do say the bounding box should be the smallest
rectangle that fully encloses the drawing, it is a common practice (and
very useful in scientific work) to define the box to be bigger than the
drawing. In reading the specification, it seems to me, that they were
more concerned that the bounding box takes into account stroke width,
etc. than in prohibiting bounding boxes larger than the drawing size. I
think it should be left up to the user to decide this.
In the past "Canvas" has been used to refer to the entire drawing area
while "Page" has been used to refer to the SVG specified drawing area.
The dialogs and command line options should use "Page" wherever "Canvas"
is used.
.fx I see small bugs in gradients and displaying a pattern.
.gpl OK.
.hpgl I see bugs in object transformations. Uniconvertor as of 1.1.4
also generates .hpgl files. Uniconvertor doesn't handle Inkscape
circles.
.odg. Small translation problems.
.pdf. Generally OK. Bug in patterns made from a group of objects drawn
off the page. Export dialog almost the same as for EPS and PS but small
differences in wording and in order of options. Should match with EPS
and PS dialog.
.plt Uses Uniconvertor. Tool tip etc. state it is AutoCAD plot file...
but this is really, as far as I can tell, just HPGL.
.png Duplicates "Export Bitmap" menu entry but without handling Filtered
objects.
.pov Broken in v0.47. Extra lines are added to object descriptions.
Works in v0.46 (some paths missing).
.ps See EPS and PDF comments.
.sk1 Uses Uniconvertor.
.svg OK
.svgz Broken in v0.47. Works in v0.46
.tex PSTricks OK, PSFrag needs work-around due to Cairo font subsetting.
.xcf OK
.wmf Uses Uniconvertor.
.xaml Objects translated wrong (could be xaml input problem).
.zip OK.
13 years, 4 months
InkscapeForum.com for offer to Inkscape.org
by microUgly
If you don't know, I run www.inkscapeforum.com--a relatively successful phpBB
forum for Inkscape users.
I created the forum because I knew there was demand and at the time I knew I
could devote a lot of time to make it successful. But I was never fond of
the idea that a single person would have ownership of the data accumulated
from the community.
I wanted to offer ownership of the forum to Inkscape.org. Ideally this only
needs to go as far as knowing that if I were hit by a bus, someone could
step in and take over. I don't know how things are ran on the inkscape.org
site, but I would be offering the entire setup to be hosted by inkscape.org
(if possible).
I would happily continue to moderate, and administer the board if
appropriate access were given. And I would redirect inkscapeforum.com to
the new domain, or change it's name servers.
Anyway, discussion open. Would Inkscape.org be interested in adopting the
forum? The forum won't be shutdown regardless of the answer.
--
View this message in context: http://www.nabble.com/InkscapeForum.com-for-offer-to-Inkscape.org-tp24673...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
13 years, 5 months
Re: [Inkscape-devel] rotating guides
by Diederik van Lierop
Op Wo, 1 juli, 2009 12:01, schreef LucaDC:
> These are my humble suggestions:
> 1) when moving the guide (no modifiers) you always also move (and snap)
> the
> origin, that goes under the cursor, in 2D (so wherever you click you
> always
> grab the guide at its origin: why moving the guide keeping the origin at
> the
> original distance from the grab/snapping point?); this behaviour would be
> consistent (=intuitive) to what happens when you create a guide;
That makes sense! If no one comes up with a valid use case for the current
behavior then I will implement it the way you suggest.
> 2) if shift is pressed when clicking, the guides always rotate (snapping
> to
> what's around or, if you press ctrl after the rotation is started, to
> absolute angles, i.e. always starting from 0, using the step specified in
> the preferences for when rotating objects);
So shift rotates ...
> 3) if ctrl-shift is pressed when clicking, the origin moves constrained to
> the guide (snapping to what's around projected perpendicularly to the
> guide;
> if you want something different you can create a new guide and snap to the
> intersection, while creating a guide perpendicular to a given one is not
> always straightforward; this is a general consideration regarding snapping
> while constrained).
... but when "adding ctrl to shift" not only it becomes constrained, but
it also changes from rotation to translation. In my opinion using ctrl
should only make the motion constrained, and not change the type of
transformation simultaneously.
So:
A) when dragging with no modifiers we will move the origin to the pointer
location (freely, in 2D)
B) with ctrl we will have a constrained translation of the origin along
the guide
C) with shift we will rotate
D) with ctrl-shift we will rotate to increments of the absolute angle
and with A), B), and C) Inkscape will snap depending on the snapping
parameters.
It looks like we're converging here, aren't we ;-) ? What do you think?
Diederik
13 years, 6 months
Inkscape scripting API (Draft)
by Glimmer Labs
Here is the first draft of a Dbus based Inkscape scripting API:
http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html
(Many thanks to the ConsoleKit team for the scripts and build system I
used to generate this documentation.)
I would welcome any comments or criticisms, the interface is very much
still up in the air so any suggestions, from small changes to major
issues, would be welcome.
I would particularly like to hear if people think that this would
potentially support the ways in which they use Inkscape, or whether
there are use cases this doesn't address. If there are lots of uses
that this interface does not support, additional interfaces geared
towards different users could be added. (In fact there was originally
one more interface than there is now, see document_new() for details.)
If you like the current API (in general) feel free to suggest
additional functions or functionality.
Finally, how would you like to see this extended? Dbus has proven to
be quite responsive and robust for this application. How would you
build off the basic platform of the Inkscape application interface?
I will keep the posted link updated as I make changes based on peoples feedback.
-Soren
13 years, 7 months
Win32 NSIS installer
by Chris Morgan
Hi all,
Today I decided to take a look at the NSIS installer for Win32, and decided
to optimise it. It currently uses a macro and function for reading options
from the command line. Since then, FileFunc.nsh has had added to it the
GetParameters and GetOptions macros, which make the code inside the
installer obsolete. I was amused to see that the option-reading code was
made by (a different) Chris Morgan in 2004! For your assurance that I
hopefully know what I'm doing, I have had lots of NSIS experience, mainly at
PortableApps.com, where our launchers and installer are in NSIS. NSIS is an
area I can help in, unlike the one I wanted to do more,
https://bugs.launchpad.net/inkscape/+bug/398603, which I'd like to fix but
can't really.
I also optimised readability and similar through the use of LogicLib's
logical code structures.
I cleaned up the language sections significantly, using a single macro
rather than a section for each, containing a macro. In all of them, polng
was equal to lng, with the exception of Japanese which had, incorrectly, jp
rather than ja for lng. lng was only used for "..\..\inkscape\*.${lng}.txt"
anyway - a mask which matches no files for any language. I'd propose that
that line be vanquished as it's not used (historical?). In the meantime, I
simplified it into one argument for the two. More on languages later.
While doing this I found about half a dozen minor bugs, all of which I've
fixed.
Starting at line 1382 (old), that set of things had the conditions the wrong
way around, so it would only print the detail if it was *empty*, rather than
if it was something... utterly insignificant, but a bug :D More
importantly, all the code around that section was inefficient, I rearranged
it to make it more efficient. Also the deleting HKCU\.svg[z] thing was
looking for the wrong thing, fixed that.
The biggest bug I found was that single-user installations didn't work (at
least judging by the code). The shell var context had been formerly set to
"all", and the all users section set it to "all" and had a bit of code which
wouldn't ever get executed. I got around this the easiest way, which was
just to create an unshown section before it to SetShellVarContext current.
All in all, I took it down from 1559 lines (47,874 bytes) to 930 lines
(34,534 bytes) (60% of the lines, 72% of the filesize), shrunk the installer
output by about 25KB (0.07% :P), fixed some bugs and made it more readable
in the process.
Now for some discussion on what I reckon having looked at it.
Languages: I can optimise those still further, just thought I'd send round
what I'd got so far. In particular, I want to change it so that no
languages are installed by default; this would speed up installation on
Windows exponentially - due to the LZMA solid compression used, each
language takes an inordinate time to install. I think I can fix that up
too, but I'll need to experiment on it a bit. Moving the files first should
help in the technique... I'll try it out and report back. However, back on
the main topic, I want to change it so English is not shown on the list
(it's really pretty meaningless, it's an empty section... and the
SectionGroup is "Translations" of the interface, English is pretty much a
given), and so that the only language which is installed is that which the
installer is running in. I can do that easily enough. Possibly also the
MUI LANGDLL should be displayed to let the user choose the initial language.
Presets: we've got the SectionIn 1 2 3 bits all over the place, but aren't
using the presets at all (any more I guess from commented out code). I
think they should be added back, that way you can have all languages in
full, the suggested one in optimal and none in minimal. Also I think that
quick launch and desktop icons should be on by default.
Start menu: currently this is forced on, in a set location, which isn't very
nice. We should use the MUI STARTMENU stuff.
I also think that a lot of the DetailPrint bits should be cleaned up to
either be removed or so they can be more useful.
The welcome and finish pages should get their own images, I'll make a
proposal for it. Also the header image should get the new logo; likewise I
can do that.
Right, I think that's enough for now, though I've probably forgotten
something I was going to say, and missed a bug or two I fixed.
-- Chris Morgan <chris.morganiser@...400...>
I don't need a quote in my signature. It's hard enough surviving as it is
without having to find a meaningful quote. Will you forgive me? Or don't
you read this bit?
13 years, 7 months
Updated bug hunt tally: 378/500 Bug hunting stalled!!
by Tavmjong Bah
The current bug hunt tally is now 378/500. Newly fixed bugs:
6 168387 van Lierop Display mode toggle doesn't update radio...
3 396580 JazzyNico non-ASCII characters not displayed...
The average number of points per day has dropped to 1 in the past
week!! Bug hunting seems to have stalled.
Let me know if you think I missed any bugs that should have been
credited. Remember, they must be marked Fixed Released or Fixed
Committed.
Tracked at:
http://wiki.inkscape.org/wiki/index.php/Release_Info_for_0.47
Tav
13 years, 7 months
Boost.Intrusive
by Krzysztof Kosiński
Hello all
In my GSoC project I need to represent nodes in a linked list. The
requirements are:
1. Obtaining an iterator from the value should be a constant time operation
2. Ownership semantics should be similar to boost::ptr_list - that is,
objects are owned by only one container and deleted when erased,
though there are special functions that allow transfer between
containers and releasing an object from a container
3. The list must have a 'closed' flag that determines the behavior of
2 functions that retrieve an iterator to the next and previous node:
If it's true, they wrap around, and if it's not they behave like
regular ++ and -- on iterators.
Initially I thought about std::list + std::tr1::unordered_map of
pointer to node -> iterator, but this is absurd. Then I created my own
NodeList class, which worked well enough, but I feel that implementing
all the operations is reinventing the wheel. I could use
Boost.Intrusive (specifically boost::intrusive::list) to satisfy 1 and
2 out of the box and 3 with a small amount of work. However, I can't
find what version of Boost we currently depend on. Boost.Intrusive is
a header only library that was released as part of Boost 1.35 in April
2008 (there are no runtime dependencies, so the only possible issue is
whether developers run recent enough systems to have it available). It
is available in Debian Lenny, as a backport for Etch, and in Ubuntu
Hardy LTS. Is it OK to use it?
Regards, Krzysztof Kosiński
13 years, 7 months
Extracting a saturation map with SVG filters ?
by Ivan Louette
I can't figure how I could extract a saturation map (as a greyscale image) with SVG filters. My idea is using it to replace any hue of an image with only one like it's done with cyan in the joined png created with Xara Xtreme Linux Edition. I am searching for a long time already but without success. Perhaps not possible.
In Xara I only put a cyan rectangle above the image and apply the "Hue" transparency type. I was able to synthezize all Xara's color effects but this one.
ivan
13 years, 7 months
Re: [Inkscape-devel] File Export (Save-As) Tests for v0.47
by ~suv
On 31/7/09 22:18, Tavmjong Bah wrote:
>>> .dfx: Generic AutoCAD export failed to load (see .ai).
>> 1) missing helper_extension 'org.inkscape.output.ps'
>> (related bug #407215 <https://bugs.launchpad.net/inkscape/+bug/407215>)
>> proposed fix: in dxf_output.inx
>> s/org.inkscape.output.ps/org.inkscape.print.ps.cairo/
>>
>> the 'AutoCAD DXF (*.dxf)'output extension is loaded and creates DXF
>> output if pstoedit is installed, though I cannot get pstoedit to create
>> DXF files that can be re-imported in Inkscape (on OS X 10.5.7, pstoedit
>> 3.45).
>
> This seems to work but it calls up the PostScript output dialog which I
> am not sure is the best. Qcad does read the output dxf OK. Tested on
> Fedora 11 with today's svn.
AFAIU pstoedit depends on the intermediary .ps format as inkscape output
because it does the conversion ps->dxf. Latest version of pstoedit 3.45
is from September 2007.
Maybe the helper_extension could to be changed like the one used for the
'print preview' which doesn't prompt for PDF output options either (or
does 'print preview' use Postscript output?).
Using 'org.inkscape.print.ps' instead of 'org.inkscape.print.ps.cairo'
doesn't work although it's defined in src/extension/extension.h.
Or there are other cross-platform converters available that can do it in
one step: svg->dxf (besides Alvins enhanced dxf_outlines.py extension)?
~suv
13 years, 7 months
