- Inkscape Devel - Inkscape Mailman

Waf build system, second try
by Krzysztof Kosiński 01 Feb '14

01 Feb '14

Hello everyone, I conducted an experiment in building Inkscape with Waf, redoing the work I did a long time ago with a newer version (1.7.15) and using more of its features. A correct build of Inkscape, with internal libraries built separately, "inklib" built as a shared library, Bazaar revision fetching and .po file compilation, requires less than 250 lines of Python script (!!!). I read on some mailing lists that Debian refused to package some software using Waf, because Debian considers shipping the "Waf binary" to be incompatible with the DFSG. I circumvented this problem by adding the Waf source distribution to the tree, which is a little bigger, but DFSG-compliant and works exactly the same. The code will be up shortly at lp:~tweenk/inkscape/waf-build, if anyone wants to check it out. Regards, Krzysztof

10 28

Re: [Inkscape-devel] Waf build system, second try
by Johan Engelen 31 Jan '14

31 Jan '14

Hi Isobel, I'll be on vacation for a week, can't give a detailed answer now. But I am not the right person to ask anyway :) I think _building_ is the easy part, but getting all the include flags correct for all platforms is not. (which is "configuration" that you mean?) An example of what would be nice to have is the ability to specify additional compiler flags for each folder. Current architecture's biggest problem is that it is not crossplatform. Note that on Windows, cygwin is cumbersome and not something we want to do. ciao, Johan ----- Reply message ----- From: "Isobel Knowles" <ik5@...2950...> To: "Johan Engelen" <jbc.engelen@...2592...> Cc: <inkscape-devel(a)lists.sourceforge.net> Subject: [Inkscape-devel] Waf build system, second try Date: Fri, Jan 31, 2014 00:14 On Thu, 30 Jan 2014 20:11:14 +0100 Johan Engelen <jbc.engelen@...2592...> wrote: > > On 30-1-2014 20:02, Isobel Knowles wrote: > > PS. My offer to write some 'nice' makefiles is still open. > > No-one is stopping you :-) > Make us dazzle... > > :) > Johan Dear Johan, OK. Before I do, do you think you could tell me what it is you want from the build? What are the essentials and what are the nice-to-haves? Where do you see the problems in the current architecture and what are its strengths? I'm only after some pointers so I don't set off in the wrong direction. I'll start the ball rolling with these: - Documentation. People who are new to Inkscape should find it easy to edit the makefiles. - Separate configuration and build cleanly so when the configuration phase doesn't do what you want for one reason or another, it is straight-forward to manually configure the build options in one or two files. - Separate compilation and installation/packaging. Installation is generally performed as root, and all too often in GNU software libtool and the like get their teeth into a 'make install', turning it into compilation job. This is wrong. - An ordinary build job should do the minimum work in the minimum time. For this I propose a flat makefile structure, perhaps composed of included makefiles. Parallel makes like this perform correctly and have no scalability issues whereas recursive makefiles are beset with problems and complication. - It should be simple to modify build flags and make alternative targets for debugging purposes. I wouldn't describe it as dazzling, but it's a start. Yours, Is.

1 0

Copying text with pattern stroke and fill + text decoration issue
by mathog 30 Jan '14

30 Jan '14

Hi all, After adding pattern fill and stroke support for text decoration I found that if both text decoration and a pattern are active, then trying to copy a text object with that combination crashes inkscape. That is, in rough terms, if the input file contains: <text > <tspan style=" pattern fill " > A <tspan style="text-decoration:underline">B</tspan></tspan></text> it loads and renders properly. But if "AB" is selected as an object (not as the text) and "^c" to copy, it crashes in style.cpp in sp_style_paint_server_ref_modified because "server" is not the same as style->getStrokePaintServer() (or style->getTextDecorationStrokePaintServer(), but these last two are identical in the test cases.) That is (sorry about the wrap): (gdb) print *server $1 = {<SPObject> = {_vptr.SPObject = 0x8a13e48, cloned = 0, uflags = 0, mflags = 0, xml_space = {set = 0, value = 0}, hrefcount = 1, _total_hrefcount = 1, document = 0x9232a80, parent = 0xa082ad8, children = 0xa086210, _last_child = 0xa086210, next = 0xa0c2ea8, id = 0xbadc000 "Packedcircles", repr = 0xbbb26f0, refCount = 4, style = 0xa096200, _release_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0xa0f6d48}, <No data fields>}, <No data fields>}, _delete_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _position_changed_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _modified_signal = {<sigc::signal2<void, SPObject*, unsigned int, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = { callback_list_ = 0x0}, impl_ = 0xa0765e8}, <No data fields>}, <No data fields>}, _successor = 0x0, _collection_policy = SPObject::ALWAYS_COLLECT, _label = 0x0, _default_label = 0x0}, swatch = false} (gdb) print *style->getTextDecorationStrokePaintServer() $2 = {<SPObject> = {_vptr.SPObject = 0x8a13e48, cloned = 0, uflags = 0, mflags = 0, xml_space = {set = 0, value = 0}, hrefcount = 7, _total_hrefcount = 7, document = 0x9232a80, parent = 0xa082ad8, children = 0x0, _last_child = 0x0, next = 0xa099530, id = 0xa059ab0 "pattern5506", repr = 0xbbb5ff0, refCount = 1, style = 0xa07be48, _release_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0xa0ccfc0}, <No data fields>}, <No data fields>}, _delete_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _position_changed_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0}, impl_ = 0x0}, <No data fields>}, <No data fields>}, _modified_signal = {<sigc::signal2<void, SPObject*, unsigned int, sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = { callback_list_ = 0x0}, impl_ = 0xa0e8fd0}, <No data fields>}, <No data fields>}, _successor = 0x0, _collection_policy = SPObject::ALWAYS_COLLECT, _label = 0x0, _default_label = 0x0}, swatch = false} It seems like the objects are put together differently when they are copied than when they are just read in. The clue comes from the "pattern5506" above. That ID isn't in the original file, it is somehow created during the copy operation. Can somebody tell me where that is happening? The object construction when the file is opened or reverted is in style.cpp, if the copy feeds through there too, I guess the question becomes "where is the SVG created" that is fed into it. If the text-decoration just uses solid colors and fills there are no issues copying a complex formatted text object with text decorations. It is only when patterns and text decorations are both present that things go south. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Trunk is broken enough to merit complaining
by Josh Andler 29 Jan '14

29 Jan '14

Hey All, Thankfully it's been a while since this has been an issue, but it seems that a reminder is needed. The only real rule we tend to have for committing to trunk is "don't break trunk". Unfortunately, trunk is currently pretty broken when trying to work with imported bitmaps. If whomever broke it can get back to fixing it, it would be greatly appreciated. In the future, just remember, if you won't have the free time within 1 day to fix something you might have accidentally broken... please wait to commit it until you do. If you can not figure out an appropriate fix, please revert the changes and work via patches in the tracker or in a branch until you can figure it out (so others can help test). Cheers, Josh

3 2

Re: [Inkscape-devel] Trunk is broken enough to merit complaining
by mathog 29 Jan '14

29 Jan '14

> Thankfully it's been a while since this has been an issue, but it > seems that a reminder is needed. The only real rule we tend to have > for committing to trunk is "don't break trunk". Unfortunately, trunk > is currently pretty broken when trying to work with imported bitmaps. > If whomever broke it can get back to fixing it, it would be greatly > appreciated. It's more broken than that, unfortunately, since on my Ubuntu test machine the inkscape binaries from 12978 on no longer even get to the point where they put any graphics on the screen. The reason it is crashing is complex enough that it really is above and beyond the call of duty for other developers to have to figure it out. (For instance, the failure mode is different in the debugger than outside of it.) So, Martin, please pull out all of the image changes from around 12939 through 12978 and test them for a while in a separate branch. Before resubmitting them to trunk, please have people test your branch on other platforms. Or at the very least run valgrind on it and make sure there are no (new) memory access issues in the code you are adding. (Admittedly this is a bit of a pain since there are already so many memory issues in Inkscape.) These image changes must have worked on Martin's machine, presumably because the memory problems didn't happen to blow up anything there, but they are show stoppers for me. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Writing Tests for URI
by Martin Owens 29 Jan '14

29 Jan '14

Hi devs, I want to write a test suite for uri.h/uri.cpp; I had a look to see if there are existing tests for the code and I admit I find myself a little confused. There's a directory called cxxtest which contains tests and then there are *-test.h files in the actual codebase. My feeling is to use extract-uri-test.h, copy it for a new uri-test.h file. But this might be wrong. New URI functionality includes: dealing with data uri, getting full path name (previous work) and further intergration between it and io/uristream.cpp to feed that lovely data in transparently when needed. Should conclude with the ability to quickly move any href from attribute to workable data. Martin,

2 1

Bug Hunt for 0.91
by Bryce Harrington 29 Jan '14

29 Jan '14

Welcome to the first bug hunt for the 0.91 release. This hunt focuses on regression bugs. Traditionally, we specify a point target for us to reach, and award us points based on the severity of the bug: 3, 6, 9, or 12 points for low, medium, high, and critical. This bug hunt's goal is 500 points worth of bugs from the following list: http://tinyurl.com/bughunt91a You'll note a few dozen regressions were already fixed, so we'll count that as a (207 point) headstart on the effort. Here's a couple more links to list only the open or closed bugs: http://tinyurl.com/bughunt91a-open http://tinyurl.com/bughunt91a-closed [I'll write a launchpadlib script to calculate the score from the latter list, unless someone's ambitious and beats me to it!] We only give points for true bug fixes - not bugs simply closed due to being dupes, invalid, works-for-me, or whatnot. Once the bug is fixed in the mainline branch, set its status to Fix Committed, and it'll tally as a fixed regression. Bug Hunt Goal: 500 points Current: 207 points If you're not a developer, you can still help by seeing if you can reproduce the bug yourself, and posting your findings. If you have an idea on how to fix the bug, but don't have the time to do it yourself, then outlining your thoughts on the bug may help junior developers pick it up and implement the changes. If you're an experienced developer, consider posting an invitation to an IRC bug party for the time period you'll be working, if you're willing to help pilot junior developers and sponsor their patches. I will be posting scoring updates a couple times a week until we're done. Bryce

4 9

Cairo and ISO C++
by Tavmjong Bah 28 Jan '14

28 Jan '14

Hi, There is a proposal before the ISO C++ standards group for a technical specification for 2D graphics based on the Cairo API.[1] It seems to have gained some traction. My question here is what is missing in the Cairo API that would be useful for rendering SVG? Tav [1] http://isocpp.org/files/papers/N3888.pdf

3 3

Strange Error
by Arshdeep Singh 26 Jan '14

26 Jan '14

Hi, I participated is GSoC 2013 and wrote code for Inkscape. I was working in WIndows last year and sometime around December I decided to port my branch to Linux (Ubuntu 12.10 , in my case) . Strangely, I am caught up with this error, which doesn't trouble me at all in my Windows branch: "ui/dialog/dialog-manager.o: In function `Inkscape::UI::Dialog::RecolorArtwork::getInstance()': /home/arshdeep/Desktop/InkS-Repo/recolor/src/./ui/dialog/recolor-artwork.h:38: undefined reference to `Inkscape::UI::Dialog::RecolorArtwork::RecolorArtwork()' collect2: error: ld returned 1 exit status " This happens only when I am associating a dialog box of the tool that I made last year thorugh the codeline: " registerFactory("RecolorArtwork", &create<RecolorArtwork, FloatingBehavior>); " inside of dialog-manager.cpp. The RecolorArtwork class is mirrored directly from FillAndStroke class and I can't pin point why this error crops up ? If someone can help , please do so. -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 1

Simple String Handling
by Martin Owens 25 Jan '14

25 Jan '14

Hi devs, I've tried out the following patch: http://paste.ubuntu.com/6809633/ And it's not working. The path which used to work well, it now being overwritten with garbage data before the file can be opened. As if the reference has been freed. I'm sure it's something simple to do with those consts or gchar types. Any ideas? Example output: ** (inkscape:4946): WARNING **: Can't open file: /home/doctormo/D\x89 \x99 (doesn't exist) ** (inkscape:4946): WARNING **: Can't get document for referenced URI: inner.svg#bar Martin,

3 3

Removal of popt
by Krzysztof Kosiński 24 Jan '14

24 Jan '14

Hello The bug which is keeping us with popt has been recently fixed. https://bugzilla.gnome.org/show_bug.cgi?id=722025 This means we can remove several kb of code and remove one of our dependencies by changing command line parsing from popt to GOption. Since the bug was Windows-specific, we can do this once the next stable version of glib is released. Regards, Krzysztof

4 5

Re: [Inkscape-devel] Why is the position of this line of code so touchy?
by Krzysztof Kosiński 24 Jan '14

24 Jan '14

2014/1/24 mathog <mathog@...1176...>: >> This line is completely equivalent to replacing it with a call to >> cairo_save and adding a call to cairo_restore at the very end of the >> containing scope. >> >> You cannot move this line into a different function, because then the >> destructor (and hence cairo_restore) gets called when decorateItem() >> returns. > > Except my code ONLY works if it is moved into another function! That's what > is driving me nuts. I will have to trace this code thoroughly, as there > must be a dangling transformation or an extra cairo_restore or cairo_save > somewhere. Please post a more complete listing of the good and the malfunctioning version of your code. I'm sure we'll find the problem then. The "call, line1, line2" etc. descriptions in your initial e-mail are a little insufficient to figure out what is going on. > I guess. I am not a fan of implicit side effects unless there is absolutely > no way around it. Here > > dc.save() > blah > dc.restore() > > would have worked, and it would have been immediately apparent to a > maintenance programmer what was going on. Or is the ::Save stuff in there > to clean up in case there is an exception and the code jumps to a handler, > without ever returning from these functions? You can add an early return and forget about adding the cleanup code, there can be an exception, or you can simply forget about adding he restore(). The ::Save object ensures proper cleanup in all of those possibilities. Regards, Krzysztof

1 0

C++ explanation please
by mathog 24 Jan '14

24 Jan '14

Sometimes it is hard to shake off decades of C programming, so please bear with. In src/display/drawing-context.h near the top one finds: class DrawingContext : boost::noncopyable { public: class Save { public: Save(); Save(DrawingContext &ct); ~Save(); void save(DrawingContext &ct); private: DrawingContext *_ct; }; and in drawing-context.cpp those methods all use ct and _ct for the variable names. Which is all fine and would be no issue at all, except that below the lines just cited in drawing-context.h every place one finds a reference to ct or _ct it is a cairo_t or a cairo_t*, not a DrawingContext. Can somebody please explain why it is considered helpful in C++ to use "ct" to mean two different things like this in the one header file? The disadvantage of doing it the way it is now is that when somebody like me encounters _ct elsewhere in src/display, and looks for it like this: grep '[\* ]_ct[; {]' src/display/*.h it finds two definitions: DrawingContext *_ct; and cairo_t *_ct; with the end result that one must read the file to figure out what is actually going on. Had the first set used "DC"/"_DC", for instance, there would have been no confusion, and the second step would have been eliminated. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 5

forward declarations janitorial task
by Guiu Rocafort 23 Jan '14

23 Jan '14

hi list. I'm taking a look at the janitorial task, specially to the forward declaration in the wiki[1]. But there is something i'm not sure about. You can use the forward declaration only if you're using the class as a pointer and without using any of its functions/attributes ? or is it just when using the class as a pointer ? for example, in attribute-rel-util.h, i can get rid of the xml/node.h include, but sp-css-attr.h doesn't seem to work. Am I missing something ? [1] http://wiki.inkscape.org/wiki/index.php/Janitorial_tasks#Improving_headers_… -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

2 1

Fwd: Re: C++ explanation please
by mathog 23 Jan '14

23 Jan '14

On 22-Jan-2014 13:39, Johan Engelen wrote: > You have to trace the scope hierarchy > manually (e.g. function body -> class declaration -> base class > declaration(s)) This is probably a rant... Never mind tracing the variables, tracing execution to see which parts are actually used can be tedious too. I spent too much of the last day doing just that. Experimental text decoration display is currently in trunk, along with a patch (in Launchpad) that modifies the Text and Font dialog to allow crude editing of those properties. Now one might think that since Cairo is used for the display, and Cairo is used to render to PDF (and others), that implementing a type of draw for display would automatically show up in render. Nope, none of the text decorations render to a file. As far as I can tell the display and render functions are both intertwined, and separate. This is what happens when Inkscape saves to a PDF (just the highlights, obviously a lot of other stuff goes on too). Starting at (A) src/extension/internal/cairo_render_pdf_out.cpp (A) pdf_render_to_document_file() (C) (->B) (H) (->I) (T) DONE! src/sp_item.cpp (B) invoke_show (->D) (G) (return ->H) src/libnrtype/Layout-TNG-Output.cpp (D) Layout::show (->E) (F) (return ->G) (L) showGlyphs (->M) (P) (return ->Q) src/display/drawing_text.cpp (E) addcomponent (add a glyph to a list, copy some parts of style into _nrstyle) (return ->F) (Z) _renderItem (draws glyphs for cairo for DISPLAY of text) src/extension/internal/cairo_renderer.cpp (I) renderItem (->J) (S) (return ->T) (J) sp_item_invoke_rendering (->K) (R) (return ->S) (K) sp_text_render (->M) (Q) (return ->R) src/extension/internal/cairo_render_context.cpp (M) renderGlyphText (->N) (O) (return ->P) (N) showGlyphs (draws glyphs for cairo for RENDER of text) (->O) When text is displayed (on the drawing surface) it also follows a call to addcomponent (E) and (if there are changes(?)) Layout::Show (D), but goes through _renderItem (Z) in src/display/drawing_text.cpp, which is never called in the trace above. Text display doesn't touch the rest of the trace shown above. In _renderItem it deals with an object DrawingContext, whereas in the trace above it carries around an object CairoRenderContext. In terms of activity both of these objects are just wrappers around Cairo - but exceedingly different wrappers. _renderItem is fairly similar to renderGlyphText (M) [but ironically, not to renderItem(I)], so renderGlyphText (M) is one logical place to patch in text decorations for render. However, when I implemented text_decoration display, which is called from _renderItem (Z) the code naturally used DrawingContext and _nrstyle (E), and neither of those is available in renderGlyphText (M), which greatly complicates implementing text decoration for render. Maybe text draw and text render were designed to be this different, but it feels an awful lot like an instance of divergent evolution. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

Href sub-document model (Martin Owens)
by Jelle Mulder 22 Jan '14

22 Jan '14

Hi Martin, Let me start with telling that I'm thrilled that you're doing work on external <use> links and have some working code. I hope it will find its way into the 0.91 version as it will make my life so much easier. However, while you're at it. Three questions arise. - Can this mechanism be used to add external CSS as well? I know Bruno Wick is working on that as well, but it seems you're on a roll here and would be the missing link (pun intended). - Would it be possible to create a save option where such external files are concatenated into one big whopper of a file? Or even better, send it all to a single root file of users choice (oh joy!)? With some nice check marks to add or not CSS, external <USE> objects, etc? It would solve a problem for all those browsers that do not support external linking or have bugs*. *(like webkit that supported external links till Chrome version 19 and then Blink had this nice regression that yet has to get solved. Opera works fine till version 12.5 and then they went Blink, Firefox can only handle links one directory level deep these days, sigh. I foresee a brighter future though) - And the very whopper question that probably stretches your patience.. How about kicking all <use> objects to external files and style info to external CSS? <script> to external files? Again with switches for each type of export. I gather this to be a whole other ball game and probably not ready for 0.91, but what power would that give to Inkscape as authoring tool for web projects! Ehm,.. sorry if this abuses the dev list as it sounds very much like something I should throw at the bugtracker wish list, but 95% of my request get timed out due to latency I experience in Chongqing, China, so I never manage to send something there. On the other hand, I think it is on topic. Jubilant cheers, Jelle Mulder > Message: 1 > Date: Tue, 21 Jan 2014 11:09:58 -0500 > From: Martin Owens <doctormo@...400...> > Subject: [Inkscape-devel] Href sub-document model > To: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > Message-ID: <1390320598.10117.59.camel@...2056...> > Content-Type: text/plain; charset="UTF-8" > > Hey developers, > > This is the model I'm going to implement for documents to reference > other documents: > > SPDocument { > GSList *child_documents; > SPDocument *parent_document; > > // Parent of parents until parent == NULL; > SPDocument *getRootDocument(); > } > > Then in uri-reference, check paths of existing child_documents, load the > referenced document and add to child_documents. Set parent_document. > > That should keep things consistant. > > The idea here is that we'll use this to track documents referenced in > <use tags> as well as <image tags> and attributes like 'marker-*: > url(...);' but not for non-vector graphics used in the image tag. > > Thoughts? Advice? > > Best Regards, Martin Owens

3 3

What is the intended purpose of this line of code?
by mathog 21 Jan '14

21 Jan '14

Hi all, While trying to find a place to patch in text-decoration writes so that they show up in cairo based file types (PDF and the like), I noticed that simple multicharacter tspans were being broken into single glyph writes by this line in TNG-Output.cpp: && (font_matrix * glyph_matrix.inverse()).isIdentity() because the test is always false. Here is the link to it in context (barring edits to that file in a revision after I send this) http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/lib… If that one line is commented out it lets something like <tspan>123456</tspan> pass through to renderGlyphtext() in one big chunk, but other than that, it doesn't seem to make any difference. Can somebody tell me why that test is there? It seems to be doing the wrong thing in all the test cases I have run through it, unnecessarily breaking up the writes, but that doesn't mean that it does not resolve a problem that arises in some case I have not yet considered. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Compile Inkscape - Problem Link DLL and .lib file
by naim 21 Jan '14

21 Jan '14

Hi I got a DLL and its .lib file that expose some functions. I need to use those functions to customize Inkscape. My question is, how do I configure build.xml so that compiler will link the .lib file? Thanks, Naim

1 0

External SVG Files via href
by Martin Owens 21 Jan '14

21 Jan '14

Hey Devs, I've been looking into this bug: https://bugs.launchpad.net/inkscape/+bug/1269880 And have forged a solution in uri-references.cpp by using the existing getPath property and GLib's build_filename. See the commit here: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12939 I really didn't expect this to work, I thought it'd be step one in a chain of items to fix. But it actually works and I'd like other dev's input to see if it's doing the right thing. I'd like to have a document based list of linked documents, so they could be tracked (and maybe ui'ed in the future). But I'm not sure if it's even needed. Thoughts? Best Regards, Martin Owens

3 5

Text decorations, GUI
by mathog 21 Jan '14

21 Jan '14

Display of text decorations is in trunk and it can display things as shown in this example: https://launchpadlibrarian.net/140347078/text_decorations.png (Note install the last patch in https://bugs.launchpad.net/inkscape/+bug/1243401 to see these again, as a recent change to trunk broke them.) Text decoration control requires three GUI fields: Line: NONE, or any combination of: underline, overline, linethrough, blink Style: solid, double, dashed, wavy Color: From Text or (Color setting widget) I'm thinking about what the GUI should look like to access these. My first thought was to add them to the "A" (Create and edit text objects) part of the GUI, since text decoration does not make a lot of sense without text to decorate, and this sort of thing would be in a part of the GUI like that in a Word processor. But that part of the GUI is already packed with options, to the extent that on my computer I can only see all the options when Inkscape fills the entire screen. If text decoration was added there, it would never all fit. So my second thought was to maybe put these in "A (with a wavy line through it)" as (Create and edit text decorations). That would let it fit on screen better, at the cost of making the line of icons down the left side of the screen one longer. The third option is to add a second line of options to the existing "A". That would use up more vertical screen space, but it would have the advantage that all of the text and text decoration formatting options could be on screen at once. This is more of a departure for the GUI, since it seems not to happen anywhere else. Thoughts? (Note: "blink" line type is emulated with a type of double line style. I don't expect true blink display to be found in many SVG viewers, ever, so all Inkscape has to do is indicate that it is set.) Is there at present anything in the Inkscape GUI where a check box widget is exposed when one of the left side icons is selected? As far as I could tell all of the widgets exposed by selecting one of those icons are of the "select one" type. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 4

wiki.inkscape.org down
by Guiu Rocafort 20 Jan '14

20 Jan '14

Hi ! I noticed that the wiki page wiki.inkscape.org is down ( at least for me and from this page[1] ) Guiu [1] http://downforeveryoneorjustme.com/wiki.inkscape.org -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

5 5

Symmetry Tool
by Tom Lechner 19 Jan '14

19 Jan '14

Is anyone out there secretly working on the symmetry-tool branch? I've tried to compile recently, but it seems to be suffering some bit rot. I'm working through errors, but for the moment I'm stumped on what seems to be a lot of c style object code from the general src breaking compilation. Any hints? -Tom ----- tomlechner.com

3 3

Menu option for web pages.
by john Culleton 17 Jan '14

17 Jan '14

The one major item that is available in html5 that I miss in Inkscape 48.4 is the drop down menu feature. I can emulate it of course with a second (third etc.) copy of the entire index.svg page with the menu dropped down. It would be cool however if I could overlay the first page with a smaller page consisting of just the menu items, live of course. Any thoughts on this? -- 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

2 1

Updated Fedora inkscape builds
by Ryan Lerch 16 Jan '14

16 Jan '14

Hi all, I am periodically building recent trunk versions of Inkscape for Fedora. all the details and repo installation inctructions are available here: http://copr-fe.cloud.fedoraproject.org/coprs/ryanlerch/inkscape-unstable/ cheers, ryanlerch

1 0

Unfinished features for 0.91?
by Bryce Harrington 15 Jan '14

15 Jan '14

Because we're now in the Chill phase of the release cycle, I need to inquire as to the status of any unfinished features for the 0.91 release. We still have ample time before the release, but what we want is for any feature that will take more than a month or two to reach full maturity, to be postponed for a future release. If you're working on a feature which you, or someone else, may legitimately consider to be not "release ready", please let me know asap. Bryce

8 17