- Inkscape Devel - Inkscape Mailman

New SVG close path command.
by Tavmjong Bah 26 Aug '14

26 Aug '14

Hi, I'm sure we've talked about it before but in the context of discussing the new Catmull-Rom path commands[1] yesterday at the SVG Working group meeting we briefly discussed adding a new close path command that would insure smoothness when closing a path. There is significant support for doing so. Can somebody whip up a quick proposal that I can present to the group? (SVG with a couple of figures would be good.) Or at least give me some input into the idea. We have two more days of meetings, Monday and Tuesday. Thanks, Tav [1] https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomCommand

5 10

inkscape-0.91pre2 source tarball
by Bryce Harrington 24 Aug '14

24 Aug '14

Download it at: https://sourceforge.net/projects/inkscape/files/inkscape/0.91pre2/ Tagged in trunk as: INKSCAPE_0_91_PRE2 It would be helpful if packagers could generate binary platform packages from this tarball, and upload them to sourceforge. If you spot packaging problems (like version numbers that didn't get updated correctly, or missing files needed for builds), please raise these problems with me ASAP. If you need assistance uploading packages to sourceforge please contact one of Inkscape's sourceforge admins. Bryce

4 7

Re: [Inkscape-devel] splitting FAQ in 2
by Brynn 22 Aug '14

22 Aug '14

Sorry, I forgot to say this. I looked in the manual for documentation on LaTeX, but it's not nearly as detailed as what's in the wiki. I could simply link to the manual (http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions-Render.html#Extensi…), but then a lot of info will be lost. So in asking about how to handle this kind of documentation, I'm asking how to avoid losing helpful info. Or maybe in this case, the wiki info is outdated? I'm not very familiar with LaTeX. In any case, I'm asking about "some official documentation". :-) brynn -------------------------------------------------- From: "Brynn" <brynn@...3133...> Sent: Tuesday, August 19, 2014 3:02 AM To: "Bryce Harrington" <bryce@...961...> Cc: "Inkscape-Devel" <Inkscape-devel(a)lists.sourceforge.net> Subject: Re: [Inkscape-devel] splitting FAQ in 2 > "These days our documentation is actually quite thorough, and the FAQ > could probably leverage it better. For instance, it could give a brief > answer and a couple hints for the most common things people want to do, > and then "For more detailed information about customizing Inkscape, > please see the <link>Customizing Inkscape</link> chapter of the Inkscape > Manual" (or whatever)." > > As I suspected, there are indeed a lot of user-related pages in the wiki. > For this page: > http://wiki.inkscape.org/wiki/index.php/Customizing_Inkscape, Bryce > suggested: > "I think it's a bit too much for the FAQ. The contents of that wiki page > looks like it really ought to be part of some official documentation, > like the man page or something." > > Now I just ran into this page: > http://wiki.inkscape.org/wiki/index.php/LaTeX (which is linked to faq item > 2.5). I suppose this should be part of "some official documentation" as > well. But documentation, in general, is a part of Inkscape that I'm not > so familiar with. > > Really, the only documentation I know about, is the manual, the official > tutorials, and the wiki (aside from Launchpad and Sourceforge docs). So > my next question, is how to handle items which need to be added to "some > official documentation". Is there a particular person who is in charge of > documentation? I could make a list and give to this person. But then my > work can't get finished, until their work is finished. Well, then maybe I > should handle it myself? But I would need a bit of guidance. I certainly > can copy/paste, and write some html. It's just where to put it, that I'm > not sure. > > Maybe I could make a new page (at first on staging site, of course)? I > would just transfer all wiki content which is currently used to answer > user questions in the faq, to this page, and link to the info there. > > However, I suspect Bryce had something else in mind with "some official > documentation". > > How should I handle this kind of documentation? > > Thanks again, > brynn > > -------------------------------------------------- > From: "Bryce Harrington" <bryce@...961...> > Sent: Sunday, August 17, 2014 12:56 PM > To: "Brynn" <brynn@...3133...> > Cc: "Inkscape-Devel" <Inkscape-devel(a)lists.sourceforge.net> > Subject: Re: [Inkscape-devel] splitting FAQ in 2 > >> On Sun, Aug 17, 2014 at 01:48:24AM -0600, Brynn wrote: >>> Thanks Bryce. >>> >>> "> Similarly, if you follow the user list or the #inkscape user channel >>> and >>> >see questions being asked a lot (and that sound likely to continue >>> >being >>> >asked long in the future), consider adding Q&A's for those." >>> >>> I recently subscribed to the user list, but I didn't even know about >>> #inkscape user channel. That's an IRC channel...or....that's not >>> twitter, is it? (Sorry, I don't participate in the whole social >>> media thing.) However, I'm quite familiar with messages posted in >>> forums, and somewhat with messages posted in Launchpad Answers. >> >> Yes, it's an IRC channel. For more info see the end of this page: >> >> * http://inkscape.org/en/community/discussion/ >> >> Fwiw, the Jabber info on that page is all obsolete I think. >> >>> I'll make a list of the bad links (dead, empty, not found pages) >>> (which I guess is what you mean by "bitrot"), and send them to you. >>> Maybe you can find them somewhere. >> >> Yes, that's what bitrot means. >> >> FWI, I'm on travel this coming week so might not be very responsive in >> the near term, but will catch up once I'm back. >> >> We also have an #inkscape-devel channel, which you're welcome to join as >> well. su_v is very active there and she might be able to help if I'm >> not around. >> >>> Speaking of a listing of tutorials -- would those be only "official" >>> tutorials? Or should all kinds of outside tutorials (such as listed >>> on my webpage) be found on the Tutorials page? Already, there are >>> lots of tutorials from a deviantART feed that Martin set up (which >>> are "outside" tutorials). But with such a listing of outside >>> tutorials, again, you'll have the bitrot issue, and possible >>> frequent requests to be listed. >> >> The FAQ probably should only directly link to the official tutorials >> (the ones that appear in-program). Those are the ones we have direct >> control over and can prevent bitrotting. >> >> I'd love to see more work go into the Tutorials section, but don't have >> specific advice. The Tutorials page doesn't need to be limited to >> official tutorials. I like how Martin set it up to pull from deviantArt >> because then we don't have to worry about bad links on our end. >> >>> "Our >>> >software documentation is also a lot better than when this FAQ was >>> >initially written, too." >>> and regarding the Customizing Inkscape faq item >>> "> There might be a few other FAQ items like this, that should just move >>> to >>> >proper docs." >>> and >>> "Also I think it probably isn't that >>> >'frequent' of a question so once it's in the program documentation it >>> >can be dropped from the FAQ." >>> >>> Are you suggesting that if documentation for an faq item exists, >>> that it should be deleted from the faq? Or that the answer should >>> be deleted, and instead should link to the documentation? >>> >>> Because I think a lot of people, maybe even most people, think of an >>> FAQ for just exactly that "frequently asked questions". Perhaps the >>> faq has been used in the past, as a place for developers to put >>> answers, and for users to find answers, when no other documentation >>> exists. But I'm not sure taking it completely out of the faq would >>> be appropriate, if it truly is asked for frequently. For >>> customizing Inkscape, I can say that it is asked surprisingly often! >>> I've even heard people say they won't use Inkscape unless they can >>> have a customized theme! (Of course, imo, that's their problem, but >>> it is a fairly common topic.) (And btw, easily customizable themes, >>> or "skins", is a much wished-for feature!) >> >> Yes, I completely agree with all of this. It's true that in the far >> past we did put stuff in the FAQ that should have just gone into regular >> docs but we didn't have those at the time. Since then I think a lot of >> that has been scrubbed out. I just want to suggest that if you feel >> there is stuff in there that's a bit too much for the FAQ, then moving >> it into proper documentation is the right way to go. >> >> These days our documentation is actually quite thorough, and the FAQ >> could probably leverage it better. For instance, it could give a brief >> answer and a couple hints for the most common things people want to do, >> and then "For more detailed information about customizing Inkscape, >> please see the <link>Customizing Inkscape</link> chapter of the Inkscape >> Manual" (or whatever). >> >> Bryce >

2 2

I think I have a good compile at last
by john Culleton 21 Aug '14

21 Aug '14

all the various sources I have used for inkscape0.91 blow up at the same point, on a file called threads.h So in desperation I copied this file from Ubuntu to Slackware. The location is exactly the same on both systems: /usr/include.2.4/glibmm/threads.h There are other files on my Slackware partition called threads.h but this is the one Inkscape 0.91 uses. Currently my attempt at a bzr based compile has produced 0.91pre2r13528. The key to that process is to run autogen.sh, then ./configure and make. BTW Inkscape compiles run longer than any others I have done on any system since I worked on tape-only systems in the 1960's. But the results are worth it! :<) -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

4 4

Swatch dialogs improvements
by Tomasz Boczkowski 20 Aug '14

20 Aug '14

Hi! I've introduced some of the improvements to the swatch dialog, that were discussed on the mailing list. First of all the default behavior when applying solid color swatches is to apply them by color value. There's a toggle button added, that allows to switch to the mode in which solid colors are applied by reference to a paint server [1]. Currently the paint server is linear gradient, but since solidColor elements are in codebase, the dialog will use them in the future. Second improvement is related to the appearance of the swatches dialog. Padding between swatches was removed and an option to turn on borders was added [2]. The dialog also supports 16x16 tile size [3]. In this case the tiles representing gradients, patterns and hatches are bigger. Hatch support was added to Swatches dialog and Fill and Stroke dialog [4]. The UI allows to select and apply a swatch. The swatch properties dialog allows to change pitch and rotate parameters. Files containing hatches can be placed in hatches subdirectory in either user config or global config directories. I've used the file [5] containing default AutoCAD ANSI hatches. Because the end of GSOC 2014 is near, I'd like those code changes to be last ones. I'll spend the last days on writing code documentation. Hovewer if you see something that definitely has to be done before monday, please let me know. The project will evolve after GSOC ends. I'll try to make the paint preview more compact. An on-canvas editing tool for hatches will be usefull too. Regards Tomasz [1] https://www.dropbox.com/s/5wh4kojl3puht6i/swatches-link.mpeg [2] https://www.dropbox.com/s/pdp1zefvr7ha1rn/swatches-borders.png [3] https://www.dropbox.com/s/urezznmjgb6s5y1/swatches-small.png [4] https://www.dropbox.com/s/g4d9psnvgfftus3/swatches-hatch.mpeg [5] https://www.dropbox.com/s/nysmx6tl0t4hqf1/ANSI.svg

4 4

splitting FAQ in 2
by Brynn 19 Aug '14

19 Aug '14

Hi Friends, I've been helping Martin on the inkscape.org website. And that somehow has grown to include the wiki. But of course, I'm glad to help. He says user info, such as forums, tutorials and galleries should not be part of the wiki, so that the wiki is only for developers. I've already transferred (and updated!) some of that user-related stuff to a test page for the website (http://staging.inkscape.org/en/brynntest/?edit&language=en). (I think all the galleries need to be moved to another page, but that hasn't been decided yet, that I know of.) (If the Community page looks like that, then the Learn page would look like this http://staging.inkscape.org/en/brynns-learn-page/?edit&language=en). Anyway, there is a *whole bunch* of user-related stuff in the wiki, and he said it would be better to ask the community about some of these questions. Since the current FAQ, which is shown both in the wiki and on the website, has as much user-related info as developer info, it needs to be split into 2 FAQs, which I've just started working on. (Maybe the user faq would be on the Learn page?) I find that the answer to item 2.11 (Is there a way to apply a gradient to a stroke so that it bends with the stroke?), links to 2 images, which are no longer there. If I knew what the author of that faq item was talking about, I could substitute some other images. I sort of know what the text is alluding to, but without the images, it's not clear. There are at least 3 or 4 ways that I know of, to fake a curved gradient (although maybe just a couple specifically for a stroke). And I can certainly describe each one (in the answer). And I know that there is a tutorial packed with Inkscape (share/examples/rope-3D.svg), which I can provide directions for readers to find. But the community is FULL of really nice tutorials. I know that, because of my research in writing this page on my Inkscape support website http://forum.inkscapecommunity.com/index.php. And coincidentally, I just wrote a tutorial on one of these techniques. So my first question: When I come across bad links, (dead, empty, not found pages, etc), what would be the best way to handle it? Can I link to any appropriate image or tutorial? Or should the links only go to "official" resources? What if those "official" resources don't exist? The 2nd question: When I come across answers to user-related questions in the FAQ, such as item 2.21 (Can I change the Inkscape theme?) where the answer is in wiki, what should I do? In this case, the answer provides a link to here: http://wiki.inkscape.org/wiki/index.php/Customizing_Inkscape which is a fairly substantial page in the wiki. If that info should not be in the wiki, where should it be? Should I write all that info from the wiki page, in the answer in the faq? Thanks for your help. And btw, since I'm such a newbie to the mailing list, please let me know if I say or do something wrong. All best, brynn

7 19

Siggraph2014 - Vector Graphics Complexes
by Mark Schafer 18 Aug '14

18 Aug '14

Some interesting features here: - https://www.youtube.com/watch?v=-XONNPyeb5U#t=122 http://www.dalboris.com/research/vgc/

2 1

Windows XP, cannot compile rev 13520
by alvinpenner 16 Aug '14

16 Aug '14

the operative message appears to be: ============ cmd ============ windres -o build/obj/inkres.o --include-dir=src src/inkscape.rc ============================= Make error line 444: RC problem: windres: src/inkscape.rc:6: syntax error .................................................................................. full text is: C:\InkscapeBZR>btool dist-inkscape #################################################### # BuildTool v0.9.9multi #################################################### ######## PARSE : build.xml ============ cmd ============ bzr revno ============================= ######## PARSE COMPLETE ######## EXECUTE ##### Target : init ##### Do all preparatory tasks, like make directories and copy files --- init / mkdir mkdir : build --- init / mkdir mkdir : inkscape --- init / copy copy : src/helper/sp-marshal.h.mingw to src/helper/sp-marshal.h copy : skipped --- init / copy copy : src/helper/sp-marshal.cpp.mingw to src/helper/sp-marshal.cpp copy : skipped --- init / makefile ============ cmd ============ bzr revno ============================= makefile : src/inkscape-version.cpp makefile : skipped --- init / makefile makefile : config.h makefile : skipped ##### Target : cxxtest ##### generate test files --- cxxtest / cxxtestpart --- cxxtest / cxxtestpart --- cxxtest / cxxtestpart --- cxxtest / cxxtestpart --- cxxtest / cxxtestpart --- cxxtest / cxxtestpart --- cxxtest / cxxtestroot ##### Target : compile ##### compile the source to .o --- compile / cc cc : compile with 1 threads in parallel ##### Target : link ##### link objects and library to create executable --- link / rc ============ cmd ============ windres -o build/obj/inkres.o --include-dir=src src/inkscape.rc ============================= Make error line 444: RC problem: windres: src/inkscape.rc:6: syntax error -- View this message in context: http://inkscape.13.x6.nabble.com/Windows-XP-cannot-compile-rev-13520-tp4971… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 1

Re: [Inkscape-devel] precompiled version of 0.91 for Linux
by john Culleton 15 Aug '14

15 Aug '14

On Thu, 14 Aug 2014 09:09:02 -0500 Terry Brown <terry_n_brown@...36...> wrote: > > I've never had any trouble building it under > Ubuntu. I do > > sudo apt-get build-dep inkscape > > which makes Ubuntu install all the dependencies > that went into building the inkscape package > that comes with ubuntu, and then compiling the > inkscape bzr trunk as always seemed straight > forward. Just in case you weren't aware of > `build-dep`. Also this probably only works > with the "current" version of Ubuntu, seeing > it's most likely to have libraries at the > versions inkscape trunk needs. > > Cheers -Terry > > Well following the above instructions from Terry I now have a real live functioning Inkscape0.19pre1 working on a linux partition! Now all I have to do is rig my Ubuntu partition to do the things I am used to on slackware. I can take it from here. Thanks to all who offered help. Dog was not kicked. -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

1 0

Problem compiling inkscape0.91pre1 on slackware 14.1 (and others)
by john Culleton 14 Aug '14

14 Aug '14

./configure shows this: WARNING: glibmm/threads.h: present but cannot be compiled configure: WARNING: glibmm/threads.h: check for missing prerequisite headers? configure: WARNING: glibmm/threads.h: see the Autoconf documentation configure: WARNING: glibmm/threads.h: section "Present But Cannot Be Compiled" configure: WARNING: glibmm/threads.h: proceeding with the compiler's result configure: WARNING: ## ---------------------------------------------------------- ## configure: WARNING: ## Report this to http://bugs.launchpad.net/inkscape/+filebug ## -------------------------------------------------- Previous versions of Inkscape compile OK. When I attempt to report the bug as described above I end up on an Ubuntu page. Is that where inkscape bugs are to be reported? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

2 1

precompiled version of 0.91 for Linux
by john Culleton 14 Aug '14

14 Aug '14

Is there a precompiled version of 0.91 for linux--any version? I've tried pre0 and pre1, on slackware, Ubuntu and openSUSE. The errors vary, but glibmm seems to be the culprit. Second question: what version of glibmm are the developers using? It seems to work on Windows 7 using the precompiled version. But Windows really sucks when pulling illos off the screen. And the 0.91 main screen is significantly different from 0.48.5 Why is this a big deal? Well I am writing books on two applications, book covers and web pages, both using Inkscape. I don't want them to be instantly obsolete. Help! -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

4 4

Re: [Inkscape-devel] 0.91 Bug Hunt Status
by Liam White 13 Aug '14

13 Aug '14

> > 3 486192 4 08/04 Liam P. White In the node editor, both > stroke and fill use the same pattern handles > 10 604025 4 08/04 Liam P. White Can't edit stroke pattern > unless there is a fill pattern > 26 601336 4 08/04 Liam P. White Inkscape crashes when trying > to move or rotate stroke pattern > 36 1330295 0 08/05 Liam P. White This file causes a crash when > semi circle is moved > 18 1274831 0 08/06 Krzysztof Kosinski crash, spraying an object with > the mode: spray object in single path > 3 1241501 0 08/06 Jabiertxof Better tooltip to "Link path > parameter" > 6 1227193 0 08/06 Tomasz Boczkowski Warning: Failed undo group > after skew > 12 1327267 0 08/06 Liam P. White Dragging handles results in > calls to sp_style_read_from_prefs() > 24 1348375 0 08/07 Liam P. White trunk: randomized star/polygon > changes shape when moved (rev >= 12554) > 18 1335943 0 08/07 Liam P. White Inkscape crashes on quit > 14 1155046 1 08/07 jazzynico Assertion `pathlen < 200' > failed > 14 1093345 1 08/07 Tavmjong Bah Trunk fails to launch with > 'Pre-render named icons' if feFlood filter primitive is present in icons.svg > 12 1349018 0 08/07 Alvin Penner trunk: visual bbox of objects > clipped with a clone doesn't update when size of the clone's original is > changed (rev >= 10618) > 6 1354249 0 08/08 (unknown) Rotated ellipse and > measurements changed > 3 1341154 0 08/08 jazzynico Inner shadow filter must allow > to set shadow parameters > 12 195214 6 08/08 Daniel Macks Bad -I order > 8 383246 5 08/08 Krzysztof Kosinski fenv.h not used, some systems > don't have fenv.h > 3 1065928 1 08/09 Johan Engelen Cannot put text on cloned path > 7 1166184 1 08/10 jazzynico XAML export not compatible > with Silverlight > 6 1350817 0 08/10 Johannes Rssel XAML export omits fractional > stroke widths > 3 1248174 0 08/11 Alberto Salvia Novella Update the Ubuntu colour > palette to fit the spec > 10 508529 4 08/13 jazzynico Printing rastered image > offsets the page > 11 264831 5 08/13 jazzynico Print settings not persistent > > Total Score: 995 / 1500 > > Wow, what a big haul this week, with many people contributing fixes. > Liam took good advantage of the extended season on past nominated BOW's, > contributing over 100 points and pushing us to the 2/3rds mark. > > Liam, mind picking out another good bug for Aug 11-18? > > Bryce > Nice. How about a performance regression: https://bugs.launchpad.net/inkscape/+bug/1356192

1 0

On the use of C++ exception handling
by Rodrigo B Almeida 12 Aug '14

12 Aug '14

Dear all, I've been investigating the use of C++ exception handling constructs in open-source C++ projects (including inkscape). Currently, I am conducting a survey on this subject and I would really appreciate if you could contribute to this research by answering a few questions. The survey is available on-line: https://pt.surveymonkey.com/s/exceptionHandling All the best, Rodrigo.

1 0

Status of 0.91 and a vote on the bug hunt!
by Bryce Harrington 12 Aug '14

12 Aug '14

With us now at the halfway milestone for the bug hunt, this is a good point to reflect on how the release is doing, and I'd like to hear your thoughts. In past releases we set a goal of 500 points worth of bugs; today we've hit 778, which is pretty amazing! We set a higher goal than usual due to the length of time since our last release, knowing that we probably needed to give more time than usual for QA and to get things stabilized. How do you feel we're doing? Do you feel Inkscape is solid enough that we could call it good on the bug hunt and proceed with the next stage of the release (perhaps with a select list of must-fix blocker bugs)? Or do you think the bug hunt is helping stimulate a lot of good bug work that we should continue? Or something else entirely? Give me your vote publically or privately and I'll make the appropriate course changes to get the release moving ahead. Bryce

4 6

Review LPE Show Handles
by Jabiertxo Arraiza Cenoz 10 Aug '14

10 Aug '14

Hi to all, I lost ask for a reviewer to the new LPE. If anybody want, the code are in: https://code.launchpad.net/~inkscape.dev/inkscape/show_handles Jabier.

1 0

New LPE "Show Handles"
by Jabiertxo Arraiza Cenoz 10 Aug '14

10 Aug '14

A new video for a new LPE, is like show handles extension. I reuse -and improve- some of my simplify LPE to do it by a sugestion of suv. https://www.youtube.com/watch?v=h9ul_PR9XYo

1 0

0.48.5 and libsigc++-2.3.2
by Ken Moffat 08 Aug '14

08 Aug '14

Hi, I do some things at beyond linuxfromscratch ( http://www.linuxfromscratch.org/blfs/view/svn/ ) and have recently started including 0.48.5 in my own builds. We have been using libsigc++-2.3.1 for some time (I guess that whoever added it did not realis it was a development version), so we went with 2.3.2. Unfortunately, that breaks inkscape-0.48.5. The specific change was announced at https://mail.gnome.org/archives/libsigc-list/2014-August/msg00000.html where it mentioned runtime errors for users who added their own visit_each overload. In fact, for 0.48.5 it broke the build, and the relevant message appeared to be : /usr/include/sigc++-2.0/sigc++/visit_each.h:169:64: error: cannot convert ‘const sigc::adaptor_functor<sigc::bound_mem_functor0<void, SPDesktop> >’ to ‘int’ in initialization /usr/include/sigc++-2.0/sigc++/visit_each.h:169:29: warning: unused variable ‘do_visit_each’ [-Wunused-variable] { sigc::visitor<T_functor>::do_visit_each(_A_action, _A_functor); } ^ CXX device-manager.o Makefile:5958: recipe for target 'desktop.o' failed make[2]: *** [desktop.o] Error 1 Dropping back to 2.3.1 fixed it. One of my colleagues created a patch to locally revert that particular change in libsigc++ which also fixed the build. My first question [ at last! ] is: Do you care about people who build 0.48 with libsigc++-2.3-series ? If you do, any ideas how to fix this ? Thanks. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.

3 9

Cairo rendering of SVG arcs
by Liam White 08 Aug '14

08 Aug '14

Hi I found out that for certain SVG files, rendering can likely be sped up a lot by directly rendering SVG elliptical arcs with Cairo instead of converting them to cubic Beziers and rendering those. I expanded our current code in experimental to do that, and it... almost works. I'm not quite sure what I'm doing wrong at the moment, hopefully someone can help me with that! The code works well for perfect circles. It does not work well for ellipses, but doesn't seem to have any issues with rotation of ellipses. Any optimization tips would be appreciated, as this code is called extremely often. #line 558 "src/display/cairo-utils.cpp" else if (Geom::EllipticalArc const *a = dynamic_cast<Geom::EllipticalArc const*>(&c)) { Geom::EllipticalArc* tx = static_cast<Geom::EllipticalArc *>(a->transformed(trans)); Geom::Affine xform = tx->unitCircleTransform(); // Normalize the ellipse into a circle Geom::EllipticalArc * ax = static_cast<Geom::EllipticalArc *>(tx->transformed(xform)); bool sweep = /*ax->sweep(), large_arc = */ax->largeArc(); Geom::Point ce = ax->center(); Geom::Point ang(ax->initialAngle().radians(), ax->finalAngle().radians()); // Apply the transformation to the current context cairo_save(cr); cairo_matrix_t cr_trans; xform = xform.inverse() * trans; cairo_matrix_init(&cr_trans, xform[0], xform[1], xform[2], xform[3], xform[4], xform[5]); cairo_transform(cr, &cr_trans); if (!optimize_stroke || tx->boundsFast().intersects(view)) { // Draw the circle if (sweep) { cairo_arc(cr, ce[X], ce[Y], ax->ray(X), ang[0], ang[1]); } else { cairo_arc_negative(cr, ce[X], ce[Y], ax->ray(X), ang[0], ang[1]); } } else { cairo_move_to(cr, ax->finalPoint()[X], ax->finalPoint()[Y]); } cairo_restore(cr); delete tx; delete ax; return; } http://cairographics.org/manual/cairo-Paths.html#cairo-arc

3 2

Re: [Inkscape-devel] Cairo rendering of SVG arcs
by Liam White 07 Aug '14

07 Aug '14

Thanks Krzysz! That fixed it and now CLI rendering of a file with a tremendous amount of arcs seems to be a bit faster: Unpatched trunk: 0m9.161s Patched trunk: 0m7.577s However, something else I might have to investigate is that with my sample file, experimental seems to have suffered a serious performance regression: Unpatched experimental: 0m20.539s Patched experimental: 0m19.482s

1 0

Re: [Inkscape-devel] SVG2 hatch rendering
by Tomasz Boczkowski 07 Aug '14

07 Aug '14

> It doesn't look terrible here... > In particular it'd be good to know if you're using cairo that includes > the downscaling patch added to cairo last week. If not, then please > re-test with a newer snapshot of cairo. I use cairo 1.12.16 distributed with opensuse 13.1. Tomasz On Tue, Aug 5, 2014 at 10:40 PM, Bryce Harrington <b.harrington@...3042...> wrote: > On Tue, Aug 05, 2014 at 01:32:16PM -0700, Josh Andler wrote: > > On Tue, Aug 5, 2014 at 1:12 PM, Tomasz Boczkowski < > penginsbacon@...400...> > > wrote: > > > > > The image illustrating the aliasing problem is: > > > https://www.dropbox.com/s/r1hlmpwuagdq8cj/hatch_rendering_zoom.png > > > > > > > Is that possibly related to cairo or pixman version? It doesn't look > > terrible here... > > https://www.dropbox.com/s/amnq9c8c64thxrk/hatches.png > > In particular it'd be good to know if you're using cairo that includes > the downscaling patch added to cairo last week. If not, then please > re-test with a newer snapshot of cairo. > > Bryce > > > > >

3 4

Recent change to SVG parsing
by Krzysztof Kosiński 07 Aug '14

07 Aug '14

Hello Recently there was a change to SVG parsing in lib2geom, so that arc segments that end less that EPSILON (1e-5) units from where they begin are ignored. However, this threshold is completely arbitrary and there is no way to change it. I think this should either be changed to strict equality, or there should be a way to set this threshold (in Inkscape, it should be dependent on the numeric precision of XML output). Regards, Krzysztof

4 3

Re: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2
by Ruben Van Boxem 06 Aug '14

06 Aug '14

As the previous email was sent only to one person, see below as well :-) I forgot to mention one thing: MSYS2 has a clang that can be used to compile applications. Unfortunately, GCC 4.9.1 header locations aren't yet added to the build, so currently it's not possible to use it. Note that Clang on Windows only works on 32-bit (for now, will change in the future) and with the dw2 C++ exceptions implementation. It uses and links to libgcc and GCC's libstdc++, no libc++ on Windows yet. Ruben From: rubenvb.development@...3139... To: jbc.engelen@...2592... Subject: RE: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2 Date: Wed, 6 Aug 2014 15:22:13 +0200 Hi guys, I'm not replying in-line because, well, the outlook.com web interface doesn't indent the previous message like gmail does. Now I have a reason to stick with gmail :-p On-topic: I understand you like the devlibs setup, but as you say yourselves, setting it up and maintaining it is a pain. My message was just meant as an FYI, for your consideration. I won't prevent you from using the binary packages built by the MSYS2 project and integrating those into your devlibs. But I'd only think it fair you credit the project for their work (I'm actually not involved in its development in any way). I think just copying the libraries from the MSYS2 packages should work. Note that C++ is a bit more ABI sensitive than C, and those packages will need a matching GCC variant. (sjlj-dw2-seh and win32-posix internal GCC threads). C code will also be affected by the internal thread implementation GCC uses. Note this does not affect your code or the generated code whatsoever. Just what GCC (libgcc) uses internally. Huh, I didn't find any 64-bit builds on the download page, if you want them to be picked up, you should place them alongside the 32-bit builds, otherwise people aren't even going to try them ;-) http://inkscape.org/en/download/windows/ or http://sourceforge.net/projects/inkscape/files/inkscape/0.48.5/ Cheers, Ruben Date: Fri, 1 Aug 2014 21:00:58 +0200 From: jbc.engelen@...2592... To: inkscape-devel(a)lists.sourceforge.net; rubenvb.development@...3139... Subject: Re: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2 Hi Ruben, On 31-7-2014 16:11, Liam White wrote: The devlibs setup is actually the most simplified way to build Inkscape, because one does not need to download and install MSYS to build it on Windows this way. I agree with Liam. Our current setup for Windows is about as simple as I can imagine (for both 32 and 64 bit). The most difficult thing is setting up Bazaar, which is unrelated to setting up the build environment. Once one can checkout Inkscape's source, the only build setup steps that are required are: bzr checkout devlibs, and downloading and unzipping mingw. There is very little room for improvement here; certainly MSYS2's installation instructions are more 'difficult'. I don't think setting up our build setup is preventing developers on Windows to join the project. That said, there is a cost of our simplicity: someone has to maintain the devlibs. With the hard work of Partha and Liam, we have managed to get devlibs64 up; without them we probably still would not have had 64bit. 64-bit builds are possible because we modified our code to get it built with 64bit! We already have official 64bit builds :) It'd be nice to have another project maintain a "devlibs", effectively what MSYS2 would provide for us, possibly at the cost of some *reduced* simplicity in setting up the build environment (based of of the installation instructions online for MSYS2). Perhaps it is as easy as just copying the binaries/headers into our devlibs though... regards, Johan (Does MSYS2 provide clang binaries that are usable for compiling Inkscape?) On Jul 31, 2014 4:00 AM, "Ruben Van Boxem" <rubenvb.development@...3139...> wrote: Hi everyone, I wanted to explore the possibility of a 64-bit Windows build of Inkscape (for obvious reasons of increased memory availability), and discovered the "effort" had already been done by the great people of MSYS2 and MinGW-w64. I would strongly suggest the Windows developers look into switching to this development platform instead of the current, manually maintained "devlibs" setup. Perhaps this suggestion can be made more plausible if I attempt to explain what MSYS2 and MinGW-w64 provide. MinGW-w64 is an active project that provides Win32 headers and libraries so that GCC can be used on Windows, both 32- and 64-bit. It has replaced "ye olde" MinGW.org on numerous Linux distros (most notably Debian, Fedora, OpenSUSE, Ubuntu, and Arch). It is also the toolchain distributed alongside the Qt SDK releases. MSYS2 is an updated version of the old MSYS (it takes a newer version of Cygwin, applies the MSYS patches, and presto: a Unix shell environment for building Unix/cross-platform software on Windows). Additionally, MSYS2 provides a complete repository of binary packages, linux-distro style. What the developers did was port Arch Linux' package manager, pacman, and create a whole ecosystem around it of ready-made MinGW-w64 packages. The full list can be found here. You'll notice that the list contains a mingw-w64-inkscape package. What this means is that there is an easy way of obtaining/building/... inkscape on Windows, without the need to jump through too many hoops. I'm not saying you guys should drop everything and come hide in the shade of MSYS2, but instead evaluate the current build process on Windows, and perhaps provide a simplified way of developing Inkscape on this platform. A free bonus would be the possibility of providing a 64-bit Inkscape build, which is already possible without any 64-bit Windows patches thanks to good code by you guys ;-). Also note that cross-compilation from Linux shouldn't be much harder either, all the aforementioned distros have an extensive list of MinGW-w64 libraries at their disposal, and using CMake should make it all "just work". The current wiki's instructions look abysmally complicated compared to the simplicity made possible by the MinGW-w64/MSYS2 combo. I strongly hope you take this into consideration, as it will lead to a lower entry for developing Inkscape on windows, which in turn will lead to quicker bug-fixing (I hope ;-)). Thanks and keep up the fine work! Ruben (known as rubenvb in the MinGW-w64 mailing community)

2 1

SVG2 hatch rendering
by Tomasz Boczkowski 05 Aug '14

05 Aug '14

Hi! I've implemented the rendering of SVG2 hatches in lp:~penginsbacon/inkscape/svg-paints-support. How it works can be seen using a test file attached to this message. The rectangles in left columns are filled with hatches, while the ones in right columns are reference images consisting of clipped paths. What is still to be done is to implement rendering when overflow property is set visible. In addition to this, I have to improve rendering when hatch covered object is zoomed out. The second problem can be seen in the picture [1]. The cause is aliasing when rendered cairo_pattern_t is applied to a shape. One of the solutions is to adjust applied pattern size to full pixels. This can be achieved by manipulating the transformation applied to the pattern by ink_cairo_pattern_set_matrix in drawing-pattern.cpp:119. The drawback of this rendering hatch paths at displaced positions, what can be visible in case of large shapes. Another solution is to allocate pattern surface of the size of object bounding box and to draw all hatch paths on it. The third one is to increase oversampling and use CAIRO_FILTER_NEAREST for hatches. What techique do you recommend? I'd like to add hatches to Swatches and Fill and Stroke dialogs and prepare stock hatches based on ISO 128-50 standard being used in Europe for technical drawing. As there are more SVG2 elements supported in Inkscape, how should fallback to SVG1.1 look like? Should there be an another output extension? In case of hatches should they be converted to patterns? Regards Tomasz

7 14

[GSOC Swatches] Latest code check in
by Tavmjong Bah 05 Aug '14

05 Aug '14

Hi Tomasz, I just looked at your latest code check-in. You've added in style.h: sigc::connection fill_ps_changed_connection; sigc::connection stroke_ps_changed_connection; to the already existing: sigc::connection filter_modified_connection; sigc::connection fill_ps_modified_connection; sigc::connection stroke_ps_modified_connection; How does "changed" differ from "modified"? This is a place where adding a comment or two would really be helpful to some future developer in understanding the code. Any progress with hatches? Tav

2 2

Compiling 0.91pre1
by john Culleton 04 Aug '14

04 Aug '14

I get this error: -------------------------- CXX libdepixelize/kopftracer2011.o In file included from /usr/include/glibmm-2.4/glibmm.h:89:0, from libdepixelize/kopftracer2011.cpp:29: /usr/include/glibmm-2.4/glibmm/threads.h:142:11: error: field 'gobject_' has incomplete type GThread gobject_; ^ /usr/include/glibmm-2.4/glibmm/threads.h: In member function 'GThread* Glib::Threads::Thread::gobj()': /usr/include/glibmm-2.4/glibmm/threads.h:138:41: error: 'gobject_' was not declared in this scope GThread* gobj() { return &gobject_; } ^ /usr/include/glibmm-2.4/glibmm/threads.h: In member function 'const GThread* Glib::Threads::Thread::gobj() const': /usr/include/glibmm-2.4/glibmm/threads.h:139:41: error: 'gobject_' was not declared in this scope const GThread* gobj() const { return &gobject_; } ^ make[3]: *** [libdepixelize/kopftracer2011.o] Error 1 make[3]: Leaving directory `/usr/local/inkscape-0.91pre1/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/inkscape-0.91pre1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/inkscape-0.91pre1' make: *** [all] Error 2 ---------------------------------------- I get another kind of error on gobj_ when attempting to compile pre0. I use Slackware Linux 14.1 64 bit. Suggestions? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

2 1