- Inkscape Devel - Inkscape Mailman

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