- Inkscape Devel - Inkscape Mailman

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

Win64: feature complete
by Johan Engelen 03 Jun '14

03 Jun '14

Hi all, A quick note to let you know that aspell is now added to devlibs64, so that the 64bit version of Inkscape on Windows is now feature complete (i.e. same features as 32bit version) Jay! Johan

3 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

Re: [Inkscape-devel] Widget c++-sification
by Tomasz Boczkowski 25 May '14

25 May '14

Resending: original message was send accidentally off-list. >> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to keep a proper logical separation between Gtkmm UI objects and the functionality they trigger or state they manifest. The bulk of code ends up in plain C++ classes, while the Gtkmm widgets merely provide a thin layer to expose >> in the 'proper' manner. That might including moving certain functionality out of the widget classes themselves. I see your point. Could you please name some inkscape UI classes that preserve the separation? I would like to go on with SPColorSelector refactoring. In Inkscape color can be selected using one of two widgets: sp-color-wheel-selector, sp-color-icc-selector. They share common functionality in sp-color-selector. Currently there are six structures consisting of both Gobjects and c++ classes. I made a simplified diagram, listing possible options for refactoring [1]. 1) ColorSelector widgets contain a reference to their state (ColorSelector). It is accessible via getColorSelector() method. Optional ColorSelectorWidget abstract class provides the method. Parent UI component would initialize color selector widgets in ctor. Reference to widget would be kept in ctor only. Parent class would contain a pointer to widget state, returned by getColorSelector(). 2) Double inheritance. ColorSelector provides widget state. Concrete implementations inherit ColorSelector and aproppriate Gtk::Widget. 3) Full wrapper. Color selector widgets contain reference to their state and have full set of thin wrapper methods. They only call corresponding methods in ColorSelector. Which is the best? What is the suggested naming and namespacing of mentioned classes? Which of the options fits the separation between gtkmm and functionality best? [1] https://www.dropbox.com/s/nvie03p9ee9r8ry/colorSelector.pdf Regards, Tomasz On Sat, May 24, 2014 at 12:41 PM, Tomasz Boczkowski <penginsbacon@...400...>wrote: > >> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to > keep a proper logical separation between Gtkmm UI objects and the > functionality they trigger or state they manifest. The bulk of code ends up > in plain C++ classes, while the Gtkmm widgets merely provide a thin layer > to expose > > >> in the 'proper' manner. That might including moving certain > functionality out of the widget classes themselves. > > I see your point. Could you please name some inkscape UI classes that > preserve the separation? > > I would like to go on with SPColorSelector refactoring. In Inkscape color > can be selected using one of two widgets: sp-color-wheel-selector, > sp-color-icc-selector. They share common functionality in > sp-color-selector. Currently there are six structures consisting of both > Gobjects and c++ classes. > > I made a simplified diagram, listing possible options for refactoring [1]. > 1) ColorSelector widgets contain a reference to their state > (ColorSelector). It is accessible via getColorSelector() method. Optional > ColorSelectorWidget abstract class provides the method. Parent UI > component would initialize color selector widgets in ctor. Reference to > widget would be kept in ctor only. Parent class would contain a pointer to > widget state, returned by getColorSelector(). > 2) Double inheritance. ColorSelector provides widget state. Concrete > implementations inherit ColorSelector and aproppriate Gtk::Widget. > 3) Full wrapper. Color selector widgets contain reference to their state > and have full set of thin wrapper methods. They only call corresponding > methods in ColorSelector. > > Which is the best? What is the suggested naming and namespacing of > mentioned classes? > Which of the options fits the separation between gtkmm and functionality > best? > > [1] https://www.dropbox.com/s/nvie03p9ee9r8ry/colorSelector.pdf > > > > On Wed, May 21, 2014 at 8:21 PM, Jon A. Cruz <jon@...18...> wrote: > >> On Wed, May 21, 2014, at 10:31 AM, Tomasz Boczkowski wrote: >> >> Thank you for the answer. >> >> >>Also, take care on what widgets you are looking at. We have a few >> groupings in our source tree that are meant to stay C. >> >> I started with src/widgets/sp-color-slider. I plan to continue with >> widgets related to fill and stroke dialog (sp-color-notebook, >> sp-color-scales, sp-color-wheel-selector etc.). Are they safe to port? >> >> >> >> Those should be OK... but in the 'proper' manner. That might including >> moving certain functionality out of the widget classes themselves. >> *Additionally* those I recognize as some of the first files I poked at when >> I initially joined Inkscape (before the project had its name). They're >> probably quite outdated by this point. >> >> Then also keep in mind that "sp" stands for Sodipodi, so when you move >> files you can drop such. Just be sure to do it in a source-control friendly >> way that won't break history. :-) >> >> >> >> >>>> 4) Should child widgets be stored as pointers as in glyph.h or >> directly as in text-edit.h? >> >> Which file are you referencing as "glyph.h"? >> >> src/ui/dialog/glyphs.h >> >> >> Ahh, that's an interesting question. >> >> For widgets, the design and intent of Gtkmm is to place children via new >> + Gtk::manage(). That ensures consistent object lifetimes and helps reduce >> memory leaks. For even stronger encapsulation often it's better to not list >> pointers as members in the public .h file, but keep them all to setup in >> the constructor. Since you won't have to delete them, you don't have to >> track them... for those cases where you set up events and handlers then add >> the child. That also goes on to event driven programming, and fewer bugs >> once you wrap your head around it. >> >> -- >> Jon A. Cruz >> jon@...18... >> >> >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. >> Get unparalleled scalability from the best Selenium testing platform >> available >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> >> >

2 2

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

21 May '14

Hi Nathan, i have problems whith my mail and get your reply searching by web the mailing list. Thanks very much for your help! Regards, Jabier. ################################################################ Hi Jabiertxo, There are various functions for this, the technical term is 'arc length', you can either compute a specific curves' total arc length (length), get an sbasis which maps time to arc length(arcLengthSb), or you can reparameterise a curve by arc length (arc_length_parameterization). There was an inverse arc length to time function somewhere too, but I can't remember what it's called. I think the easiest way to get what you want is roots(arcLengthSb(B) - desiredLength) which will return all the positions on B that are desiredLength from the start. njh On Mon, May 19, 2014 at 08:59:19PM +0200, Jabiertxo Arraiza Cenoz wrote: > Hello again. > Thanks to LiamW i undertand the time in bezier curves is influenced by > his curvature. Now i have a problem i want to select a time value at > specific distance. Is posibol actualy? > > Thanks, Jabier.

1 0

Widget c++-sification
by Tomasz Boczkowski 21 May '14

21 May '14

Hi! I started porting inkscape widgets to gtkmm and c++ and have a few questions: 1) There are two directories src/widgets and src/ui/widget. Is the former deprecated? 2) Should I move classes to src/ui/widget after c++-sification? 3) What is the proper macro to differentiate between gtk versions? GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0? Regards, Tomek

3 8

Windows 64-bit build
by Johan Engelen 20 May '14

20 May '14

Hi all, With Partha's and Liam's help, we seem to be able to build for 64-bit Windows now. Some dependencies are missing, but it is a good start. For more details, please see http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_64-bit All help is appreciated! (I do not know about the consequences for release. It'd be nice if we can release with a w64 version too, but I do not know about potential bugs with newer dependency versions. If anything, dragging the canvas seems quite a bit faster on my machine with the 64bit version) cheers, Johan

6 16

0.48.3.1 and 0.48.4 on Ubuntu 12.04 - Node Sculpting Problem
by clarkk 19 May '14

19 May '14

I hope someone can offer me some help. Please let me know if I haven't reported this in the right way or have omitted any info. Thanks in advance! My problem is that I am unable to sculpt text when using the node tool, as described at http://wiki.inkscape.org/wiki/index.php/Release_notes/0.44#Node_sculpting, and demonstrated in this video tutorial, http://youtu.be/_qqTAjBaeJ0?t=8m20s. These are the steps I take: 1) Create text with text tool 2) Node Tool 3) Select Text 4) Convert Object to Path 5) Select each path (each letter) - Note: the tutorial above shows that a selection box may be used to select all the paths at once, but this doesn't work for me. Hence, to work around this, I've selected each letter while the Shift key is held. Reasons for this would be welcome also! 6) CTRL+A (to select all nodes in selected path) 7) ALT+drag node - this MOVES all nodes together rather than sculpts them as described in the manual This is a video I made of the above process: https://dl.dropboxusercontent.com/u/14392713/temp/inkscape-sculpt-problem4.m kv I've also worked with a friend using Windows 7, where we have both done the same steps simultaneously. Hers works correctly (except the note mentioned in step 5) and mine does not. Any help would be very much appreciated! Environment: Ubuntu 12.04.4 (as per /etc/issue) Inkscape 0.48.4 (see my video below - installed from trunk ppa), but also tested in 0.48.3.1 (from Canonical repo) Default preferences (~/.config/inkscape deleted) System Alt key swapped with Win key (as per http://askubuntu.com/questions/118151/how-do-i-disable-window-move-with-alt- left-mouse-button-in-gnome-shell#272317)

2 1

Can't compile for Windows x64 (with btool)
by Liam White 18 May '14

18 May '14

Googled this issue, tried all the recommended solutions, and I found nothing helpful. When I run this command, btool -file build-x64.xml Everything compiles correctly, but the linker completely fails to find all external libraries: Make error line 459: LINK problem: c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lMagick++-6.Q16 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lMagickCore-6.Q16 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lMagickWand-6.Q16 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -latk-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -latkmm-1.6 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcairo c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcairomm-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcdr-0.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lexif c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfontconfig c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfreetype c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgc c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdk-win32-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdk_pixbuf-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdkmm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgio-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgiomm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglib-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglibmm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgobject-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgsl c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgslcblas c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgthread-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgtk-win32-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgtkmm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lintl c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ljpeg c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -llcms2 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpango-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangocairo-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangoft2-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangomm-1.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangowin32-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpng c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpoppler c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpoppler-glib c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpopt c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lsigc-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ltiff c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lvisio-0.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwpd-0.9 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwpd-stream-0.9 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwpg-0.2 The thought occurred to me that the issue might also affect the regular 32-bit builds as well. It didn't. They still compile fine. Johan, Partha, help!

3 4

Setting up a relative link
by john Culleton 18 May '14

18 May '14

I want to set up a relative link within a svg-based website. Here is the code I have now: <a xlink:href="http://../WEB00.svg" id="a3040"> <rect y="839.75012" x="257.37564" height="91.428574" width="282.85715" id="rect3009" style="fill:#ffff00;fill-opacity:1" /> </a> However my browsers (Seamonkey, Firefox, konqueror) can't follow the link. I could use a non-relative link of course but that would mean loading the pages to my website or else moving them to my /var/www/htdocs file. So a relative link would be a great convenience. Can anyone spot the error in my code above? -- 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

Idea: merge Inset, Outset, Dynamic Offset, Linked Offset
by Krzysztof Kosiński 18 May '14

18 May '14

Currently there are four offset-related items in the menu, but we actually need only one, Dynamic Offset. It could be renamed to Offset or Offset Path. The current Inset and Outset items are practically useless, because they use a fixed, non-configurable width (or it's hidden somewhere in the prefs). Linked Offset is redundant, because this action could be represented by using Dynamic Offset on a clone. What do you think? Regards, Krzysztof

6 8

Windows: why do we build with -O2?
by Johan Engelen 18 May '14

18 May '14

Hi all, Why do we build with -O2 instead of O3? We are missing out on: -O3: Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize, -ftree-slp-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options. regards, Johan

6 8

Render Barcode extension problems
by Krzysztof Kosiński 18 May '14

18 May '14

The "Render Barcode" extension seems to have some problems: 1. The font for the numbers is specified as "sans-serif", rather than being a specific monospace font such as Courier. The extension should either check the system for a few fonts and use a suitable one, or use fixed paths. 2. The numbers are laid out using spaces instead of the "dx" attribute (kerning), so the spacing is more font-dependent than it should. 3. The layout of numbers looks nothing like the example in Wikipedia, and the quiet zone mark ">" on the right is missing. Regards, Krzysztof

5 9

Inkscape doesn't apply a changed display profile
by Tobias Ellinghaus 17 May '14

17 May '14

Hello, after annoying su_v with this for a while in IRC I'm taking this to the list now and hope that someone here can have a look -- otherwise I will try to file it in launchpad. The bug (?) I see is that Inkscape fails to apply a changed display color profile. More precisely, when I tick "Retrieve profile from display" in the settings Inkscape correctly gets whatever I set in the X atom. When I change the assigned profile while Inkscape is running it doesn't change the used profile though. After digging into the code a bit I found that src/ege-color-prof-tracker.cpp correctly notices that the profile was changed in handle_property_change(), it manages to extract the correct data and calls set_profile(). Afterwards fire() is called and the innermost if() is also reached, resulting in the g_signal_emit() being executed. This looks all fine and dandy. However, there is no further reaction I could see. I didn't try to understand what signal exactly was emitted there and what pieces of code connected to that, so I can't tell if the signal isn't caught by anyone, or if the subsequent code is buggy. All I could notice is that the newly found profile is not used. The easiest way to test this is using a regular sRGB profile and one of those profiles that swap color channels (BRG.icc or the like). I would expect that changing the display profile makes a noticeable difference then. I hope that it's just a small fix and that it can be taken care of for the upcoming release. Thanks for your attention, and thanks for Inkscape. Tobias

1 0

Re: [Inkscape-devel] Rejuvenated build system for Mac OS X
by su_v 16 May '14

16 May '14

On 2014-05-06 11:49 +0100, Partha Bagchi wrote: > Yes, my builds open PDF files and I saw this Debian bug report where > someone claimed that Inkscape uses gs instead of pstoedit: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366797 That bug report was originally filed against older versions of inkscape (0.43-0.46). With the release of Inkscape 0.47 on 2009-11-24, PS/EPS import was switched from pstoedit to ps2pdf (from Ghostscript): <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#PostScript_and_E…> <http://tavmjong.free.fr/INKSCAPE/MANUAL/html/File-Import.html> pstoedit [1] (used in older Inkscape versions for PS/EPS import) is a different application than ps2pdf [2] (used by current Inkscape stable and trunk [3]). 'ps2pdf' is part of Ghostscript i.e. it is one of the many separate command line tools installed by Ghostscript. [1] pstoedit: <http://www.pstoedit.net/> [2] ps2pdf (Ghostscript): <http://www.ghostscript.com/> <http://www.ghostscript.com/doc/9.10/Ps2pdf.htm> [3] (e)ps_input: <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/e…> <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/e…> <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/e…> > On Mon, May 5, 2014 at 10:01 PM, su_v <suv-sf@...58...> wrote: > >> On 2014-05-06 03:38 +0100, Partha Bagchi wrote: >>> On Mon, May 5, 2014 at 8:40 PM, su_v <suv-sf@...58...> >> wrote: >> >>>>> and I was not able to open EPS files (got a parsing error with >>>>> "expecting "<" ...). >>>> >>>> Since you don't share details about how your app was created (I assume >>>> you used custom packaging routines, too, besides your own build env for >>>> the dependencies), I can only guess what the underlying issue might be: >>>> >>>> I build all gtk/glib dependencies from scratch, everything I need for >> Gimp >>> (you can check out my Gimp builds on my website). >>> >>> I downloaded your branch and built the Inkscape App using the same >>> structure as my Gimp builds. The Inkscape App like my Gimp builds is self >>> contained and does not rely on the User for any dylibs. >>> >>>> 1) Is your Inkscape.app (Inkscape-0.48-dev) able to open PDF files? >>>> (these kind of parser errors are known from contexts where PDF >>>> support in Inkscape is broken - e.g. because poppler was configured >>>> without xpdf headers, or not built in at all). >>>> >>> See above. My builds have poppler configured with xpdf headers and >>> associated dependencies included. My Gimp builds open PDF/EPS/PS just >> fine. >>> :) I'll be happy to share my Inkscape build with you (or anyone) if >> needed. >> >> So your Inkscape.app build does open PDF files or not? Please note that >> GIMP's PostScript import feature is different from Inkscape. >> >>>> (If poppler support was not properly compiled in, >>>> 'org.inkscape.input.pdf' might be a logged missing dependency for input >>>> formats like PS and EPS (see 'extension-errors.log' in the inkscape user >>>> profile dir used by Inkscape.app - the exact location depends on whether >>>> you used the launcher script of the 'osxmenu' branch, or your own)). >>>> >>>> 2) Did you verify that the bundled ps2pdf and GhostScript (I assume you >>>> included it in the app bundle, since it is a required helper app for >>>> PostScript input in Inkscape) works as expected? >>>> >>> I was going to build ps2pdf till I saw the bugreport where you said that >>> one does not need it anymore. Gimp does not need ps2pdf to open EPS files >>> (or Ghostscript for that matter). Just the dylib. I'll build ps2pdf and >>> recheck this. >> >> Which bug report for inkscape - do you have a link? I can't imagine that >> I said that Inkscape no longer needs ps2pdf for EPS/PS import (it still >> does). >> >> In Inkscape, PS/EPS import works in two steps: >> 1) the PostScript file is converted to a PDF file with ps2pdf from >> Ghostscript (needs to be in $PATH). >> 2) the just created PDF file is imported in Inkscape using built-in >> (poppler-based) routines. >>

2 1

Windows devs: IMPORTANT, buildtool improvement
by Johan Engelen 15 May '14

15 May '14

Hi all, If you bzr up, you have to rebuild buildtool. I added a cxxflags attribute, so we no longer get warnings about C++ flags that are not applicable to C compilation. This is cmd you need: g++ buildtool.cpp -o btool.exe -O3 -fopenmp regards, Johan

1 0

Careful with merging!
by Johan Engelen 15 May '14

15 May '14

Hi all, Look here: http://bazaar.launchpad.net/~inkscape.dev/inkscape/experimental/changes rev 13365 <http://bazaar.launchpad.net/%7Einkscape.dev/inkscape/experimental/revision/…> managed to 'rename' my earlier commit to include poppler in win64 build. My recommendation to not waste too many brain cycles: don't merge. You can create you own branch, fine, just don't merge it in. Just create a separate trunk/experimental checkout and copy your changes in, then commit. Whatever you think about better workflows, it is paramount to maintain a clean version history. And again and again, we have proven that we are not capable of maintaining a clean history by using bzr merge. Thanks, Johan

4 5

[win32] really long initial startup times on Windows 7/8
by Liam White 15 May '14

15 May '14

This one almost certainly has to be fixed before we release. To be quite honest, I am unsure of the cause. I did test this out on Windows XP and it worked perfectly well. I compiled on a Windows 8.1 x64 machine, and launched it on a Windows 7 machine. The console window appeared, as normal, but I wondered why it didn't go away. Interested, I launched it with not gdb, as would be recommended, but instead with Visual Studio (as it would have symbols for all of the Windows libraries). The long startup didn't cause any sort of trap, but the preferences.xml I had did. (the trap seems to happen when you launch with default prefs, iconify the Fill and Stroke dialog, close it normally, and restart it with gdb: https://bugs.launchpad.net/inkscape/+bug/1317700) After I had stepped through every single one of the several hundred breakpoints, I could not find the issue (although mainly because the Microsoft devs refuse on releasing the details to their PDB format, and do not seem to support DWARF debug symbols in their debuggers). I am unable to reproduce the exceptionally long startup time issue, as it went away immediately after the first startup. Possibly a registry key was set. However, the traps are a persistent issue and make my loading time about five seconds longer. What I am envisioning right now is thousands of people downloading the update, launching Inkscape, and not seeing anything at all (compiled with -mwindows), despite the process showing in Task Manager and consuming many resources. We have also had at least one complaint about this before. (If I could put a bounty on this bug, I would!) What is this madness?

5 6

Setting up sub-projects for Inkscape
by Bryce Harrington 14 May '14

14 May '14

The question has come up a couple times now, so figured a definitive official answer might help, while the steps are still fresh on my mind. tldr: Contact one of the admins for help (see https://launchpad.net/~inkscape.admin/+members) Anyone can set up an independent project in Launchpad, unassociated with Inkscape. Anyone can also create their own Inkscape branch, unofficially associated with Inkscape, ala lp:~bryce/inkscape/my-stuff. But what about making separate projects that are *associated* with inkscape? And what about making official branches associated with inkscape that other devs can contribute to? Official Team Branches ====================== If you're a member of the inkscape-dev team, you can also upload official branches by doing: bzr push lp:~inkscape.dev/inkscape/branch-name A full list of all branches associated with Inkscape can be seen here: https://code.launchpad.net/inkscape (Please delete branches when you no longer need them, to cut down on clutter!) Setting up Sub-Projects ======================= But what if you want a distinct project from inkscape, but want to enable your fellow inkscape developers to work on it? To enable others in inkscape.dev to commit, first you upload the branch as you would an official inkscape branch. I.e.: bzr push lp:~inkscape.dev/my-project-name/branch-name Then under the Code tab of your project in Launchpad, click 'Configure code hosting' and specify this branch name for "Link to a Bazaar branch already on Launchpad". Optionally, you can also change the Maintainer for your project to 'inkscape.admin'. Note that you lose some ability to configure the project once you do this, so only change it if you really want to turn over administration to the inkscape admins. Launchpad permits establishing groupings of projects under an umbrella project. All the sub-projects would share certain settings. Presently we don't have a project group for inkscape, but I think we've accumulated enough projects that it's time to set one up. Once this is done, to add another project to the Inkscape project group you'd go to your project's configuration page and under "Part of" hit the Choose button and type 'inkscape', and then select the inkscape group project. On Tue, May 13, 2014 at 11:10:55PM +0200, Johan Engelen wrote: > On 13-5-2014 23:05, Vinícius dos Santos Oliveira wrote: > >Em Ter, 2014-05-13 às 21:14 +0200, Johan Engelen escreveu: > >>Please apply the attached patch to the libdepixelize repo > > > >Done (r187). > > > >>(inkscape dev's have no access). > > > >This is a mistake. > > > >How do I transfer a repo to the Inkscape organization? > > > >I remember Jabier had to create another org just to give commit > >access to other Inkscape developers. > > I don't know. > Perhaps you can add people with commit rights. The one you want to > add is "inkscape.dev", which is the team of all people with commit > access to Inkscape trunk. > > regards, > Johan > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0