May 2014 - Inkscape Devel - Inkscape Mailman

Last call for 0.48.5
by Josh Andler 09 Jun '14

09 Jun '14

Hey all, We have some license compliance issues which have been fixed in the 0.48.x branch which is overdue for should release anyway. I don't recall seeing objections the last time releasing 0.48.5 was brought up (but could have missed something). If there are no issues left unmentioned or unresolved prior to next Sunday, May 25, we will move forward with releasing it. Given that our focus is really on moving forward with 0.91, please speak up as this is likely to be the last release in the 0.48 series. Cheers, Josh

5 8

Frost for 0.91
by Bryce Harrington 04 Jun '14

04 Jun '14

The release process is ready to now move to the Frost phase. 1. Open development. √ Triage and prioritize bugs report this year √ Itemize regression bugs found since last release 2. Chill. √ Development focuses on wrapping up √ Disable features that aren't finished √ Identify 'make distcheck' issues √ Identify any critical OSX/Win32 packaging issues √ Identify remaining writing needed for Release Notes. √ Regressions Bug Hunt: 500 points √ Update tutorials and other docs 3. Frost. √ Experimental Branch is forked √ Mainline Branch focuses on stabilization √ Only production-ready code committed to Mainline Post inkscape-0.91-pre0.tar.gz Finalize any major changes to platform packaging Release Notes should be >90% filled in. Inkscape must pass >90% of 'make distcheck' Start an About Screen contest General Bug Hunt: 1500 points Post additional inkscape-0.91-pre*.tar.gz releases Packagers test creating pkgs of the -pre* releases Mainline Branch =============== During the Frost period, developers should not commit changes to mainline unless the change improves the overall stability of Inkscape or is needed for packaging or to fix distcheck issues. Use your judgment as to what is "safe". If you're unsure, email me or Josh before committing and we'll make case-by-case decisions. As a general rule of thumb, if your commit doesn't specify a LP bug #, then it should probably be signed off on by josh or I. Experimental Branch =================== The Experimental Branch is now forked. You can check it out via: bzr branch lp:inkscape/experimental This is an official (but temporary) branch, for freely merging all development work. Please treat it as you would mainline when we're not in release, and strive to keep it buildable and usable. In particular, all merges of GSoC branches and other sponsored development work should target this experimental branch instead of mainline. Bug reports will be accepted for the experimental branch. These bug reports will be EOL'd when the experimental branch goes EOL. About Screen Contest ==================== Josh, can you and Ryan work on organizing this? This contest will need to be completed before we enter Freeze. Make Distcheck ============== Last I checked we had some distcheck issues, which will need to be resolved before we release. Basically just run `make distcheck` and work on sorting out the errors and warnings that print out. Bug Hunt ======== This time around, any bug filed against Inkscape is fair game. I'll be posting stats on Mondays. This next Monday I'll explain this in more detail. I'll start the count as of May 5th. Packaging ========= If you are working on packaging improvements, please continue to do so, with the goal of having it all in working order by the time Frost is over (probably several weeks from now). Bryce

2 2

SPPattern class refactorization.
by Tomasz Boczkowski 03 Jun '14

03 Jun '14

Hi! Tavmjonh Bah has suggested me to contact you and consult SPPaintServer class refactoring I would like to do. Currently SPPaintServer contains pattern_new method. Since it directly handles rendering and uses cairo, I think it could be moved outside of SP tree. My idea is to implement paint server drawing routines in a parallel hierarchy of classes belonging to New Renderer. Image [1] contains the class diagram. Common base for them would be NRPaintServer, containing pure virtual method pattern_new. Concrete NRPaintServer derivatives would contain a reference to corresponding SPTree items and use it while rendering. To choose an appropriate NRPaintServer for given SPPaintServer I thought about a factory method in NRPaintServer class. Example interfaces and their usage are shown at [2] The tricky part can be the implementation of NRPaintServer::create method. I have thought about two solutions: a) using a battery of dynamic_cast if statements like this: NRPaintServer* NRPaintServer::create(SPPaintServer* ps) { SPPattern* pattern = dynamic_cast<SPPattern*>ps; if (pattern != 0) { return new NRPattern(&pattern); } //and so on for gradients } b) using double-dispatch strategy. There would be an .cpp file internal class NRPaintServerFactory. class NRPaintServerFactory { public: virtual NRPaintServer* create(SPPaintServer*); virtual NRPaintServer* create(SPLinearGradient*); virtual NRPaintServer* create(SPRadialGradient*); //and so on } And NRPaintServer::create implementation would look like this: NRPaintServer* NRPaintServer::create(SPPaintServer* ps) { static NRPaintServerFactory *factory = new NRPaintServerFactory; return factory->create(ps); } What are your thoughts about this solution? [1]https://www.dropbox.com/s/bz83xd0ks378qys/NRPaintServer.svg [2]http://pastebin.com/h9AcrusW Regards, Tomasz

3 2

Making inkscape usable in valgrind grumble
by mathog 03 Jun '14

03 Jun '14

Hi all, In order to find memory leaks, some types of access violations, and the use of uninitialized variables I depend on valgrind. The problem is that valgrind is barely usable with Inkscape. The output on even the most minimal session (open, type a few letters, format them, close) runs to just under 500K lines and takes 5 minutes to complete. Some of this may be because garbage collection must be turned off in order to use valgrind. That is: export _INKSCAPE_GC=disable; valgrind .... src/inkscape There is no choice in that though, because if it is not done valgrind crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current Trunk). There is a libgc.supp in the top of the distribution, but it cannot be used on my system, since it does not suppress valgrind's crash when it tries to run inkscape with GC enabled. Here is the damage seen on a normal exit for a minimal run: ==16527== LEAK SUMMARY: ==16527== definitely lost: 567,697 bytes in 17,670 blocks ==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks ==16527== possibly lost: 21,940,610 bytes in 282,461 blocks ==16527== still reachable: 21,470,100 bytes in 360,304 blocks What can be done so that Inkscape makes a better effort at cleaning up its enormous memory tangle when it exits while running in valgrind? Some of the memory Inksape allocates is cleaned up, but it seems like a very high percentage of memory allocations are tacked into this complex memory structure, and inside valgrind the whole ball of yarn is just dropped on the floor when the program reaches the final exit(), rather than being unwound in an orderly fashion. (In theory GC may be cleaning this up better, but I'm not sure how we can really know, since valgrind cannot tell us.) Could somebody who understands these parts of Inkscape PLEASE clean up this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will unwind its memory structures before exiting? At the very least we will learn after this unwinding what memory is still left, and that will be the result of existing bugs in the code. Once we obtain a baseline inkscape that is usable once again in valgrind, we can reasonably expect that by using valgrind developers will be able to catch the memory problems they may introduce. Sadly that is far from true now, what with so many thousands of lines of background noise in the log files to slog through. Admittedly some of the lines in valgrind's log file do come from valgrind issues, but the ones I know about can be removed with: cat >wcslen_sse2.supp <<EOD { wcslen1 Memcheck:Addr8 fun:__wcslen_sse2 fun:* } { wcslen2 Memcheck:Cond fun:__wcslen_sse2 fun:* } { iffyinflate Memcheck:Cond fun:inflateReset2 fun:inflateInit2_ obj:* } EOD valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --log-file=/tmp/vgfi.log src/inkscape which improves the output to: --16527-- used_suppression: 208319 wcslen1 --16527-- used_suppression: 142 wcslen2 --16527-- used_suppression: 330 iffyinflate ==16527== ==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed: 208791 from 656) I understand that there may be other problems in some libraries which are called, but from the contents of the log file it looks like the majority of the loose ends were directly created in Inkscape. (And we can use valgrind suppression files, as above, to silence the unfixable library problems.) Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 3

Method to duplicate a SPDocument?
by mathog 01 Jun '14

01 Jun '14

If there is an existing method for making a copy of an SPDocument, what is it called? Resolving bug 1318657, without introducing other problems, seems to require that the clipboard be replicated, and all actions occur on the replica, which is then thrown away. See comments 8 and 9 https://bugs.launchpad.net/inkscape/+bug/1318657 Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 2

Removal of -inkscape-font-specification ?
by Tavmjong Bah 01 Jun '14

01 Jun '14

Hi, I would like to propose the removal of the Inkscape specific -inkscape-font-specification property. This property was added in 2007 in an attempt to allow Inkscape to handle more font faces for a given font family than allowed by CSS.[1] It relied on Pango being changed to support this. In the intervening seven years, Pango has not changed nor does it seem likely it ever will. There doesn't appear to really be a need to expand on what CSS does already (and any SVG files that would use such a feature would not be viewable correctly in browsers). Inkscape (trunk) already supports, for example, all nine font faces of DejaVu Sans. Support for the font-variant features of CSS Fonts Module Level 3[2] would allow access to variants within a single font file which seems to satisfy the need that -inkscape-font-specification was meant to address. Font factories already have moved to put variants inside a single font file (vs. keeping them in separate files). See for example the bug (from 2004) about Adobe Caslon[3] with the long list of variants and the current OTF files from Adobe where the Small Caps, Alternative, and Swash variants are included in the regular files.[4] At the moment, -inkscape-font-specification duplicates the information already stored in other font related properties. There is a cost in this duplication, not only in increased file size but also in code maintenance. Keeping -inkscape-font-specification matching the other font properties is a source of bugs. It is currently making proper quoting of font-family names in font-fallback lists more difficult to fix. The actual changes needed to remove -inkscape-font-specification are straightforward and effect a few lines in about seven or eight files. No functionality would be lost as the property is completely redundant with the other font related properties. Tav [1] https://bugs.launchpad.net/inkscape/+bug/169973 [2] http://www.w3.org/TR/css3-fonts/#font-variant-prop [3] https://bugs.launchpad.net/inkscape/+bug/165521 [4] http://www.myfonts.com/fonts/adobe/caslon/buy.html

2 2

New PreviewHolder and swatches dialog design.
by Tomasz Boczkowski 28 May '14

28 May '14

Hi! I have designed a new class layout for PreviewHolder. It's functionality is illustrated at [1] Because the new widget should support not only rendering paints, but also glyphs and symbols, a flexible architecture is needed. I've choosen MVC approach, heavily based on Qt MV model design [2]. It is shown at [3]. In the upper part of the picture there are generic model and view classes. The lower part shows the application in swatches dialog. Model is organized as a hierarchy of lists. Qt documentation explains similar hierarchy of grids [4]. It enables navigating and iterating through the structure and defined signals when items are inserted, moved or deleted. Model class itself does not contain data (classes that inherit it do) and it's methods do not provide access to data items. Model index is array index generalization for hierarchical structures. PreviewHolder belongs to the "View" part. It is the widget that displays items categories and places the preview tiles. To make things work it needs a model and a means to display (and access) model data. The latter is provided by TileRenderers. TileRenderers can render images associated with model data. When clicked they send signals. How do TileRenderers access to data contained in model, while Model class does not provide access to them? They are all constructed by a TileRendererFactory. Concrete factories find appropriate data items by ModelIndex, and initialize concrete TileRenderers with it. They also bind tile renderer signals upon construction. The example shows the use of PreviewHolder in swatches dialog. Displayed items are paints. They are stored in PaintsModel. This class represents paint servers stored in document and built-in ones. It reacts to changes in document, updates it's entries and sends generic model signals. The model consists of PaintItems, that represent paints servers and provide access to SPPaintServer objects. PaintTileRenderer just fills it's content with pattern. Swatches dialog besides being a dialog, defines a slot that is executed when a tile renderer is clicked. It invokes apropriate SVG tree actions to set current object fill and stroke or execute "paint properties" dialog. TileRenderer can be implemented as plain class or it can inherit Gtk::Widget. The second solution would mean easier support for mouse and D&D events, but I'm not sure if it would affect performance (gobject construction, storing Gdk::Windows, initializing cairo context for each widget in GTK2). We will have several hundreds of those objects. Did you encounter any issues with Gtk performance? Which solution do you recommend? [1] https://www.dropbox.com/s/7nbg1uzk1sal2kn/new_swatches_ui.png [2] http://qt-project.org/doc/qt-4.8/model-view-programming.html [3] https://www.dropbox.com/s/r5ph6tgp5halal6/PreviewHolder.pdf [4] http://qt-project.org/doc/qt-4.8/model-view-programming.html#parents-of-ite… Regards, Tomasz

1 1

New video for the LPE Fillet-Chamfer
by Jabiertxo Arraiza Cenoz 28 May '14

28 May '14

Hi to all. I just release a new video for the LPE Fillet-Chamfer. Now have simplified interface and more features and bugfixes. https://www.youtube.com/watch?v=wJKzGhJULfc Thanks to Nathan, Liam, Josh, SUV, Mc- and all give feedback!

1 0

New LPE, New Video. Fillet/Chamfer
by Jabiertxo Arraiza Cenoz 28 May '14

28 May '14

Hi to all. Here is a video showing my new LPE. The branch is here[1].The video here[2]. Thanks to Josh Andler for give me the idea Also thanks very much to suv for the feedback and time inverted on it. And a special thanks to Liam P. White, without his help the LPE need a lot of hours to be.. or not to be. Bye, Jabiertxo. [1] https://code.launchpad.net/~inktxof/inkscape/fillet-chamfer [2] https://www.youtube.com/watch?v=HdsxhXPksgo

5 17

Change in pixels per inch?
by Tavmjong Bah 27 May '14

27 May '14

Hi TimeWaster and Nick, Alvin Penner has suggested that I contact both of you about a change to Inkscape I am pushing for: Currently Inkscape transforms non-pixel units (e.g 'in', 'cm') using the ratio 90 pixels per inch. This ratio is hinted at in SVG 1.1 but not explicitly defined (someday I'll blog about the history of this). CSS 2.1 does explicitly defined the ratio to be 96 pixels per inch, a standard that all web browsers as well a Batik have followed for many years. I recently proposed that in SVG one should be allowed to set this ratio but that idea was quickly rejected by the standards group. Previous to Inkscape 0.91 all dimensions inside of Inkscape were stored only as pixels values (despite allowing the user to enter dimensions in other units). As long as one did not import SVGs from other sources the ratio between px and in was not all that important. With 0.91, one can optionally set font-size to be output in points. To ensure consistency with what is rendered in Inkscape and what is displayed by other SVG renderers we should move to the standard 96 pixels per inch per CSS2.1. To make the change, two files must be modified: share/extensions/inkex.py share/ui/units.xml and probably the default export resolution should also be changed in preferences. Alvin is afraid this will cause trouble in the world of desktop cutters and plotters. Do you see this as a problem? Thanks, Tav BTW, the 0.91 release notes suggest that extensions relying on units other than pixels were already broken by the work on units.

4 9