August 2017 - Inkscape Devel - Inkscape Mailman

Download page inkscape, please sort by system
by the Adib 19 Aug '17

19 Aug '17

Hello web team, I wanted to update my system and was a bit confused which download to use. I propose to group alphabetically or by system instead of upload time. HTH, Adib. --

7 22

Measure line LPE improvemets
by Jabier Arraiza 19 Aug '17

19 Aug '17

Hi all. Following a CR conversation about "Measure Line LPE" and the unmanegable/slow to add a LPE for each segment. I do a mayor update to it. ALso rename it to "Measure Segments LPE" The previous LPE is not abailable now, so convert to paths previous works with it before update to trunk, sorry. Features: When apply to a path (can have subpaths) the full path is meassured. You can remove or add a partial segment measure by a blaclist/whitelist implemented. Before you can add another LPE to fill the removed segments with diferent params measuraments. By this way i do also a method to not cross measures with angle greater than "Fix Crossings º" parameter. I hope now is much more easy to use. Best regards, Jabier.

2 2

CMS on Windows, and a few more thing...
by Miguel Lopez 17 Aug '17

17 Aug '17

It doesn't seem to work, or I'm not sure how to get it right, but I'm sure you put .icc profile under new folder in Inkscape directory under share/color/icc, and Inkscape should be able to detect them, but from my end, it does not seem to work. Also, would it be possible to hide tabs in the color sections, and force Inkscape to stick with CMS? Is there some limitations to CMS that I'm not aware of? Does filters offset color informations? This is one feature I have never saw the use until recently. Thanks, Miguel Lopez

1 0

Inkscape Vectors Meeting - This Friday!
by Ryan Gorley 17 Aug '17

17 Aug '17

This month Vectors meeting will be hosting our first official meeting (see agenda <https://gitlab.com/inkscape/inkscape-vectors/admin/issues/1>)! There's a lot of need for diverse talents so please join us: * Friday, August 18, 18:00 GMT (14:00 EST) * https://teams.freecreatives.org/inkscape We look forward to meeting you and getting your input. :) Ryan @ Dijt <https://dijt.co>

1 0

What the hell happened to the git repo ?!?!?
by Felipe Sanches 16 Aug '17

16 Aug '17

https://gitlab.com/inkscape/inkscape

4 5

Fw: Version 0.92.2 seems infected by malware
by brynn 15 Aug '17

15 Aug '17

I received this below through Inkscape Community contact form (another person who could not figure out how to contact the website). I'll inform the sender of your reply (replies). All best, brynn -----Original Message----- From: johan_frederik@...1523... Sent: Tuesday, August 15, 2017 5:26 AM To: admin@...3472... Subject: Version 0.92.2 seems infected by malware Contact Page Form for Inkscape Community Name: Fred Schouten Email: johan_frederik@...1523... IP: 82.95.66.107 Message: Downloading en subsequently testing the download shows that libicudt58.dll is infected with malware. At least 10 engines at TotalVirus find a positive at the moment of testing (aug 15 2017). This is not the case with version 0.92.1.

2 2

inkscape root dir tidying thoughts
by Bryce Harrington 15 Aug '17

15 Aug '17

With the cmake and git conversions complete, and autotools and bzr bits removed, I am wondering if there's some additional cleanup of stuff accumulated in our repository's root directory. But much of this I'm not 100% sure about (and that maybe why others haven't already dealt with it). ------------------------------------------------------------------------ + distro + libgc.supp + tools-version.sh I think these may be obsolete. They've been in the codebase forever, but I don't know what they are used for anymore. I'm guessing they're autotools leftovers; can we drop them? ------------------------------------------------------------------------ + inkscape.ico + inkscape.png The share/icons/application/ directory is the formal place for our icons, with share/branding/ the official source for branding files. Only the windows packaging refers to inkscape.ico. So I think this could be moved to packaging/. Or perhaps windows could be changed to use the .png files like everything else? Doxyfile seems to reference inkscape.png but I believe it could as easily use one of the icons in share/icons/application/, but see below... ------------------------------------------------------------------------ + Doxyfile This doxygen config file works fine (just ran it). However according to http://wiki.inkscape.org/wiki/index.php/Doxygen_documentation we aren't posting doxygen pages online any more. In any case, doxygen lets you pass the config file name on its command line, so no reason this has to live in the root directory. Unless anyone has strong feelings otherwise I propose moving this file to doc/ with our other code/architecture docs. Or... other ideas? ------------------------------------------------------------------------ + inkscape.spec.in This is an old RPM build file I made way way back. I'm sure Fedora has something better, and besides this is _completely_ out of date. I will be deleting it. ------------------------------------------------------------------------ + inkscape.desktop.in + inkscape.desktop.template Is inkscape.desktop.in generated from inkscape.desktop.template? Do we need both files? ------------------------------------------------------------------------ + mingwenv.bat + mingwenv.cmake + msys2checkdeps.py + msys2installdeps.sh + msysenv.sh + inkscape.appdata.xml.in + Info.plist.in + appveyor.sh + appveyor.yml + .gitlab-ci.yml + .snapcraft.yaml + packaging/ I know a lot of tools expect config files in the project's root directory, but can any of these be moved to packaging/? (Or maybe a utils/ dir?) Several of these have description snippets that are essentially the first few paragraphs of the README. If the README is revised (see below), it may be worthwhile to resync the text in these from that. ------------------------------------------------------------------------ + download-gtest.sh This still seems necessary for setting up gtest (although current trunk breaks on configure due to lack of a "Findgtest.cmake"; but that seems unrelated). Having to use this script has always seemed a bit hacky to me. (and it's downloading gtest 1.7, but 1.8 is current). I know there's been some good work done on improving our testing cmake rules, I wonder if there is a way we can eliminate this script? ------------------------------------------------------------------------ + testfiles/ Speaking of tests... Is there a reason why we call this directory testfiles/ rather than a more traditional name like 'test/' or 'tests/'? ------------------------------------------------------------------------ + INSTALL The installation directions here are for autotools so the whole file is obsolete. I only hesistate to delete it because I believe `make distcheck` requires it. So question here is should we move the installation directions currently in the README.md file to INSTALL? ------------------------------------------------------------------------ + README.md + README.ca.txt + README.de.txt + README.es.txt + README.fr.txt + README.it.txt + README.pt_BR.txt + README.sk.txt + README.sr.txt Speaking of the README, we've had these translations of the README for a long, long time. Most have not been updated to reflect the autotools -> cmake move, some haven't been updated in a decade. None have followed the main README's reformatting to markdown. But I wonder if translations of the README are that necessary? If not, would anyone be troubled if we dropped them at this point? Aside from the installation directions (which are out of date anyway, and maybe should move to INSTALL), the information in the README is just introductory stuff that exists in translated form on our website and elsewhere so The first section of the README we have used far and wide all over the place. It's a stock text we cut and paste into anything that needs a description of our project. But it's been pointed out to me that this doesn't really reflect the current state of Inkscape and all the stuff that's been achieved since it was written. So, we may want to consider revising this. Does anyone know of a more current description of Inkscape that we could leverage for this? ------------------------------------------------------------------------ + inkscape.pod + inkscape.de.pod + inkscape.el.pod + inkscape.fr.pod + inkscape.ja.pod + inkscape.sk.pod + inkscape.zh_TW.pod + inkview.1.in + man/ Unlike the README's, the translated man pages have been getting updates. The --no-convert-text-baseline-spacing option is only documented in the English inkscape.pod, but the previously added option, --export-ps-level, (from 2013) is present in all. However, these should move down into the man directory. The CMake code is already in CMakeLists.txt to generate the .pod files from the man/ directory, so recent changes to the root *.pod's just need to be sync'd with the corresponding files in man/ and then removed. As an aside, I know we eliminated Perl from the build system, but it's still used for the man page generation (the 'p' in pod stands for perl). I like the POD format, but raw man page syntax (TROFF) isn't *that* complicated; if we wanted, we could just keep all the man pages as troff, eliminate pod usage, and simplify our build requirements. (Compare inkview.1.in with man/inkview.pod.in to see the difference). Would anyone be opposed (or favorable) to this change? ------------------------------------------------------------------------ + fix-roff-punct + utf8-to-roff These perl scripts were used to fix up punctuation goofs by pod2man. If we moved away from POD, then these are entirely superfluous and can be dropped. -------------- + COPYING + GPL2.txt + GPL3.txt + LGPL2.1.txt Next, licenses... As detailed in the COPYING file, the only reason we have GPL3.txt is because there's a few files in our tree copied from GIMP. Could someone please take the task of eliminating those files, so Inkscape can return to being pure GPL2? The LGPL2.1 isn't a problem, but according to COPYING it's only there due to some libs we copied into the tree (I see libavoid is LGPL, is there anything else?) If the LGPL libs were changed to be external dependencies instead of copied into src, we could eliminate the LGPL2.1.txt file too. ------------------------------------------------------------------------ + CMakeLists.txt + CMakeScripts/ + cmake_uninstall.cmake.in + config.h.cmake CMake is nice and concise compared to autotools. I do wonder if cmake_uninstall.cmake.in could perhaps be moved into CMakeScripts/. If anyone else wants to move it, please do, else I'll look into it some time. ------------------------------------------------------------------------ + astylerc This config file appears to be for a code formatting tool. I vaguely remember kk discussing it a while back. Is anyone still using it? The astyle man page indicates it supports using --options=FILENAME to specify a path to astylerc, so the file could be moved to utils/ or elsewhere. I see we already have the options documented at https://inkscape.org/en/develop/coding-style/ including directions for how to store the settings locally in ~/.astylerc. If no one is actively using this tool, that might be a better solution and remove astylerc from the codebase. ------------------------------------------------------------------------ + _clang-format I'm not sure why this is in the tree. Guessing it was a jenkins-related thing? I suspect we can drop this. ------------------------------------------------------------------------ + setup/ This appears to be current, but what is it? It has a single subdir with a single file, which looks like a copy of inkscape.desktop.in with translations embedded. Why is this in a directory called 'setup'? ------------------------------------------------------------------------ + ChangeLog With the newest entry in this file being from 2014, this looks vestigal. I think it used to be needed for packaging, and I think it dates to pre-bzr. Anyone know if there's a reason to keep it? ------------------------------------------------------------------------ + AUTHORS + TRANSLATORS + NEWS + doc/ + share/ + src/ + po/ This is all pretty stock, no comment here. Bryce P.S. if you've read to this far, thanks! This ended up way longer than I anticipated, sorry!

13 35

Correct download URL for source ?
by Ken Moffat 13 Aug '17

13 Aug '17

When I downloaded 0.92.2 using firefox, I thought that the link was to https://inkscape.org/en/release/0.92.2/source/archive/dl/bz2/ (but I might have misread the tiny text), and presumably it had inkscape-0.92.2.tar.bz2 on the end of it. But now that I try to go there directly I get inkscape's Page Not Found, and using that to search for inkscape-0.92.2.tar.bz2 fails. I see that Arch seem to be using https://media.inkscape.org/dl/resources/file/inkscape-0.92.2.tar.bz2 but that too fails for me with 404, or 403 for the directories above that. So, please, where should I point people to so that they can download it with a browser or wget ? ĸen -- I live in a city. I know sparrows from starlings. After that everything is a duck as far as I'm concerned. -- Monstrous Regiment

2 2

Rerun Cakke
by Jabier Arraiza 12 Aug '17

12 Aug '17

Hi all. Please I just push a minor improvement and if you have compiling isues with a icon, please re-run cmake. (not need to remove cache cmake file). Sorry for the inconveniences, Jabier.

1 0

Icon names
by Alex Valavanis 12 Aug '17

12 Aug '17

Hi Tav, Is there any chance you could use your icon-extracting Perl script to generate a list of Inkscape's icon-name strings? It would be good to put a table of names/descriptions on the Wiki to help people develop custom icon themes. AV

2 1