- Inkscape Devel - Inkscape Mailman

roughen-improvements LPE
by Jabiertxo Arraiza Cenoz 19 Oct '15

19 Oct '15

Hi to all. First of all sorry for the noise whith the roughen related commits, the work is near end but finaly i decide made a new branch to reduce noise and also work in other place. I take the code working better in trunk but not working like I want so I think this week can fix it and propose for merge. Cheers, Jabier.

1 0

Re: [Inkscape-devel] Website Feedback
by Martin Owens 19 Oct '15

19 Oct '15

Hi Will, This is a great question and as the Website administrator I would normally ask you to post this in the appropriate channel. But to help get an answer (especially to your question about how to help to the features you want) I'm posting it to the developers mailing list. If you reply to any of the messages, you should subscribe to the mailing list first by looking at the email footer of that message. Developers and Users: see the message below and reply. Best Regards, Martin Owens Volunteer Website Administrator On Mon, 2015-10-19 at 15:30 +0000, Anonymous User wrote: > willprot@...36... > > There is only one thing that stops me from using Inkscape over > Illustrator and I have been waiting on it and checking on it for > literally years now and that is gradient meshes. > > Coloring an image is he most basic and integral part of graphics and > it is just way too easy & convenient to accomplish in AI to pass up, > > That said is there any time line for Gradient Meshes in Inkscape? > > Years ago the SVG2 specs for it were to be finalized Aug 2015, can't > see now where that is at. > > I also see there is a way to help certain project, but > A. not sure how? and B. If the SVG 2/Grad Mesh specs are not finalized > does that mean there can be no movement regardless for that?

3 2

2Gom sync - high potential for regressions after r14226
by Krzysztof Kosiński 18 Oct '15

18 Oct '15

Hello I recently made a commit that finally synchronizes the 2Geom version used in Inkscape and the "upstream" version in 2Geom's Launchpad repository. It compiles and appears to work correctly, but since there were several potentially breaking changes in 2Geom, it has a high potential for regressions. The most important changes in 2Geom are: 1. The sign convention for cross(Point, Point) was flipped to match the one for cross(D2<SBasis>, D2<SBasis>): it is a[X]*b[Y] - a[Y]*b[X], not the other way around. I think I converted all uses, but one can never know. 2. All nearestPoint() methods were renamed to nearestTime(), since they return time (parameter) values, not points. nearestTime() for Path and PathVector returns PathTime and PathVectorTime respectively. PathTime encapsulates a curve index and a time value, while PathVectorTime encapsulated a path index, a curve index and a time value. The reason for using these types instead of extending the range of the time parameter from [0, 1] to [0, N] is twofold: - Packing these two parameters into the double type causes a loss of acuracy as the indices increase. For example, referencing a point that lies on the 32nd curve causes a loss of at least 5 bits of precision. - For PathVector, there is an unnecessary O(N) step involved in mapping the [0, N] time value to path and curve indices. In the future, there will be two additional families of methods: nearestPoint(), which will actually return the nearest point (I avoided adding until the sync is done to simplify porting to the new API), and nearestPosition(), which will compute both the nearest point and the time value. Doing the latter can often save a lot of calculations, since in many cases the point is computed from the time or vice versa. 3. SVGEllipticalArc was renamed to EllipticalArc, and the old EllipticalArc was removed. The only difference between them was that EllipticalArc would throw exceptions if the constructor parameters did not specify a valid arc, whereas SVGEllipticalArc just falls back to a straight line. Additionally, a number of other improvements were made, for example EllipticalArc no longer allocates a copy of itself when transforming it. 4. There was a major cleanup of Path: - Iterating between begin() and end_closed() will skip the linear closing segment if and only if its endpoints coincide exactly. SVGPathParser was modified to retain the old behavior of considering the closing segment degenerate if it is shorter than some specified tolerance. - Internally, the path is now stored as a copy-on-write boost::ptr_vector of Curve. This should give a performance boost, since we are no longer using boost::shared_ptr-based copy-on-write for each curve, but only for entire Paths. - PathVector is now a real class, not a typedef of PathVector, This allows several things to be implemented as methods instead of as standalone functions. - PathSink was improved. Instead of creating a switch-like structure for the result of dynamic_cast of the abstract curve type to more concrete types, please derive from PathSink. - There is a new class called CairoPathSink for outputting 2Geom paths and shapes to Cairo. 5. Circle and Ellipse were fleshed out, and contain many of the methods found in Curve and Path. 6. There is a new intersection API, exposed as a method on shapes and returning a class that contains two time values and the point of intersection. There are methods for Line, Circle, Ellipse, Path and PathVector. Please test and report and regressions, but please make sure to check whether they are really regressions - for example the eraser tool sometimes doesn't work and it has nothing to do with the 2Geom sync, but rather with some faulty code in livarot. Regards, Krzysztof

3 8

CMake remaining items
by Marc Jeanmougin 15 Oct '15

15 Oct '15

Hi all, With su_v, we recently compiled some items left to do for CMake builds, so here it is. Feel free to take and fix anything on this list, or add anything that would be missing from it. --------------- CMake todolist -> add -std=c++11 to CXXFLAGS /if needed/ (by libsigc++>2.5.1 for instance)<https://bugs.launchpad.net/inkscape/+bug/1488079> ->make sure "make check" works and also checks extensions ->port options from configure to cmake : - WITH_GTK3_EXPERIMENTAL - WITH_DBUS - WITH_LOCAL_INSTALL (if dbus is ON) - WITH_LCMS - OSXAPP<https://bugs.launchpad.net/inkscape/+bug/1502774> - STATIC_BUILD - WITH_SILENT_RULES - WITH_SVG2 / WITH_LPETOOLS <https://gist.github.com/su-v/79199ba0ac5df2e2ac7c> --enable-strict-build -> use pkgconfig for imagemagick so that it correctly sets MAGICKCORE_HDRI_ENABLE and MAGICKCORE_QUANTUM_DEPTH. Also do the proper thing for pango and fontconfig. -> install man pages ->check remaining FIXME -> (automatically update author dialog from authors file?) -> set the version string if not built from a bzr directory - check that all cmake option variables //actually do/ /what they claim Windows : -> Add a variable to devlibs, and more generally get cmake to work as expected with "cmake .; make" on windows -> check dependencies -------------- -- Mc

8 7

Inkscape consultant and development needed
by Mats Blakstad 15 Oct '15

15 Oct '15

Hi I organize a postcard and translation project named Globalbility <http://en.globalbility.org/>. We use vectore graphic maps (see map icon in corner) and also the posters at the website is done in SVG (it is automatically created out of our translations using a SVG-template). The website i created using Drupal CMS <https://www.drupal.org/>, and I now look into possibilities to integrate new functionalities related to vector graphic on the website. More specificually I'm interested to look into how to *manipulate SVG using terminal commands*, and possibilities to *make Drupal and Inkscape communicate good (create a module)*. Also some general consulting about *text rendering in inskcape/svg* that is very important for multilingual SVG, and strategic planning for SVG2 for if/when it is ever coming. This is an open source project so anything that might be useful for others will be contributed back to Drupal and/or Inkscape. If anyone are interested and have time, please write me and tell me your working rate. Thanks Mats Blakstad

1 0

A discussion about color management in Inkscape
by Tobias Ellinghaus 11 Oct '15

11 Oct '15

Hello List, a while ago I filed a bug in launchpad about how Inkscape treats color spaces and does its display color management (https://bugs.launchpad.net/inkscape/+bug/1457053). As requested by Tavmjong I wrote up some further explanations in the hope that it helps people understand the problem and maybe start some discussion. First of all I beg your pardon for the wall of text. If you know about color spaces just skip the "Theory" part. In the following description I will only talk about RGB color spaces. For things like CMYK the same reasoning applies but I want to keep it simple. For the sake of readability. I will also simplify a terrible lot to keep this beginner friendly and easy to understand. Like, seriously simplify. No need to point that out. I am also aware that some of the limitations might be coming from the SVG specs or are at least implied in there (like the mandatory blending in gamma corrected or linear sRGB). Theory When we talk about (RGB, see above) colors we often only mention three numbers representing the value for each of the red, green and blue channel. In general 0 means "nothing" and 255 (8 bit values) or 1.0 (float values) means "full power". I will use the float notation here since it's easier to calculate in the head. Thus, something like (1, 0, 0) means "the reddest red" and (1, 1, 1) is "white". Now, there is a problem once you want to display such a color: What does "full power" or "the reddest red" actually mean? That's where color spaces come into play. They define a set of "primaries" that tell us what "red", "green" and "blue" actually mean. They are defined in absolute, real world means (most often in XYZ) that directly relate to specific wavelengths of light and precisely define a color that can be displayed. With that knowledge it's possible to say that (1, 0, 0) is not just some reddest red, but what it looks exactly like. Every other color inside the [0..1] range per channel can thus be defined, too. Some popular color spaces are sRGB and AdobeRGB in the RGB world. The CMYK world has things like "ISO Coated v2". Of course there is more than just one color space and most have different primaries. The colors that can be described with a given set of primaries is called the "gamut" of a color space – not to be confused with the color space's "gamma"! We will ignore the latter. Now that we know that the same triplet of numbers does mean something different in different color spaces we also understand that the numbers alone are meaningless without a color space. Since there is a terribly large number of images – both raster and vector – without any color profile information attached there is the common default of assuming sRGB. When looking at articles about color spaces there are almost always images of a horse shoe formed colorful diagram with a triangle on top (like https://commons.wikimedia.org/wiki/File:CIE1931xy_gamut_comparison.svg). The background horse shoe represents all possible colors a typical human can see while the corners of the triangle are just the aforementioned primaries. The area of the triangle covers the colors that the colorspace can display*. With the AdobeRGB triangle being bigger than the sRGB one (and completely covering it) we can easily see that AdobeRGB contains colors that are not expressible in sRGB. Besides these well known and standardized color spaces used to define colors in images there are also device color spaces that describe what colors some physical appliance can display. For now we will concentrate on monitor profiles since they are also RGB but of course also printers with four or even more colors can be measured and their primaries be determined. See the SWOP CMYK gamut in the sample image for a typical result of that. Back in the days of CRTs there was that prototypical monitor that exactly covered the sRGB color space – it's where it originated from. Nowadays with LCD displays and all that diverging technologies there isn't one typical display profile any longer. It turns out that most laptops and consumer grade displays cover less than sRGB while some high end monitors reach AdobeRGB or even wider gamuts. Therefore it's important to have proper color management in place so that the (1, 0, 0) you put into an image looks the same everywhere and not like an orange on some screens and a fire truck on another. Current state of Inkscape I have to admit that it's a while since I looked at the relevant code so my memory might be missing some details, but I am quite sure that the general picture I'm going to paint is in the right ballpark. When Inkscape displays "normal" colors they are untagged, 8 bit values. So it's just something of the form (255, 0, 255) for a nice magenta. According to the SVG specs (http://www.w3.org/TR/SVG/color.html) this is implicitly assumed to be sRGB. Using the CMS mode of the Fill&Stroke dialog the user can also specify the color space to be something else, for example AdobeRGB. While the value set in that mode gets propagated to the SVG as-is and be tagged with its color space, internally it will be converted to sRGB. When the user also specified a display profile the result of the renderer will in the end be transformed from sRGB (that's what all the colors Inkscape works with are) to the display profile. Problems While in theory this seems to be a sound way to deal with colors – transforming everything to sRGB as the internal working space – it poses a few problems in practice. First and foremost there is the usage of 8 bit values. It doesn't allow very fine steps between tonalities. And the bigger the color space's gamut gets the worse it becomes. That is especially true when doing blending in linear space and not gamma corrected (never mind that detail, it's not the important part here). Just look at the diagram again. The same number of steps (255 in case of 8 bit values) have to stretch a wider range of real world colors, so every intermediate step gets bigger. Another problem with 8 bit colors is that there is nothing below 0 and nothing above 255. At first that might not look like a problem, after all, (255, 0, 0) is the reddest red. There is nothing more red, so why think about numbers that are bigger? Well, because as we have seen earlier, it's only the reddest red in its own color space. When looked at it in any bigger color space it's just an average red, there are redder reds. Therefore the transformation of colors into sRGB will leave wrong results when anything that is not inside the sRGB gamut is being transformed to it and at the same time clipped to the 8 bit range. The result can't be mapped back to the original color any longer. Even when the display is able to cover all the AdobeRGB colors and the user specifies the colors in that color space the displayed results will map everything outside of the sRGB gamut to its inside (there are several way to do that clamping, you can just cut the values off, scale them nicely, ... but at the end of the day they are not what they used to be). To show the results of this clamping have a look at https://launchpadlibrarian.net/206984719/canvas_cms.png. Every row contains the same color value (shown on the left) four times, just tagged with different color spaces. So the first row should show the reddest red in AdobeRGB, sRGB and Laptop (some color space SMALLER than sRGB). We will ignore the GRB column, it's just there to show that color management was actually turned on. We notice that the first two columns look the same though. The reason is the clamping Inkscape does. The reddest red of AdobeRGB (i.e., its red primary) is far outside of sRGB's gamut. So Inkscape clamps the color and moves it to the closest sRGB contains: the reddest red sRGB knows. The same happens for green and blue. Once that happened every further step won't distinguish between the colors that once were very different and no matter what display profile is set the result will look the same. Because it is. Now for the third column. The Laptop profile has a smaller gamut than sRGB so when converting its primaries to sRGB they can be represented in the 8 bit range and are shown correctly in the resulting image. A better world All of this isn't that great for anything that is supposed to have correct colors and not be limited to sRGB. That might be less of a concern for Web graphics, but once you think about printing (most CMYK profiles are not inside the sRGB gamut) or even just seeing your work on a good monitor you have a problem. The first step would be to get rid of the 8 bit limitation. Not only would that allow for smoother gradients (remember that step size? With float they become virtually arbitrarily small!) but floats also allow to transform colors to a smaller gamut without clipping them since the values can be bigger than 1.0. Of course, all color math has to be checked if it would still work with values bigger than "full power" and there are cases where it will fail. Thus as a second step it would be helpful to either replace sRGB with something bigger for the internal working space (not exactly what the SVG specs allow :-() or maybe even keep all colors in their original color space and only do transformations where needed. Since there are even problems when doing some computations in a gamut that can express all colors but isn't the original one it might even be a good idea to let the user specify a color space of the whole document so that all colors that are not tagged are treated as that color space instead of sRGB, i.e., specify the working space (again, not what the SVG specs call for). For documents not mixing colors of different color spaces that might be the best solution – just take all colors as-is, handle them like Inkscape already does (with the exception that it should really really do it in float and not 8 bit) and in the end convert from the document working space to the display color space. * Actually this is just the colors with maximum saturation, the set of all colors isn't a triangle but skewed box in 3D space. In order to compare color spaces it's enough to look at this projection though. Thanks for reading Tobias

6 9

Website Downtime
by Martin Owens 09 Oct '15

09 Oct '15

Dear all, The inkscape website was down because of a DDos attack against one of OSUOSL's vlans. From: 2015-10-08 12:32 -0700 To: 2015-10-08 13:56 -0700 Hosting mailing list: "The outage is now over. A particular IP on this block experienced a DDOS. Since it has received several in the last few weeks, we're looking at moving it over to a different vlan that is better equipped to deal with these issues." >From their support: "As communicated via our hosting mailing list, this ddos has subsided. We are pursuing a strategy with our ISP to isolate the target to its own vlan, so we can apply stronger filtering rules, as well as contain the side-effects of exceeding transit limits." Su_v has a list of downloads for anyone who needs to download during a downtime period again. IRC should be used to find out more information if the website is down. Best Regards, Martin Owens Website Administrator

1 0

Hackfest 2016
by Tavmjong Bah 07 Oct '15

07 Oct '15

Hi all, At the Inkscape board meeting on IRC last week we started to think about our next Hackfest. While not absolutely necessary, it might be useful to couple it with a conference as we did last year with LGM. LGM will be in London this year[1] (April 15-18) and that is certainly a possibility but we also would like to look at other conferences. Does anybody have suggestions for other conferences that would be appealing to Inkscapers? Other conferences mentioned include FOSDEM[2], SCALE[3] and OSBridge[4]. Has anybody been to these conferences? Thanks, Tav [1] http://libregraphicsmeeting.org/2016/ [2] https://fosdem.org/2016/ [3] https://www.socallinuxexpo.org/scale/14x [4] http://opensourcebridge.org/

5 5

Another font issue: Calluna Regular
by C R 05 Oct '15

05 Oct '15

Calluna Regular, which is currently in use on the website is a commercial font. While it's true that the regular version is offered under a free license, it is not offered under an OFL license, and what's a bit worse, is not licensed at all for use in documents, etc. (only desktop/web, and some sites want to sell a web license for it, which is worrying). So... heh. Anyone want me to work on finding alternatives for that one too? We pretty much need to. -C

7 13

Technical IRC Meeting
by Josh Andler 05 Oct '15

05 Oct '15

Hey All, During the board meeting today it was evident that we need to schedule a technical meeting to discuss development issues (likely both Inkscape code and Inkscape website related). It looks the week of the 18th-24th is where we should be aiming to calendar something as 1 of the people who would like to participate has school conflicts between now and then. Does the noon Pacific time slot work again like it did for the board meeting? If so, what days are people available that they're aware of in that timeframe? I'm pretty open right now, so we can leave it to others to eliminate days based on availability. Cheers, Josh

3 2