Inkscape for embroidery
by Michael Soegtrop
Dear Inkscape Developers,
I added a few features to Inkscape for use in embroidery, because the
commercial tools available don't offer the artistic flexibility I want.
I would like to have your opinion on if you think it makes sense to
integrate such functionality into the Inkscape mainline, or if it would
be too much of a stretch. It boils down to some LPEs and an export
format. The commercial tool I have from Bernina (a Swiss sewing machine
manufacturer) is based on Corel Draw.
Below is a list of the additions I did / I am working on.
Please let me know what you think about this. With these additions,
Inkscape offers substantially more flexibility than affordable
commercial SW (and affordable here means 500..1000$).
Best regards,
Michael
1.) Ways to fill an area with clusters of contours
Inkscape already offers 2 path interpolation LPEs which allow this. I
plan to add a 3rd one which creates a set of equidistant inset/outset paths.
2.) A way to connect sub path of a path into one continuous path
I added an LPE to do this with various options of end interpolation.
Maybe if I use bool-ops I need to extend it with some sort of sorting,
cutting and auto reversing mechanism to keep the connections short.
3.) A way to cut a path into stitches (straight line segments) in a
controlled way.
I added an LPE to do this, but it is quite primitive as yet.
4.) Bool ops on paths because in embroidery you cannot simply hide an
object below another one.
I just added a bool-op LPE for this - needs some additional work to cut
contours against a closed path.
5.) A tool to convert graphics output to some format an embroidery /
sewing machines can read.
I wrote an external tool to convert HPGL to a common embroidery format
(stitch/DST), but could also integrate this into Inkscape.
6.) Maybe a tool to hide connections between path segments below filled
areas. For a sewing machine it is quite complicated to do a "pen up" -
it has to cut the threads, so one typically hides connection paths below
some embroidery to avoid thread cutting.
Currently I do this semi-manually. Doing this automatically might be
quite complicated.
7 years
performance problems and possible remedies?
by Yale Zhang
Hi. I'm using Inkscape to author a comic and the slow speed for certain
things is very annoying. I'm already have OpenMP turned on and using 4
cores.
1. *large blurs are slow* - I'm an expert with writing SIMD code, so I was
thinking about vectorizing the Gaussian IIR filter with SIMD intrinsics,
even though it's harder than for a FIR. But I noticed there isn't any SIMD
code in Inkscape so does that mean it's something to avoid.
I'm pretty sure no current compiler is smart enough to vectorize it, and
besides, Inkscape is compiled with -O2, meaning -ftree-vectorize isn't on
by default.
2. *when there's a large image (raster based) background - scrolling in a
zoomed region is very slow*
I compiled the latest 0.49 code with GCC profiling and it shows this:
33.98 22.47 22.47 exp2l
21.29 36.55 14.08 log2l
17.57 48.17 11.62 pow
7.12 52.88 4.71 658 0.01 0.01
ink_cairo_surface_srgb_to_linear(_cairo_surface*)
6.72 57.32 4.44 563 0.01 0.01
ink_cairo_surface_linear_to_srgb(_cairo_surface*)
5.51 60.96 3.64 1216 0.00 0.00
Inkscape::Filters::FilterGaussian::~FilterGaussian()
5.23 64.42 3.46 internal_modf
0.59 64.81 0.39 _mcount_private
0.41 65.08 0.27 __fentry__
0.12 65.16 0.08 GC_mark_from
0.09 65.22 0.06 5579 0.00 0.00
Geom::parse_svg_path(char const*, Geom::SVGPathSink&)
0.06 65.26 0.04 35320 0.00 0.00
bounds_exact_transformed(std::vector<Geom::Path,
std::allocator<Geom::Path> > const&, Geom::Affine const&)
0.06 65.30 0.04 8 0.01 0.01
convert_pixbuf_normal_to_argb32(_GdkPixbuf*)
0.05 65.33 0.03 885444 0.00 0.00
std::vector<Geom::Linear, std::allocator<Geom::Linear>
>::_M_fill_insert(__gnu_cxx::__normal_iterator<Geom::Linear*,
std::vector<Geom::Linear, std::allocator<Geom::Linear> > >, unsigned long
long, Geom::Linear const&)
The cost is absolutely dominated by ink_cairo_surface_srgb_to_linear() and
ink_cairo_surface_linear_to_srgb(). My first instinct was to optimize
those 2 functions, but then I thought why are those even being called every
time I scroll through the image?
Why not convert the images up front to linear and stay that way in memory?
If that can't be done, then my optimization approach is:
1. replace ink_cairo_surface_srgb_to_linear() with a simple 3rd degree
polynomial approximation (0.902590573087882 - 0.010238759806148x +
0.002825455367280x^2 + 0.000004414767235x^3) and vectorize with SSE
intrinsics. The approximation was calculated by minimizing the square error
(maxError = 0.313) over the range [10, 255]. For x < 10, it uses simple
scaling.
2. replace ink_surface_linear_to_srgb() with a vectorized implementation
of pow(). Unlike srgb_to_linear(), a low degree polynomial can't be used
due to the curve having larger high order derivatives. An alternative would
be piece wise, low order polynomials.
The main question I have is what degree of accuracy is desired? Certainly,
it doesn't need double precision pow() since the input is only 8 bits! Is
+- 0.5 from the true value (before quantization) OK or do people depend on
getting pixel perfect results?
UJ
7 years, 2 months
xverbs
by Dmitry Zhulanov
Hi, all!
Im a game developer and using the inkscape for layouting my game
screens. Loading_screen_layout.svg one of them. It have g with id
pause_button and rect with id sandclock_bound which I use for animation
placement.
The verbs feature which inkscape already have is have some limitations.
The MAX_PATH for example. Also some verbs required user interactions, so
I need some eXtended verbs here.
Using python script I have load layout as xml and collecting
element-id's of interactive elements with "onclick" attribute, for
example. Using this element-id list I generate .yaml, which is some sort
of batch file. Here is the .yaml file which is used with Inkscape to
clean up layout and put button image in separated file with
pause_button.svg filename. Also I count undoable actions to restore
state generating verb EditUndo.
command: inkscape -B loading_screen_layout.yaml
----------- loading_screen_layout.yaml ---------
run:
- xverb-id: XFileOpen, loading_screen_layout.svg
- xverb-id: XUndoLabel, fresh_document
- xverb-id: XSelectElement, pause_button
- verb-id: EditInvert
- verb-id: EditDelete
- verb-id: FitCanvasToDrawing
- xverb-id: XFileSaveAs, pause_button.svg # save with stupid name
- xverb-id: UndoToLabel, fresh_document
- xverb-id: XSelectElement, pause_button
- verb-id: EditDelete
- xverb-id: XUndoLabel, fresh_document
- xverb-id: XSelectElement, sandclock_bounds
- verb-id: EditDelete
- xverb-id: XUndoLabel, fresh_document
- xverb-id: XFileSaveAs, loading_screen_layout_release.svg # save
with stupid name
- verb-id: FileQuit
------------------ CUT HERE --------------------
I guess you can get readonly access on my launchpad page.
https://code.launchpad.net/~dmitry-zhulanov/+junk/inkscape-xverbs
Code is tested with mingw+windows7+VS2010 sdk.
If you would like to merge the feature, I will clean up code to
conforming code style, remove printf's & so on
Any help or advice are appreciated!
P.S. sorry for my bad english :)
Best Regards,
Dmitry Zhulanov
7 years, 2 months
Stroke to path
by Jabiertxo Arraiza Cenoz
Hi to all.
This is a requets tor change "path->stroke to path" menu item to
another definition -string- based in a new code.
My proposal is path->to path
This new code basicaly do a convert stroked item to path retaining
paint-order, fills and markers.
The patch is here:
https://bugs.launchpad.net/inkscape/+bug/1556592
Cheers, Jabier.
7 years, 3 months
Doc scaling compatibility issue (Bug 1389723)
by Bryce Harrington
What do you think we should do about the release-critical DPI bug?
We need a decision on a course of action.
One of the changes we're bringing in this release is changing the
definition of px from 90 dpi to 96 dpi, but a consequence of this is
that documents created in 0.91 or earlier will become mis-scaled if used
in 0.92. This is tracked in the following bug report:
https://bugs.launchpad.net/inkscape/+bug/1389723
This is a release-critical bug, the sort that is likely to become a
thorn in our side in the near to mid term as users start running into
it more and more. Longer term it will diminish as our users move to
newer versions, but I imagine it'll take multiple years before it goes
away completely.
I don't think we should consider reverting the change; it was introduced
pretty early on this development cycle so backing it out could cause
secondary bugs to crop up. Also, it's a change that has to be done, so
if we don't do it this release we'll have to go through all the trouble
again next release anyway.
One proposed approach is to detect the affected files on load and
display a warning with a recommendation to convert the file manually.
Javier has posted a conversion tool that could be made use of; it's
received a fair bit of testing but there may be some remaining corner
cases to sort out; on the plus side with it being a discrete utility
fixes could be rolled out for it without needing full Inkscape releases.
The other proposed approach would be for Inkscape to internally convert
files, so that no warning is needed. In theory this would provide a
better user experience, but is going to require a lot more developer
effort and thorough testing. I'm doubtful that all of this can be done
adequately within the timeframe we're looking at for the release.
Both approaches also require a mechanism to detect affected files, which
sounds like it may be the tricky part here, as our SVG documents haven't
had versioning information we could rely on for this case.
Do you have thoughts on other ways to address this issue? Do you have a
strong opinion on whether for this release we should use the expedient
approach or else postpone the release until the more user-friendly
approach can be developed? Or should we reconsider a revert of the DPI
switch so we can get the release out and re-enable it post-release in
hopes the issues can be worked out?
Bryce
7 years, 3 months
Request for Comments on an Idea - Rendering Tests
by Shlomi Fish
Hi all!
Do you think it would be a good idea to make Inkscape's test suite more
comprehensive by making sure some (= as many as we can) input SVGs result in the
same bitmap images after being rendered by --export-png? It won't be too hard
to implement, and may prevent regressions.
Regards,
Shlomi Fish
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Humanity - Parody of Modern Life - http://shlom.in/humanity
<ew73> VB.NET is all of the fun of enforced privacy OO with all of the power
of BASIC. — Freenode’s #perl
Please reply to list if it's a mailing list post - http://shlom.in/reply .
7 years, 4 months
Account request on the wiki
by Sylvain Chiron
Hello all,
I'm a quite new (several months have gone now…) French translator for
the project, stealing progressively all the translation tasks to Mr
jazzynico. I also work a little on the website project.
I would like to get an account on the wiki, to be able to write glossary
info for French as a first reason, because such a glossary would be very
useful to other translators and I like to share the core nodes of my
work. Other reasons would be trying to update/improve pages or correct
their little mistakes, as I can't bear working with mistakes,
obsolescence and non-compliance without attempting to correct them (I
love the wiki system for that).
Please set Frigory as my username.
Thank you; regards,
--
Sylvain Chiron
7 years, 4 months
Board meeting June 3rd
by Bryce Harrington
Reminder that our June board meeting will be this Friday in
#inkscape-devel at noon Pacific time.
http://wiki.inkscape.org/wiki/index.php/Board_Meetings
Agenda is above. There were a lot of action items out of the May
meeting, so please doublecheck on your tasks and come ready to report.
There will be an informal 0.92 release meeting after the board meeting
(1pm US pacific time). Potential topics include a run through of
release critical bugs, the about screen contest, translation work,
platform packages of the release candidate, etc.
Thanks,
Bryce
On Sun, May 08, 2016 at 01:22:35PM -0700, Bryce Harrington wrote:
> On Tue, May 03, 2016 at 12:34:18PM -0700, Bryce Harrington wrote:
> > May's meeting is coming up. It'll be in #inkscape-devel at noon Pacific
> > time (2000 UTC).
> >
> > http://wiki.inkscape.org/wiki/index.php/Board_Meetings
> >
> > This will be a good opportunity to debrief from the hackfest and
> > identify followup actions that the board should work on in coming
> > months.
> >
> > Bryce
>
> Thanks everyone for attending, that ended up being an impressively
> productive meeting. I've gone through the meeting log and pulled out
> action items:
>
> http://wiki.inkscape.org/wiki/index.php/Board_Meetings
>
> I've penciled in Friday, June 3rd as our next meeting, and jotted in an
> agenda to followup on a number of the items we touched on this week.
>
> Bryce
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Inkscape-board mailing list
> Inkscape-board(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-board
7 years, 5 months
Arcs in the path editor.
by unknown＠example.com
Hi,
I've not contributed to inkscape before, this is my first time.
I have created a branch which supports editing elliptical arcs in
the node editor.
I'm new to bazaar (and inexperienced with launchpad) so I think I've
done the right thing with a merge request here:
https://code.launchpad.net/~danieljabailey/inkscape/arc_node_editor/+merg...
(but thought I'd check by asking on this list.)
Is this an interesting feature?
If so I can polish it up for merging into the main repo.
Thanks.
Dan.
7 years, 5 months
