November 2013 - Inkscape Devel

[tony@...3057...: URGENT: please remove Google Checkout links from your site ASAP]
by Bryce Harrington 20 Nov '13

20 Nov '13

Is anyone able to edit the current site? If so, we should switch off the google checkout links. Bryce ----- Forwarded message from Tony Sebro <tony@...3057...> ----- Date: Tue, 19 Nov 2013 17:34:57 -0500 From: Tony Sebro <tony@...3057...> To: inkscape@...3057..., Inkscape Board <inkscape-board(a)lists.sourceforge.net> Subject: URGENT: please remove Google Checkout links from your site ASAP Hi, all: I note that you still have a Google Checkout link on the Inkscape website (specifically, on your "Donate to Inkscape" page). As was announced a few weeks ago, Google is sunsetting their Google Checkout service as of tomorrow (November 20) [1]. To avoid creating problems for your donors (and for Conservancy), I ask that you please remove any Google Checkout links from your website immediately. Thanks! Best, -Tony [1] for more information on Google's time frame for shutting down Google Checkout, please refer to: https://support.google.com/checkout/sell/answer/3080449?hl=en-GB -- Tony Sebro, General Counsel, Software Freedom Conservancy +1-212-461-3245 x11 tony@...3057... www.sfconservancy.org ----- End forwarded message -----

2 3

possible bug
by TimeWaster 19 Nov '13

19 Nov '13

hi, i think with the change from inkex.unittouu to Effect.unittouu in inkex.py (r12722) was a bug introduced (regression). am i right that a user unit is equivalent to a pixel? if yes, the actual implementation is converting to *something* but not to user units. i think the code should look like this (or the method should be renamed to something other than *touu): if u: try: return retval * self.uuconv[u.string[u.start():u.end()]] except KeyError: pass else: # default take document unit return retval * self.uuconv[self.getDocumentUnit()] can somebody confirm this? its also the same with uutounit, it should be: def uutounit(self, val, unit): return val / self.uuconv[unit] regards, TimeWaster -- Save a printer manufacturer. Print this e-mail unless it's really necessary not to do so.

3 4

PDF X series.
by john Culleton 19 Nov '13

19 Nov '13

When I create a book cover using the perfect book cover template I still need to convert it to either PDF X/3 or PDF X/1-a:2001 format for the printer. Today there is no way to do this in Inkscape. I must import it into Scribus 1.5.0 or Adobe Acrobat just for the conversion. Are there any plans to add this feature to Inkscape? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

4 6

Devlibs, GTK3, latest TDM-GCC
by Johan Engelen 19 Nov '13

19 Nov '13

Hi all, To the devlibs gurus: what is the status of GTK3 devlibs and, can we try and make them compatible with the latest TDM-GCC? It'd be nice to be able to use the latest gcc so we can use more C++11 in the future. I'm not sure how much help can I can provide, but if supplied with sufficiently detailed instructions, I don't mind compiling a lot. Cheers, Johan

2 5

Branches: open them up !
by Johan Engelen 19 Nov '13

19 Nov '13

Hi all, Please open up your branches for commits from others. It is kind of annoying not being able to help...... Thanks, Johan

3 2

Embedded libraries
by Alex Valavanis 19 Nov '13

19 Nov '13

Hi All, I just thought that we could use a quick status check on the embedded libraries in the Inkscape repo... i.e., what we have, and what we intend to do with them. My personal preference is to get rid of as many of them as possible. Here is a list of what I think the current status is... please let me know what you think: * cxxtest - There's a patch for building against an external copy, but it introduces a few compiler warnings and there's no OSX port of cxxtest available yet [1]. We're currently running an ancient version with no customisation... we should really bump to the most recent upstream version and wait for OSX before we can drop it. Also, there's talk of replacing this with the google test framework. * 2geom - Tracking the possibility of building against an external copy here [2]. Last time I checked, there was a crash on startup. Perhaps it would be helpful to explicitly track the upstream revision of lib2geom that's currently embedded in trunk? Until it's packaged in distros, there's not much scope for aggressively pursuing this! * libavoid/libcola/libvpsc - all taken from the Adaptagrams project [3]. Review needed to see what divergence exists between our copy and the upstream version. Not available in many distros. * libcroco - tracked here [4]. All upstream changes merged. Minimisation of the diff in progress, then we can send patches upstream where possible. Available in Ubuntu, at least. * libdepixilize - New GSOC contribution. Any plans for this to be released as a standalone package? Would be good to enable an optional external build. * libgdl - We build against external lib when using the experimental gtk+ 3 branch. All the important patches have been accepted upstream. We'll delete our internal copy when we finally switch to gtk+ 3 builds. See bug #792115 [5]. No further action needed * libnrtype - I believe that there was a plan to replace most/all of this with Pango [6]. Is this still the intention? Is anyone in particular coordinating things? * libuemf - New contribution [7]: Is there a plan to push this to distros? Would be good to enable an optional external build * livarot - Apparently huge deviation from upstream lib [8]. Not in many distros. ...and I think that's it! AV [1] https://bugs.launchpad.net/inkscape/+bug/1094771 [2] https://bugs.launchpad.net/inkscape/+bug/1155947 [3] http://www.adaptagrams.org/ [4] https://bugs.launchpad.net/inkscape/+bug/648246 [5] https://bugs.launchpad.net/inkscape/+bug/792115 [6] http://wiki.inkscape.org/wiki/index.php/Pangoification [7] http://sourceforge.net/projects/libuemf/ [8] http://sourceforge.net/projects/livarot/

5 7

new compile warnings on Windows r12816
by mathog 16 Nov '13

16 Nov '13

Some change recently in compiler flags on Windows build, now seeing at r12816 cc1.exe: warning: command line option '-Woverloaded-virtual' is valid for C++/ObjC++ but not for C [enabled by default] cc : compile src/libuemf/uemf_endian.c (src/libuemf/uemf.h modified) Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

scan-build
by Alex Valavanis 14 Nov '13

14 Nov '13

Hi All, Has anyone played around with the Clang analyzer much [1]? I gave it a quick run last night, and it picked up a few hundred potential issues in our code. At first glance, a lot of them are probably harmless, but the tool is very good at highlighting places where we could be referencing NULL pointers or using uninitialised variables. Even when we "know" that the highlighted code is safe (e.g., pointers have implicitly been checked before referencing), we can add assertions to make the safety explicit. Here's an example [2] I'd strongly recommend that we make use of this tool! AV [1] http://clang-analyzer.llvm.org/scan-build.html [2] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12798

2 2

xlink:href eternal files
by Jelle Mulder 13 Nov '13

13 Nov '13

Hello guys, I was wondering how much work it would be to get Inkscape to use external file objects in the xlink:href context. I would be way cool if that would be possible and it would make my life so much easier. Now I have to hand code it and rendering is only possible in browsers. But if it would be possible to <use> it in Inkscape and have the result be translated to all those other formats such as PDF it would create its own use case. Just sticking some objects from a library of objects together and separating the logic and the content of a project in Inkscape would be really useful. Granted, the problem arising is the amount of nesting to be available to a file, but if the nesting of linked objects goes too deep (more than 2 steps), it may be an option to copy them to the defs. It would also be useful to then be able to move them from the defs into an external file as to create libraries of objects. Obviously the Symbols tool basically uses this principle for the external libraries of objects, which get rendered in it, so my guess is that Inkscape basically is already capable of it. Giving the option to collate such projects together into a single file or vice versa, ripping them apart would be an added benefit. Cheers, Jelle

1 0

Namespace pollution (r12782)
by Krzysztof Kosiński 13 Nov '13

13 Nov '13

Hello r12782 introduces a third-level namespace called "Tools", i.e. Inkscape::UI::Tools. There are some problems with this: 1. While this does follow current practice, I don't think the current practice is any good. The only result of having such deeply nested namespace hierarchies is the need to tediously type this all out, since if there actually is a naming conflict they prevent, it's a symptom of bad design / naming. 2. "Tools" is pluralized, while "Dialog" and "Widget" are not. This is inconsistent. It is sufficient to put all UI code in Inkscape::UI. This would also remove any doubt over whether to use e.g. "Inkscape::UI::Dialog::Print" (which makes the name as used within the namespace ambigous - "Print" what?) or "Inkscape::UI::Dialog::PrintDialog" (which is redundant) - one would simply use "Inkscape::UI::PrintDialog". In general, 2 levels of namespaces are entirely sufficient. XML tree goes into Inkscape::XML, UI code goes into Inkscape::UI, object (SP) tree goes into Inkscape::SVG (in the future), and so on. Regards, Krzysztof

3 3