- Inkscape Devel - Inkscape Mailman

Wiki account
by Brad Pitcher 26 May '15

26 May '15

Can I have an account for the wiki please? I have an extension I'd like to add to the list.

2 1

Inkscape trunk PPA - 'Dependency wait' since May 21 (no new builds)
by su_v 26 May '15

26 May '15

1) Last successful PPA build and upload was rev 14163 on May 20; since then every new build has failed with 'Dependency wait': * Missing build dependencies: libgtkspell-3-dev > The following packages have unmet dependencies: > sbuild-build-depends-inkscape-trunk-dummy : Depends: libgtkspell-3-dev but it is not installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. > Package installation failed Anyone familiar with the build recipe able to fix this dependency issue? 2) GTK3 builds are currently broken (likely unnoticed due to above build failures) - AFAICT the refactored PDF import dialog (r14170-14172) does not compile with GTK3: Build log (first 20 errors) with Gtk+ 3.16.3: https://gist.github.com/su-v/ba21869dc538149dff16

2 1

Scribus 1.5.0 released
by "Christoph Schäfer" 26 May '15

26 May '15

After many years of work and more than a thousand bugfixes and feature implementations, the Scribus Team is pleased to announce the release of Scribus 1.5.0. Scribus 1.5.0 is a preview of the next stable version 1.6.0 and has primarily been released for testing purposes, so more users can help us with identifying and fixing bugs. It is not stable enough for use in real production scenarios yet, but it can help users to become familiar with the new interface and the amount of new features, the number of which has almost doubled in comparison to the stable 1.4.x series. ==Most Important Technical Changes== - Scribus 1.5.0 uses Qt 5 as its UI toolkit. The minimum version to compile Scribus from source is Qt 5.4. - The file format has undergone significant changes and may change even further before the release of 1.6.0. Thus, files created or edited in 1.5.0 cannot be opened in earlier versions of Scribus. Potential changes to the file format on the road to 1.6.0 notwithstanding, the Scribus Team will work very hard to make sure that files created by 1.5.0 and the following technology previews can be opened reliably in the next stable release. - Unfortunately we cannot offer GraphicsMagick and Open Scene Graph support for all platforms yet, whereas on Linux (and probably *BSD), GM and and OSG have become new dependencies. - Scribus will detect an installed version of UniConvertor and use it to import some of the vector formats supported by this program into Scribus. ==Most Important New Features== ===General=== -The user interface has been overhauled and restructured in many places. For example, the context menu takes a lot less screen estate than before, and the Document Setup / Preferences dialog has been rewritten from scratch. The Scribus Team is aware of the remaining deficiencies and will work on resolving these issues before the release of 1.6.0. In some cases inconsistencies in the UI (e.g. the "Drop Shadow" tab in the Properties Palette) have been deliberately left in place to receive feedback from users as to which way they prefer. - Scribus can now store bitmap images within its native file format. Previously it was only possible to link to external images. - Scribus 1.5.0 now offers a "Symbol" or clone feature similar to Adobe Illustrator: If one master object (Symbol) has been modified, all of its copies (clones) are being modified as well. - With the new "Weld" feature, objects can be combined and moved without being "grouped", i.e., each object remains fully editable. ===Text / Typography=== Scribus 1.5.0 provides some of the most often requested text features, among them: - vertical scaling of text; - orphans and widows control; - foot and end notes; - text variables; - cross references. Moreover, Inline Objects in text frames are finally fully editable. ===Tables== In previous Scribus versions tables were nothing more than combined text frames. Scribus 1.5.0 finally introduces "real" tables that resemble table features in word processors and other DTP programs, including table styles. ===Graphics=== - A new feature-rich plug-in called 'Picture Browser' enables asset management for graphics files by tagging them or creating graphics collections. Graphics files can be dragged into a Scribus document from the Picture Browser. - Scribus 1.5.0 supports all advanced gradient types available in Adobe Illustrator and XARA Designer, including mesh gradients. - One of the most-requested features -- drop shadows -- is finally available, albeit still experimental. - For documents that comprise many large (in terms of file size) bitmap images, a configurable image cache has been added. It can buffer image files to the hard drive and free RAM, so Scribus can continue to run smoothly. ===File Import / Export=== Scribus 1.5.0 is being shipped with a huge number of new or rewritten import filters, although not all of them are of equal quality, and some are still experimental. ====DTP Files==== For the first time in its history, Scribus 1.5.0 can open / import files created by other DTP programs, namely: Adobe InDesign XML (IDML), Adobe InDesign Snippets (IDMS), Adobe PageMaker (P65, PMD), Apple iWorks PAGES, Microsoft Publisher (PUB), QuarkXPress Tags (XTG), VIVA Designer XML, and Xara Page & Layout Designer (XAR). Regarding DTP formats not yet supported, a workaround is sometimes to use an output format as an option. Accordingly, Scribus 1.5.0's PDF importer has been rewritten from scratch, and Scribus can now reliably open almost every PDF file directly with the original layout intact. For Windows users, Scribus 1.5.0 also comes with reliable import filters for Microsoft's PDF alternatives XPS (Windows Vista and 7) and OXPS (Windows 8 and later). ====Vector Drawings==== - The import filter for Adobe Illustrator files has been rewritten from scratch and Scribus's graphics capabilities have been expanded accordingly, so most AI files can be imported or opened flawlessly. Moreover, Scribus can now detect hybrid AI files and enables users to choose between the AI and the PDF version. - The import filter for OpenDocument graphics files has been rewritten from scratch and expanded, so Scribus can now open and import ODG drawings and ODP slide shows without issue. - "Layers" in SVG files are now supported if an SVG document is being opened (as opposed to being imported into an existing document). - Thanks to the libraries provided by the Document Liberation Project, Scribus can now import native MS Visio and CorelDraw files. - Other new import filters: Computer Graphics Metafile (CGM), Photoshop Custom Shapes (CSH), Micrografx Draw (DRW), Enhanced Metafile (EMF), StarView Metafile (SVM), WordPerfect Graphics (WPG), Xara Designer (XAR). ====Bitmap Files=== - Scribus 1.5.0 supports the open standard Open Raster (ORA) for complex bitmap files, including advanced features like layer effects or paths. - With GraphicsMagick installed, Scribus can import all bitmap files supported by this program, including GIMP's native XCF format. - Scribus 1.5.0 can import PGF bitmaps, an open alternative to JPEG 2000. ====3D==== With OpenSceneGraph installed, Scribus 1.5.0 can import 3D objects in all formats supported by OSG into a new frame type called "3D Annotation". Scribus also offers limited editing functions, such as setting the lighting source or the default display mode for a PDF-3D-capable PDF viewer. ====Colors and Fills==== Scribus 1.5.0 can use color palettes in the Adobe Color Swatch (ACO) and AutoCAD ColorBook (ACB) formats, as well as GIMP Gradients (GGR) and GIMP Patterns (PAT). The former color manager has been extended to a "colors and fills manager" to reflect Scribus's new capabilities. ===Output=== The most important new feature with respect to output is the support of PDF/X-4 in the PDF exporter. Another important addition, at least in some environments, is an exporter for Microsoft's XPS format. For a cursory overview of all new features, see: http://wiki.scribus.net/canvas/Scribus_1.5_Readme A data sheet is available here: http://wiki.scribus.net/canvas/File:Data_sheet-Scribus150.pdf (English) http://wiki.scribus.net/canvas/File:Datenblatt-Scribus150.pdf (Deutsch) The complete changelog is available here: http://bugs.scribus.net/changelog_page.php?version_id=60 ==New Website== Thanks to Carsten Liersch and Dennis Groenewegen van der Weijden, we're also pleased to present Scribus via a new and modern website to the world. ==Primary Download Locations== - Installation packages for Windows, Mac OS X and the source code are available here: http://sourceforge.net/projects/scribus/files/scribus-devel/1.5.0/ - Fedora and CentOS RPMs: http://download.opensuse.org/repositories/home:/mrdocs - OpenSUSE, SLED, and SLES RPMs: http://download.opensuse.org/repositories/home:/mrdocs - Packaging for *BSD, Solaris and OpenIndiana is beyond our influence. We recommend updating the respective repository data on a regular basis. ==Download Verification== Description File Name Sha1sum Source scribus-1.5.0.7z 7a8dbe7ae7790ecc194dbe9c6c23726bb3b226d7 Source scribus-1.5.0.tar.xz fdf451037073ee648f135669535508813d61ee7e OS X Mavericks or higher (DMG) scribus-1.5.0.dmg 55a1e0800b73f7b7b0b136b3ebc1eb6a03ef0b07 Windows 32/64 Bit scribus-1.5.0-windows.exe 9a0ce39350e77d6a907f8aae2b6d803ba6345ef7 Windows 64 Bit scribus-1.5.0-windows-x64.exe 42d489fe1098797772a14113ca2ac49244a4dbd2 ==Credits== The Scribus Team would like to thank Anduin.net and Modirum for their continued hosting of all of the Scribus websites. We are grateful to the Organisation Internationale de la Francophonie and Linux New Media (Germany) for sponsoring. Special thanks go to Carsten Liersch/Bauwerk Design (Germany) and Dennis Groenewegen van der Weijden for the design of the new Scribus website. The Scribus Team is also honored to have Resene Colours (New Zealand), dtp studio oldenburg (Germany), GiveLife Color System (Spain), Scientific Illustration Services Corp. (USA), the Newspaper Association of America (USA) and Software Consulting Services (USA) as Special Supporters and donors of color palettes and other content since the 1.4.x release, just like we are grateful to the owner of Vector Portal for the permission to distribute some of his work as Scribus Templates. Porting Scribus to OS/2 and eComStation is being supported by Mensys BV (The Netherlands) and Serenity Systems (USA). Finally, the Scribus Team would like to thank the many end users, translators, testers and contributors who helped us with this release.

3 2

RFC: Switch to Google Test framework
by Bryce Harrington 24 May '15

24 May '15

Hi all, At the hackfest today we discussed the Boost test suite vs. the Google test suite. Both options are very good and better than cxxtest that we use currently, and should be straightforward to move to. We tentatively decided on Google test. 2geom uses it, so many of us already have familiarity with it, and it will keep the two projects consistent. Boost's commands have prefixes which makes for a bit more typing, whereas Google test's are more brief. KK liked Google test's handling of templates better too. Does anyone have a strong differing option? We're hoping to have the decision finalized by the end of the week. Bryce

8 21

New LPE Transform by two nodes-knots-
by Jabiertxo Arraiza Cenoz 24 May '15

24 May '15

Hi to all. Here are a video with my last LPE. https://www.youtube.com/watch?v=ZLmYdWoXXIw Its based in a feature pointed by Ivan Louette. Here the branch to review: https://code.launchpad.net/~inkscape.dev/inkscape/transform_by_two_points Best regards, Jabier.

3 5

Description of Livarot's boolops algorithm?
by Krzysztof Kosiński 24 May '15

24 May '15

Hello Can anyone provide a rough description of how livarot's boolops work? In my thesis, I want to compare it to my new implementation in 2Geom. The new implementation is almost complete, and handles all general cases on any combination of lines, Beziers and elliptical arcs. The only remaining thing is the handling of overlapping segments. Regards, Krzysztof

1 0

Web IRC client - support troubles
by Bryce Harrington 24 May '15

24 May '15

It's come to my attention that our website IRC client, which provides a convenient means for users to ask a quick question, is causing a lot of frustration amongst our volunteers on the channel who are trying to provide support and manage the channel. There's three issues that I'm aware of: * Drive by's: Very often people will log in, shoot off a question that is easily answered, then depart before anyone has a chance to answer it. * Language: Often people will express questions in their native language. As our current support volunteers only include English speakers, this just isn't going to work out. * Anonyminity: The nice thing about the IRC client is since it doesn't require login credentials, it's quick and easy to use. The downside is we have no idea who the person is. This means no way to contact them out of band (e.g. shoot them an email with the answer to their question, or post it to their inkscape.org account), and no way to ban people who behave abusively (the channel op can kill the session, but the troll could just re-login.) There may well be other issues, but I think this is representative. Compounding the problem, I think the IRC support crew feel a bit disempowered: The web irc client is part of the website and thus maintained by the website maintainers. The easiest solution would be to switch off the irc client on the website, or for the IRC support staff to set /ignore (or worse) on "inkscaper*". But these don't really *solve* the problems, they just brush them under the rug. Are there other changes (maybe minor tweaks, maybe major re-thinks) that would address these problems while still helping users get answers to their questions, quickly and/or interactively? Bryce

9 15

Fwd: Website Feedback
by Martin Owens 19 May '15

19 May '15

Forwarding on a request from intel: ---------- Forwarded message ---------- From: Catalin Crisan <catalinx.crisan@...1100...> Date: 19 May 2015 at 07:39 Subject: Website Feedback To: Martin Owens <doctormo@...400...> Hello Inkscape team, My name is Catalin and I work within the Software & Services Group (SSG) at Intel, supporting successful application developers and publishers in different levels and would like to speak about a possible cooperation. I have just tested Inkscape and I think it's a wonderful app. So, congratulations for the great work! Seeing the good reviews and potential that “Inkscape” has, I wonder if you would be interested in working with us on optimizing the app for 2in1 Ultrabooks (PCs that transition from clamshell/laptop mode to tablet/touch mode). The idea is to have two slightly different UIs that adapt to the both usages, taking advantage of the hardware’s capabilities and offering a great experience in both cases. We mainly offer hardware, technical support and different co-marketing opportunities, but I would like to go further into details. Looking forward to hearing from you! Have great day! Catalin Crisan ISV Enabling Manager Skype: catalinc-intel Tel +44 01844340399 catalinx.crisan@...1100...

4 4

PUBLISHER article on 0.91 available
by "Christoph Schäfer" 18 May '15

18 May '15

Hi, The article on Inkscape 0.91 is finally available in print and online: http://publisher.ch/dynpg/upload/imgfile6767.pdf Enjoy (or be upset). Christoph

3 4

Do geometric contructions tool / general Inkscape UX discussions
by Ryan Lerch 18 May '15

18 May '15

HI all, I just noticed the new "Do Geometric constructions" tool in the inkscape trunk, and this got me thinking a few things about this new tool (and inkscape usability and UX in general). First up, this tool provides (among other things) two new ways to create a circle: "a circle by three points", and a "circle by center and radius". These are pretty neat additions, but my first question when I saw this was why is this in a completely separate tool, not as a sub-tool of the circle tool. I understand these are implemented as LPEs, but from a user point of view, if you want to create a circle, wouldn't you expect these options in the circle tool? If they were in the circle tool, there might even be the option to create a circle with the traditional mode of the circle tool, then fine-tune it with one of the other two "editing" modes, rather than it appear to the user to be three completely separate object types that can't be converted back and forth. Something similar is also in play with the (present in 0.91 "shape" option of the pen tool) the "shape" option only works when creating a new line with the pen tool, while other tools (such as the star/polygon tool) allow changes in the tools control bar to impact the currently selected object. I know this is kind of out of the blue, but i have been thinking a lot lately about some of the inconsistencies like this in the inkscape interface, and would love to try to help contribute to fixes / be involved with helping with the usability of new tools we create. Has there ever been anyone involved with doing usablity reviews / testing of this sort? (doctormon, i know you did some last year :) ) I know of plenty of UX people that use Inkscape that would probably be keen in contributing in this area. cheers, ryanlerch

7 9

External funded development site
by Maren Hachmann 15 May '15

15 May '15

Hi everyone, yesterday, I stumbled about this (following a link from the elementaryOS website): https://www.bountysource.com/trackers/459306-inkscape Seems they do 'funded development' for Inkscape (and everyone else...) without us even knowing about it (or maybe someone does?). They pull the data from launchpad. They say they collect money for bug bounties, and reward that to the dev who closes the bug, with a 10% deduction if the dev asks for transfer of the money to his/her bank account/paypal account/etc. I don't know how (if?) they inform a developer about the bounty, when the project doesn't even have a representative registered on their website. To me, it sounded as if the developer must actively ask them to pay out the reward (please read their TOS/FAQ, I'm not a native speaker). They also allow projects to setup donation campaigns. Currently, there are no bounties for Inkscape on their site. Do we need to do anything about this? The options we have seem to be: - create an account and make sure that everything goes correctly, and use it actively - create an account and just keep an eye on it - ask them to not include Inkscape, or somehow make it clear that this is not endorsed by us (if it isn't) - officially decide that that thing can run in parallel with our own funded projects without problems and without us doing anything Regards, Maren

3 2

Re: [Inkscape-devel] Educating users on Free Software (was: C++-11...)
by Bryce Harrington 13 May '15

13 May '15

On Fri, May 01, 2015 at 07:06:03PM -0400, Martin Owens wrote: > But the Free Software activist side of me thinks it's a worthwhile > investment if we can introduce a way to educate users about their > platforms and why a Free Software platform would be better for future > buying decisions. Well said Martin, and I totally agree. This is something I've wanted to pick your brain on, if you're willing to share thoughts on the subject? One of the things that burnt me out on doing release management for Inkscape years back was the realization we were accumulating tons of users on non-free platforms, and the better we were executing on those platforms the less reason we were giving for them to switch. IOW it felt like our release process and development momentum was getting bogged down fixing Windows bugs to improve Inkscape on Windows, making it easier for Windows users to have the benefits of being on Linux without having to be on Linux. This time around, one of the main reasons I'm gung-ho on the funded development stuff is to establish a paid way to provide Windows support and tap the Windows userbase to fund the work, so it is less impact on developers that don't care about Windows, and doesn't hold up the release process so much. I'm also personally less driven to see people switch to Linux specifically, after all the in-fighting, open source politics, and monetization of communities that's happened over the past several years. But I do still believe strongly in the overall ideals of Free Software and encouraging community, collaboration, deliberation, and sharing around collective works in common. Jon had made a good suggestion of writing up some of the defining principles of Inkscape, such as the idea that we don't draw a line of distinction between user and developer, but consider it a sliding scale and try to invite all users to contribute even in small ways. There's probably a handful or two of other ideas along those lines that define our development community, which would be valuable to disseminate more broadly. Do you have more ideas on how we could do this? Bryce

10 50

URI acceptance and loops with respect to SVG spec [167247]
by Marc Jeanmougin 11 May '15

11 May '15

Hi all, I recently started to work on bug 167247 [1]. This bug is about circular references in svg [For now, i'm working with local references, not references to the "containing file" itself as described in first comment of the bug report] I narrowed it to the URIReference::_acceptObject method: some references are accepted, when they create loops (and should be rejected). The relevant part of the spec[2] states: ''' IRI references that directly or indirectly reference themselves are treated as invalid circular references. ''' which i translated like this: ''' Once we have an object, it can accept a href to another object, iff the graph of objects where directed edges are either parent->child relations , **or** href'ing to href'ed relations, stays acyclic. ''' This prevents us to have loops like (read this as a regexp) "/a use to a group( whose descendant is a use to a group)+ containing the original/", which was NOT prevented by the previous check who checked only for descendance, not linking loops.[5] This will also prevent such loops as "a clippath containing a rect which has(refers to) a clippath which contains a use to a rect which has the first clippath as clipping". (There were also crashes with patterns using themselves indirectly, masks, etc that will be solved with this method, or any crashes with any looping combination of hrefable elements) *But* (yes, there is always a but) that would also prevent behaviour like "a rect clipped by its clone" even when there is no "rendering loop" (understand this as "no segfault for now") which would have to be done with a LPE that keeps a copy of the rect in the clippath, not a <use>. [3] I don't know precisely if that is what is intended by "directly or indirectly references themselves", but i believe so. ( Also, I'm looking for a nicer way to get the "original" of a pseudo-element inside a <use> (those elements that have element->cloned == true) than what's in my patch[4] (which is : go up to the element that does not have ->cloned set to true, look at the path you've followed in the tree, getOriginal(), follow the same path in the reverse order, repeat while you're ->cloned) ) Thanks, -- Mc [1]https://bugs.launchpad.net/inkscape/+bug/167247 [2]http://www.w3.org/TR/SVG11/linking.html [3][rect hrefs to clippath which has child use which refers to rect => direct loop] [4]https://launchpadlibrarian.net/206054089/total2.diff [5]cf the failed struct-use-12-f w3c test file for the simplest example[6] [6]sorry the refs are not in the order of the mail, i don't write my emails in LaTeX, the numbering comes as i type :p

1 0

Re: [Inkscape-devel] Inkscape Devlibs (windows)
by Partha Bagchi 10 May '15

10 May '15

HI Adlib, I'll be building 32bit libraries with 4.9.2. I don't use TDM. Is that a problem? Thanks, Partha On Sun, May 10, 2015 at 12:04 PM, the Adib <theadib@...400...> wrote: > Hello Partha, Josh, > > still in our docs we state to compile win32 using gcc 4.6.1 > http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows. The > TDM GCC variant has now 4.9.2 for both win32 and win64. > > Can we also switch win32 to latest gcc 4.9 as in win64 development.? > > As this is a big step, possibly we need a tag in the devlibs bzr to easy > recover the current development environment once a hotfix is needed. And > then we can update the repository and Wiki to reflect the changes. > > Please let us know how you proceed .... > > Best regards, > > Adib. > -- > > On Sun, May 10, 2015 at 1:04 PM, Partha Bagchi <partha1b@...400...> wrote: >> >> No problems Josh. Please test 64bit for now and I'll update the 32bit >> libs as soon as I can. >> >> Thanks, >> Partha >> >> On Sun, May 10, 2015 at 1:06 AM, Josh Andler <scislac@...400...> wrote: >> > Hey Partha, >> > >> > I will try them out in a few days, as for 32bit libs they are probably >> > in >> > need of updating as well for the Cairo fixes. If you can do it, awesome. >> > If >> > you want me to test 64bit first, that is cool by me. If you have no >> > interest >> > in producing 32bit libs, just let me know. :-) >> > >> > Thanks for doing this! >> > >> > Cheers, >> > Josh >> > >> > On May 9, 2015 9:07 PM, "Partha Bagchi" <partha1b@...400...> wrote: >> >> >> >> Hey Josh, >> >> >> >> I compiled all the needed devlibs using gcc 4.9.2 for x86_64 Win64. I >> >> haven't had the time to do the 32bit yet. But I am guessing Inkscape >> >> already has 32bit libraries? >> >> >> >> Please download; >> >> http://www.partha.com/temp/Inkscape-devlibs-win64bit.7z >> >> >> >> Let me know if you have issues. >> >> >> >> Thanks, >> >> Partha >> >> >> >> >> >> On Fri, May 8, 2015 at 2:12 PM, Josh Andler <scislac@...400...> wrote: >> >> > Hey Partha, >> >> > >> >> > I just wanted to follow up to see if you had ended up creating the >> >> > devlibs and I possibly missed it. >> >> > >> >> > Cheers, >> >> > Josh >> >> > >> >> > On Thu, Mar 12, 2015 at 3:09 PM, Partha Bagchi <partha1b@...400...> >> >> > wrote: >> >> >> I have not heard of any issues with moving to SEH. So, if you are >> >> >> comfortable, I will provide you with SEH devlibs. >> >> >> >> >> >> If you want 32-bit, I'd be happy to provide those as well. >> >> >> >> >> >> On Thu, Mar 12, 2015 at 3:15 PM, the Adib <theadib@...400...> wrote: >> >> >>> Hello Partha, and all, >> >> >>> >> >> >>> Looking at >> >> >>> >> >> >>> >> >> >>> http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj… >> >> >>> I think that SEH should be preferred on win64. >> >> >>> >> >> >>> Is there any counterargument or testcase that blocks from >> >> >>> switching? >> >> >>> >> >> >>> Regarding the 32 bit devlibs. Our documentation how to generate the >> >> >>> devlibs >> >> >>> does seem to be reproducable. I struggelt on the way. I red about >> >> >>> msys2 >> >> >>> would that make building easier? >> >> >>> >> >> >>> Regards, >> >> >>> >> >> >>> Adib. >> >> >>> -- >> >> >>> >> >> >>> Am Donnerstag, 12. März 2015 schrieb Partha Bagchi : >> >> >>> >> >> >>>> Hopefully I will be able to update the 64-bit devlibs this >> >> >>>> weekend. >> >> >>>> >> >> >>>> My job would be easier if we didn't insist on sjlj as opposed to >> >> >>>> seh. >> >> >>>> :) >> >> >>>> >> >> >>>> On Tue, Mar 10, 2015 at 11:23 PM, Josh Andler <scislac@...400...> >> >> >>>> wrote: >> >> >>>> > Hey all, >> >> >>>> > >> >> >>>> > Now that Cairo 1.14.2 is out, can both the 32-bit and 64-bit >> >> >>>> > devlibs >> >> >>>> > get updated? I think we should aim to get 0.91.1 out in maybe a >> >> >>>> > month >> >> >>>> > or so. I will start looking into doing backports later this >> >> >>>> > week. I >> >> >>>> > figured I'd bring up the devlibs first though since they seem to >> >> >>>> > take >> >> >>>> > a bit to get updated. >> >> >>>> > >> >> >>>> > Cheers, >> >> >>>> > Josh >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > ------------------------------------------------------------------------------ >> >> >>>> > Dive into the World of Parallel Programming The Go Parallel >> >> >>>> > Website, >> >> >>>> > sponsored >> >> >>>> > by Intel and developed in partnership with Slashdot Media, is >> >> >>>> > your >> >> >>>> > hub >> >> >>>> > for all >> >> >>>> > things parallel software development, from weekly thought >> >> >>>> > leadership >> >> >>>> > blogs to >> >> >>>> > news, videos, case studies, tutorials and more. Take a look and >> >> >>>> > join the >> >> >>>> > conversation now. http://goparallel.sourceforge.net/ >> >> >>>> > _______________________________________________ >> >> >>>> > Inkscape-devel mailing list >> >> >>>> > Inkscape-devel(a)lists.sourceforge.net >> >> >>>> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> ------------------------------------------------------------------------------ >> >> >>>> Dive into the World of Parallel Programming The Go Parallel >> >> >>>> Website, >> >> >>>> sponsored >> >> >>>> by Intel and developed in partnership with Slashdot Media, is your >> >> >>>> hub for >> >> >>>> all >> >> >>>> things parallel software development, from weekly thought >> >> >>>> leadership >> >> >>>> blogs >> >> >>>> to >> >> >>>> news, videos, case studies, tutorials and more. Take a look and >> >> >>>> join >> >> >>>> the >> >> >>>> conversation now. http://goparallel.sourceforge.net/ >> >> >>>> _______________________________________________ >> >> >>>> Inkscape-devel mailing list >> >> >>>> Inkscape-devel(a)lists.sourceforge.net >> >> >>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >

2 2

PathInfo info+
by Jabiertxo Arraiza Cenoz 09 May '15

09 May '15

Class example files for pathinfo: http://bazaar.launchpad.net/~inkscape.dev/inkscape/pointwise/view/head:/src… http://bazaar.launchpad.net/~inkscape.dev/inkscape/pointwise/view/head:/src… all the best, Jabier.

1 0

2Geom sync status
by Krzysztof Kosiński 09 May '15

09 May '15

The 2Geom sync is almost done. So far I have identified two problem areas. 2Geom is now a lot more strict about what it considers a degenerate closing segment - it requires exact equality of endpoints, not just nearness to some arbitrary precision. This is of particular importance in paths where the last segment is curved. Because Inkscape loses precision when storing paths, bug #515237 now manifests on every closed path with a non-linear last segment. https://bugs.launchpad.net/inkscape/+bug/515237 I intend to fix this in the following way: first, modify SVGPathParser so that it knows whether the last segment before 'z' was relative, and if it is, snap it to the final node with a precision set by another function call, 1e-6 by default; second, by making Inkscape output paths with the double-conversion library now integrated in 2Geom and always using absolute coordinates, so that there is perfect roundtrip between XML and internal representation. This will mean the removal of the Output Precision setting and a moderate increase in file sizes. The proper place for such functionality is in a separate export filter. As a bonus, setting the document unit to metres will no longer cause a variety of issues. We discussed output precision briefly on the hackfest. Moving to full precision output with perfect roundtrip is the only correct solution and will enable us to avoid excessive recomputation of attributes in the SP tree, which is a performance win. If someone wants to get rid of extra precision - use an export filter. However, if anyone has a different opinion please speak up now. The second problem is the transformation of elliptical arcs, as seen when manipulating ellipses in the selector tool. In some cases, the large arc / sweep flags are incorrectly set for transformed arcs. I am still looking for the cause of this bug. The sync branch is at lp:~inkscape.dev/inkscape/lib2geom-sync - if anyone feels like looking for additional bugs, please do. I only did minimal testing on it. Regards, Krzysztof

4 12

non-Unicode symbol fonts do not work on Windows. Bug 165665. Do we need the flag USE_PANGO_WIN32 ?
by Alvin Penner 09 May '15

09 May '15

ref : https://bugs.launchpad.net/inkscape/+bug/165665 I believe this bug can be fixed by disabling the flag USE_PANGO_WIN32 in line 19 of src/libnrtype/FontFactory.h. When I do this on Windows XP, I gain about 35 new fonts. Not all of these new fonts are useable, but the most interesting ones, such as CommercialPi, Symbol, Technic, Webdings, Wingdings, MonoType Sorts, TechnicLite are working well, both in Inkscape and in IE9. This is a Windows-specific bug which hides symbol fonts, and does not occur in Gimp 2.6 on Win XP. As far as I can tell, the Gimp source code does not contain any analogue or equivalent of the flag USE_PANGO_WIN32. Would there be any objection if I disable this flag, or does it serve a specific purpose that is essential? tia - Alvin Penner -- View this message in context: http://old.nabble.com/non-Unicode-symbol-fonts-do-not-work-on-Windows.-Bug-… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

7 16

Units
by Jabiertxo Arraiza Cenoz 09 May '15

09 May '15

Hi to all. Today I want to remove document units from effect.cpp/h to aboid crash noticed by Tav. Also remove units handle from fillet-chamfer and roughen LPE. Finaly there is two LPE harcoded to use "PX" as document units and we need to fix it: path_length and ruler Best of all, Jabier.

1 0

Glue together extension
by Christopher Saloman 08 May '15

08 May '15

I wrote a small extension to place multiple objects next to each other (with 0 distance to each other) vertically or horizontally as i need this quite often. Don't know if this is already implemented somewhere. But in case it isn't here is the code: https://github.com/mrsalo/inkscape_glue_extension

1 0

Inkscape_trunk_scan-build - Build # 72 - Unstable!
by Jenkins (build tester) 07 May '15

07 May '15

Hi developers, Clang scanbuild found a potential bug in recently committed code. Inkscape_trunk_scan-build - Build # 72 - Unstable. See here which bugs were found (new in red): http://jenkins.inkscape.org/job/Inkscape_trunk_scan-build/72/clangScanBuild… It is paramount to keep our codebase clean with as little compiler warnings as possible, so we can swiftly eradicate newly introduced bugs, to keep Inkscape stable and prevent lengthy dragging bug hunts before releases. Your friend, Jenkins http://jenkins.inkscape.org

3 12

Multilingual SVG
by Jabiertxo Arraiza Cenoz 06 May '15

06 May '15

Hi All. I want to improve switch work, to find a way to handle multilenguage SVG's. I try to explain whats in my mind to be improved with your thoughts. *current document is the default document. *When add a new lang, all contents is cloned/copied into a switch into his target lang. *I think clones are paths, ellipses, stars.... and copies are text elements and groups *Default document is moved to the default lang in switch. *Currently inkscape show the switch in current system lang, this behabiour is good for a viewer but we need a switcher for diferent langs, so the user pick the lenguage to use and inkscape reloads with this lang. Waiting to start, J.

3 2

patch test, causing crashes for another tester, not me
by insaner 04 May '15

04 May '15

I wrote up the following patch: https://bugs.launchpad.net/inkscape/+bug/1169123 And a user on IRC said they have a crash when adding a filter, I have no such crash and was wondering if someone could possibly shed some light on this. Their crash details: http://pastebin.com/FDaTFjwB http://pastebin.com/HHhq3KdQ http://pastebin.com/SSGPbfpb -- View this message in context: http://inkscape.13.x6.nabble.com/patch-test-causing-crashes-for-another-tes… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

Hackfest Q&A on git
by Bryce Harrington 04 May '15

04 May '15

On the last day of the hackfest, we discussed git over lunch. A few folks on IRC had questions about what we talked about, and I figured there'd be wider interest so am writing this up. What is motivating us to switch? Is bzr going away? Development of bzr has stopped. A couple years ago Canonical reassigned all the bzr devs to other projects, leaving just a skeleton staff to do bug maintenance (same was done with Launchpad). There had been a time when Canonical pushed bzr as the Cat's Meow, but I think the realization has sunk in that git has won the larger hearts and minds war. bzr is not going away though, near as I can tell. There's no urgency to move to something else; we can stay with it indefinitely if we want. But it's a dead end tool. As we recruit new developers we will find more often they have git experience but not bzr; eventually bzr will be a detriment to attracting new talent that will prefer to invest their skills in git. And there's no guarantee Canonical won't pull the plug on it at some point, regardless. There are also tons of tools, web applications, and so on being developed for git. What exists for bzr is in process of bitrotting away (e.g. I tried to install the rebase plugin last night but it's several bzr revisions out of date, and did not work.) Isn't git hard to learn? bzr seems so natural... git has a reputation for having a high learning curve, and it's legitimately earned. But most all of us have at least had a little exposure to git, and there are plenty of good tutorials out there. git was a struggle for me to learn, so I won't sugar coat it and say it'll be easy. But I will say if you haven't yet mastered git, then it's an important software development skill you're going to want to have beyond Inkscape anyway, since pretty much all other projects use it. What about Launchpad and its bzr integration? One of the reasons we picked bzr was because of its integration with the bug tracker, and yes that's pretty cool and something we'll lose making the transition. The good news is that unlike when we switched to bzr, there are now a number of good web apps and services (github clones, et al). So we'll have a wealth of options to consider when we get to this point. Where will we host the repository? github? freedesktop? One nice thing with git is that we will have 100% freedom in deciding where to host the official repo. We can even consider self-hosting it (e.g. on our website vm). We have lots and lots of options, and plenty of time to deliberate and decide on a plan. Can it import our history? tags? Yep. Lots of projects have preceeded us in bzr->git conversions and there's a rich set of well tested converter tools available. Can we still do PPA recipe builds on Launchpad? Sure can. Launchpad may only host bzr but it has a very good git importer. So we'd set up LP to import our git branch to a bzr tracking branch on LP and then it's business as normal. Can we convert to git ASAP? I know some people are anxious to move us over to git, and so am I, but we need to pace ourselves. Changing VCS is going to be disruptive to everyone, and it will take time before everyone's up to speed with it. As a project there are other changes which are more pressing, which we need to give priority to. If we rush into git, we're likely to make mistakes or at least cause unnecessary frustrations. Planned well, we can make the transition relatively smooth, and ensure there are tutorials and tips available as needed. Bryce

7 8

Re: [Inkscape-devel] Hackfest build-systems discussion]
by Ken Moffat 04 May '15

04 May '15

Whoops, replied to Bryce instead of to all. Let's try sending it to the list. On Sun, May 03, 2015 at 03:00:30AM +0100, Ken Moffat wrote: > On Sat, May 02, 2015 at 06:34:57PM -0700, Bryce Harrington wrote: > > On Sat, May 02, 2015 at 11:39:34PM +0100, Ken Moffat wrote: > > > On Tue, Apr 28, 2015 at 08:35:00PM -0700, Bryce Harrington wrote: > > > > On Wed, Apr 29, 2015 at 02:51:15AM +0100, Ken Moffat wrote: > > > Yes, cmake -L appears to know what it is doing (noted some things I > > > > Building seemed to be going well, until > > > > > > [ 65%] Building CXX object > > > src/CMakeFiles/inkscape.dir/ui/dialog/text-edit.cpp.o > > > /scratch/ken/bazaar/inkscape/src/ui/dialog/text-edit.cpp:29:32: > > > fatal error: gtkspell/gtkspell.h: No such file or directory > > > compilation terminated. > > > > > > And when I look back at the cmake output it says: > > > -- checking for module 'gtkspell-2.0' > > > -- package 'gtkspell-2.0' not found > > > > What it's doing at that point is shelling out to pkg-config to see if > > gtkspell is installed. > > > > pkg-config --cflags --libs gtkspell-2.0 > > > > Run ^ that on your commandline and see what it says. If you don't have > > it installed, install it. :-) > > > I know I don't have it installed. If it is now required, I assumed > cmake would tell me. > At this point, I'm looking at r14094. If you will accept that, for the moment, using ./autogen.sh and configure is still a valid comparison, then gtkspell is optional. With autogen.sh and configure I've managed to build it - no sign of gtkspell (nor the coreldraw, vision, whatever) stuff. Some hours later, after copious swearing (is that required or does it only seem to help ? ;-), I think I've found where the problem is. With the following patch, I can cmake, build and DESTDIR install inkscape and the man pages, without any additional -D magic. I will note that inkview did not get installed. I would have thought that the set line I deleted would have done the right thing, but for me it didn't. If this is acceptable, do you need a SoB or equivalent ? ĸen --- inkscape/CMakeScripts/DefineDependsandFlags.cmake.orig 2015-05-03 22:06:01.598985260 +0100 +++ inkscape/CMakeScripts/DefineDependsandFlags.cmake 2015-05-03 22:08:03.313995015 +0100 @@ -290,8 +290,9 @@ list(APPEND INKSCAPE_INCS_SYS ${GTKSPELL_INCLUDE_DIR}) list(APPEND INKSCAPE_LIBS ${GTKSPELL_LIBRARIES}) add_definitions(${GTKSPELL_DEFINITIONS}) + else() + set(WITH_GTKSPELL OFF) endif() - set(WITH_GTKSPELL ${GTKSPELL_FOUND}) endif() #find_package(OpenSSL) ĸ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.

2 1

cmake next steps
by Bryce Harrington 03 May '15

03 May '15

Several of us now are able to successfully build Inkscape using cmake only. This is still relatively new, but we need to broaden this to everyone and make sure it works universally. Do a 'make distclean' in your repo, update to latest bzr, and then: $ cmake . $ make -j8 Hopefully this "just works". If not, read on for troubleshooting tips. CMakeCache.txt is a listing of all configurable parameters and all computed values. For settables, you can force them via: $ cmake -D<VARIABLE>=<VALUE> If the build craps out during build or linking due to some missing bit or other, reviewing this file can indicate if it has misdetected an include or library path or whatnot. CMakeList.txt is the top level build script, and generally the place to start for debugging problems. This also is where all configurable option parameters should be defined. There is also a src/CMakeList.txt where the source files and header files are itemized. This also sets up rules for compiling and linking the executable and its libraries. Similar CMakeList.txt files are placed in other directories with source. The CMakeScripts/ directory holds various helper functions. In this directory is a Modules subdirectory; this is where the logic is held that finds where various dependencies have their include and library files located. If you get errors about dependency headers not found during build, or during linking it can't find definitions of symbols then there could be an error in one of the Module Find*.cmake files. CMakeScripts/DefineDependsandFlags.cmake is another important file; this is where the include path and library options are worked out. This file is essentially the "glue" that utilizes all the Modules, and propagates settings up to the top level script. Beyond this, there is a wealth of cmake tips and examples on the web, so google will be your friend. ------------------------------------------------------------------------ So what development needs done? While the cmake scripts work, they're a bit hacky and in need of some cleanup. Below is a laundry list. I'd encourage everyone to tackle a task or two, to get some cmake familiarity if nothing else. Once this work is all done, we can wrap up 0.92 and start the release process. 0. Cleanup definitions. In CMakeLists.txt there are a sequence of add_definitions() to set some environment variable definitions. Some of these may not be strictly needed, others could be moved to DefineDependsandFlags.cmake or to the respective Modules files. 1. Win32. Someone needs to try this against our supported win32 platforms, and fill in the missing logic that is specific to Win32. 2. More files. A lot is missing from the build... tests, man files, icons, locale. If it's not clear how to do the logic for this stuff, refer to another cmake-based project. 3. More Modules. In DefineDependsandFlags.cmake we just brute force several libraries (to pick a few examples: pangocairo, gthread, gomp, gslcblas...) These need to have proper Find<Library>.cmake scripts made. Generally these are pretty easy - just make it wrapperize pkgconfig. FindGtkSpell.cmake has a simple example. Google "cmake <library>" before you do any work though; sometimes someone has already done the logic and you can just copy. 4. Update Modules. Several of our modules were taken from cmake or elsewhere, a long time ago, and they've improved upstream since then. Snag newer versions, test, and add to our codebase. If we have local changes consider pushing those upstream. 5. Add more configuration options. Review what we offer in automake and make sure the equivalents are defined in CMakeLists.txt 6. Verify that uninstall works 7. Fix dist. In CMakeLists.txt it adds a custom svn command; this needs replaced with the equivalent bzr. And in general run 'make dist' and hack on it until it produces a proper tarball. 8. Identify other issues needing resolved. I notice FIXME's peppered here and there in various files. We'll want to tackle those or at least plan those tasks for later on. Bryce

3 2