- Inkscape Devel - Inkscape Mailman

Screenshots of bool LPE with new slice-inside and slice-outside bool ops.
by Michael Soegtrop 28 Feb '16

28 Feb '16

Dear Inksacpe Team, here are 3 screen shots of the bool-op LPE and the new slice-inside and slice-outside bool ops I implemented this weekend: www.Michael-Soegtrop.de/Inkscape/slice_off.png www.Michael-Soegtrop.de/Inkscape/slice_inside.png www.Michael-Soegtrop.de/Inkscape/slice_outside.png In the slice-outside image please note that the cut shape is transparent - it is not just hiding the lines below. Of cause all normal bool-ops are also supported by the LPE. Since I want to supply a patch for embroidery use based on 0.91 soon, I implemented it based on the old livarot mechanisms, but the new bool ops are just 200 lines with quite a few comments, so I don't see much of an issue to port it later. The main work was anyway thinking about how to do it so that it works reliably and not implementing it. The filltype parameters I will remove and get them from the paths instead. I think these bool-ops are quite useful for normal drawing (not embroidery) as well as a more generic kind of hatching. Best regards, Michael

2 1

Quality of gradients.
by Gez 28 Feb '16

28 Feb '16

A few weeks ago, Tavmjong added a comment to bug #180693, asking if the reported issue was still present with the new renderer. I'm answering here, as I'm adding some personal comments that probably don't belong to the bug report. Please tell me if it's is worth that I add some of this information to the bug report, or feel free to do it if anyone wants to. Regarding the question, As long as Inkscape renders at 8bpc, yes. It will still be a problem. It's possible that some sizes and colors hide the problem more than others, but banding will still be a problem unless images are rendered in higher precision. The easiest way to check this is to draw a grayscale gradient. At 8bpc, you can't paint more than 256 shades of gray. So a 256px-wide gradient will look ok, but as soon as you stretched that gradient to a larger size, banding will appear. An even more extreme example (but not less frequent) is when you also have a grayscale gradient, but instead of going from black to white you go from a middle gray to a lighter gray. If your gradient takes, say 50 levels out of those 256, stretching the gradient will result in severe banding sooner. I don't think it's possible to address banding in 8bpc without some form of dithering, and it looks that the current renderer doesn't apply any. As I mentioned in an older comment, the best way I could find to work around this was using the "spread" filter in GIMP, which jitters the edges of each step of the gradient making it look smoother. There are existing dithering algorithms that could be used too, like floyd-steinberg, bayer, a-diher (http://pippin.gimp.org/a_dither/), etc. but I wonder how effective would they be as we don't have a smooth gradient as a starting point, but a stepped one. Those dithering algos could be useful if inkscape rendered at 16bpc, to bring down the display to 8bpc though. At any rate, rasterizing a vector shape and applying a filter would be prohibitively slow for large sizes so this dithering, if applied, should be probably applied only to export, making this solution unsuitable for on-screen representation. Anyway, I don't think banding is too much of a problem (it is, but it's not as severe) for screen as it is for printing. For printing it becomes a critical issue, as other commenters pointed out. Inkscape is a valuable tool for large format printing which I use daily, and time to time I have to apply some nasty workarounds because of this limitation. For my professional work, the way inkscape renders gradients is a show- stopper. The quality of my work suffers if I don't apply one of those tedious workarounds discussed in this thread. This bug has been reported about 8 years ago, and a lot happened since. Maybe this time, with a new renderer there's something that can be done to get it fixed? Gez

4 11

Win64 devlibs update
by Eduard Braun 28 Feb '16

28 Feb '16

Hi all, as some of you might already have noticed I'm working on a major update for the win64 devlibs. Current status: Both trunk and 0.91 build fine and seem to work without obvious flaws on my system! Most of the binaries are contributed by Partha Bagchi whom I'd like to thank very much again! Almost all dependencies were updated to the latest available version and rebuilt from scratch with gcc 5.3. Although work is not yet finished I'm at a point were I'd like to encourage you to test my changes: * If you want to compile Inscape from scratch you can do that as usual [1]. However you'll need a checkout of the updated devlibs branch, see https://code.launchpad.net/~inkscape.dev/inkscape-devlibs64/5.3 The updated compiler is available as part of a MinGW-w64 package available from https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20… Lastly you'll need an updated build-x64.xml. I temporarily uploaded a copy for both trunk and 0.91 branch to my Google drive, see https://drive.google.com/open?id=0B3IZiqBj23X1My1CaUE2NjlpVms * If you want to start testing right away, I also provided pre-built packages available from the same link https://drive.google.com/open?id=0B3IZiqBj23X1My1CaUE2NjlpVms I'll push some further smaller updates in the coming days. If no bugs or regressions are discovered I'll propose to merge the update after that. Thanks for testing, Eduard [1] http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_64-bit

2 4

Wrote a Boolean LPE - How to make operand path invisible?
by Michael Soegtrop 27 Feb '16

27 Feb '16

Dear Inkscape Developers, I just wrote a Boolean OP LPE. It was quite easy using sp_pathvector_boolop. It works well, just I can't figure out how to make the operand path, which comes in via a OriginalPathParam, invisible. Also I have one design question: Some operations are symmetric, others not. Currently my interface has a bool_op enum and a swap operands bool parameter. I wonder if it would make more sense to combine these into one like: uninion intersection this minus operand operand minus this ... I think this would be easier to use, but it would break consistency with the existing bool op menu operations. Best regards, Michael

2 2

Re: [Inkscape-devel] Website Design
by Martin Owens 26 Feb '16

26 Feb '16

Yesterday Mc- brought up a design for the inkscape website which got a few approval nods from various attending people: https://yadi.sk/i/CfqypzmvpPbay I contacted the designer at the time and just heard back. So what we have here is a psd of a single page that flows downwards. I expect it to assume a standard set of css frameworks such as bootstrap or similar. I also know that Hinerangi has some designs waiting in the wings for the website and that we've stalled on moving more improvements in. I'm interested in hearing wider feedback from the community since I've been under the impression that the website's design has been fairly serviceable. A replacement would be a fair amount of work and at the moment I'm only committed to making sure the technical integration of any proposed design goes ahead without any barriers. What do you think we should do? Best Regards, Martin Owens

6 9

Re: [Inkscape-devel] Create a SVG chart from Excel/Libreoffice Calc data sheet?
by Martin Owens 26 Feb '16

26 Feb '16

Moved to devel: Question: Should we add nicecharts to inkscape trunk? https://github.com/Moini/NiceCharts/tree/patch-1 My answer: yes as long as simplestyle is available, Maren responded with the email below. Maren do you want to do the honours since you're the new upstream :-D Martin, On Thu, 2016-02-25 at 22:30 +0100, Maren Hachmann wrote: > simplestyle comes with Inkscape. It's one of those helper py modules > in > the extensions directory. > > (http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/e…) > > I agree it would be useful for people to have that by default. > > (Isn't your question more for the devel list or a bug report at lp?)

3 5

ReadTheDocs
by Krzysztof Kosiński 25 Feb '16

25 Feb '16

ReadTheDocs is a site that can build documentation and serve it online after every commit to a repository. We used to have something similar, but it ceased to work at some point. It looks like it's fairly simple to mate Doxygen with ReadTheDocs (which uses the Sphinx documentation system) using a project called Breathe. http://breathe.readthedocs.org/en/latest/ I'll try to set this up for lib2geom tomorrow and report on the results. Best regards, Krzysztof

2 3

Website design
by Jelle Mulder 25 Feb '16

25 Feb '16

Martin, It may have gotten some approval nods, but mine certainly isn't one of them. Responsive design is nice and all to have and something that needs to be addressed if it hasn't been done already, but this design doesn't cut it. I would also refrain from completely overhauling the current design aspects (colour, type) which are not bad at all. What I see here is a two or possibly 4 column collapsable design that has a splash screen with a download button and some icons on the bottom. All readable info would be off screen in case of a small factor screen. What's the point of that? There is no Android or iOS version of Inkscape, so that would be besides the point wouldn't it? You would only want to be able to read some info rather than the download button. Nor does it strike me as good practice to lard your entry page for smart phones with sizable bitmaps. In my view it just doesn't appeal, both from UI, UX and design point of view. Back to the drawingboard I'd say and give it some thought this time. The website design as it is has room for improvement from a marketing point of view, but in general is quite functional and to the point. Nor am I a great fan of the scrollmania that is so popular these days as a reflection of small factor readers. Single page view designs are still preferable to the hot swipe that goes around as fashionable and hip. Yes to responisive design, but why not make the current design responsive and not just by tossing it into bootstrap. Cheers, Jelle > Message: 1 > Date: Wed, 24 Feb 2016 10:51:25 -0500 > From: Martin Owens <doctormo@...400...> > Subject: Re: [Inkscape-devel] Website Design > To: inkscape-devel <inkscape-devel(a)lists.sourceforge.net> > Cc: Hinerangi Courtenay <hine.courtenay@...36...>, inkscape-user > <inkscape-user(a)lists.sourceforge.net> > Message-ID: <1456329085.3092.11.camel@...2056...> > Content-Type: text/plain; charset="UTF-8" > > Yesterday Mc- brought up a design for the inkscape website which got a > few approval nods from various attending people: > > https://yadi.sk/i/CfqypzmvpPbay > > I contacted the designer at the time and just heard back. So what we > have here is a psd of a single page that flows downwards. I expect it to > assume a standard set of css frameworks such as bootstrap or similar. > > I also know that Hinerangi has some designs waiting in the wings for the > website and that we've stalled on moving more improvements in. > > I'm interested in hearing wider feedback from the community since I've > been under the impression that the website's design has been fairly > serviceable. A replacement would be a fair amount of work and at the > moment I'm only committed to making sure the technical integration of > any proposed design goes ahead without any barriers. > > What do you think we should do? > > Best Regards, Martin Owens >

1 0

Re: [Inkscape-devel] inkscape text alignment icons
by Martin Owens 24 Feb '16

24 Feb '16

Dear Claus Staedtler, Thank you for emailing me :-) I think it's a good idea to harmonise where possible. Inkscape's icons are a mix between our icon packs (a tango theme and a symbolic mono-color) none of our themes have text alignment icons (only object alignment icons). In order to use the proposed icons they would have to be installed into the system's icon theme. What is the status of gimp and libreoffice regarding using system icons? Best Regards, Martin OWens P.S. I've forwarded this conversation to the inkscape developer's mailing list (without attachment) we can sort that out later. On Sun, 2016-01-03 at 11:44 +0100, staedtler-przyborski wrote: > Dear Martin Owens, > > first a happy new year > > I recently added to the new gimp symbolic icon theme some icons. > > As my idea is that inkscape/gimp/libre-office .... use the same symbolic > icons whenever they do the same (which is quite often not the case) > I've made additionally made some text-alignment icons for gimp (it uses > currently system-icon-theme, like inkscape). > > I thought inkscape might want to use these icons too (so they would be > identical in gimp and inkscape and libreoffice). > > I've added symbolic and colored icons as svg. The symbolic icons are > derived from libreoffice, you might want to correct the color (for what > reason ever, inkscape uses different gray than libreoffice and > libreoffice a different than gimp in their symbolic icon theme ..., > maybe someday in future this will be harmonized too). > > It's up to you to make use of them or put them into trash. > > Regards > > Klaus Staedtler >

2 1

Re: [Inkscape-devel] Website Design
by Martin Owens 24 Feb '16

24 Feb '16

Hi Hinerangi, Thanks so much for posting a screenshot of your design, I like it very much. What I like about your design is: * The colour theme, I've grown to like the white an black clean lines * The non-scrolling, single page, makes it easier to do information pages using the same * The news and other information is closer to the top. What I like about eshill's design is: * The four horizontal images for each of the sections * The cleaner download button, separate and large for the first page. * The icons for the information sections (news, users etc) But getting a responsive design would be really nice IMO. One of the best advances for the site. Martin, On Wed, 2016-02-24 at 17:51 +0000, Hinerangi Courtenay wrote: > Oh, I wasn't aware of this new redesign – I had a few propositions > going already, one which was posted to the mailing lists a little more > than a year ago > (https://www.dropbox.com/s/m2f988q3jqn2vbr/mockup-hp-2014-26-12_v0.1.png?dl=0), and a second which was being done directly in the HTML/CSS code (consulting with Martin directly). > > The second one was more of an evolution than a redesign, to make the > existing site work responsively and bring it up to date with current > aesthetics. I've attached a screenshot of the work-in-progress for > reference, but obviously if the community prefers to push it in a new > direction, that's cool too :)

1 0