- Inkscape Devel - Inkscape Mailman

cairo 1.4.4 on win32 does not work
by Adib Taraben 20 Apr '07

20 Apr '07

Ishmal, I tried your cairo 1.4.4 that I saw this morning :-) The new libs does not work as expected. (I use your provided libs also in my own application to create some pdf report) I am not shure if this is caused by the optimisations in cairo or by your compilation. However thx. for the win32-libs Hope my report is somehow usefull, Adib. -- In my own application where I use your cairo libs it throws an SIGSEV somewhere on cairo_create(surface). As I use codeblocks as IDE I do not know how to copy a backtrcae from the list. The last entries are ntdll!WaitForCriticalSection, cairo_color_white(), msvrt!free(), ntdll!AppendStringToString(), msvcrt!free() however Inkscape dies as follow 0x7c928fea in ntdll!RtlpWaitForCriticalSection () from ntdll.dll (gdb) bt #0 0x7c928fea in ntdll!RtlpWaitForCriticalSection () from ntdll.dll #1 0x03c0d110 in ?? () #2 0x03c0d110 in ?? () #3 0x03c0d110 in ?? () #4 0x00000004 in ?? () #5 0x627449a3 in _libmsvcrt_a_iname () from D:\projekte\inkscape\inkscape\inkscape\libgobject-2.0-0.dll #6 0x00000000 in ?? () from #7 0x03c25110 in ?? () #8 0x0022e578 in ?? () #9 0x00000000 in ?? () from #10 0x00000000 in ?? () from #11 0x00000000 in ?? () from #12 0x0022e578 in ?? () #13 0x627466f7 in _libmsvcrt_a_iname () from D:\projekte\inkscape\inkscape\inkscape\libgobject-2.0-0.dll #14 0x03c25110 in ?? () #15 0x7c97e0f8 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #16 0xffffffff in ?? () #17 0x7c97e0d4 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #18 0x7c95a5d0 in ntdll!RtlInsertElementGenericTableAvl () from ntdll.dll #19 0x00240000 in ?? () #20 0x50000061 in ?? () ---Type <return> to continue, or q <return> to quit--- #21 0x03be9610 in ?? () #22 0x00240000 in ?? () #23 0x002595c8 in ?? () #24 0x40000060 in ?? () #25 0x00000000 in ?? () from #26 0x0022e5c0 in ?? () #27 0x00000000 in ?? () from #28 0x00000000 in ?? () from #29 0x00000688 in ?? () #30 0x0022e518 in ?? () #31 0x7c91104b in ntdll!RtlEnumerateGenericTableLikeADirectory () from ntdll.dll #32 0x000bc0a0 in ?? () #33 0x010939a3 in _cairo_scaled_font_map_lock () at src/cairo-scaled-font.c:195 Previous frame inner to this frame (corrupt stack?) (gdb)

2 4

Build failures on OS X 10.3.9: isnan, isinf, etc.
by John Faith 19 Apr '07

19 Apr '07

Hello, I've been looking at building source from SVN on OS X 10.3.9 and I've found these problems: - configure.ac uses g++ instead of gcc when testing for -Wno-pointer-sign support (ignoring $CFLAGS) and gcc3 dies in libcroco. Already reported by jiho. - isnan undeclared in src/libcola/cola.cpp. I worked around this by changing "isnan" to "isNaN" since the latter is defined in isnan.h, though I'm not sure this makes sense for all platforms. - libcola/gradient_projection.cpp:54 isinf undefined. Adding '#include <math.h>' fixes this. There are several issues for isnan already in the tracker, so my question is: are these new problems (requiring new bugs created), or the same as earlier bugs? - Although configure apparently finds msgfmt, In po/Makefile, both $MSGFMT and $GMSGFMT are empty. When make hits the '.po.gmo:' target, it complains "-o: command not found" since part of the command is "$(GMSGFMT) -o $$file $<". Has anyone run into this? Thanks!, John

3 2

Problems with new axonometric grid?
by Maximilian Albert 19 Apr '07

19 Apr '07

Hi Johan and everyone, first of all thanks a lot for your work on the grids!! Today I wanted to give the new functionality a try and was a bit stuck, however. Maybe this should go to the bug tracker directly but what I experienced seemed so weird that I thought I'd ask for other people's experience first, since I reckon that Johan would have realized if he had encountered this behaviour, too. Maybe I got something completely wrong, although I don't see what this should be. The rectangular grid works like a charm. But when I create an axonometric grid instead, I cannot get the pen tool, say, to snap to any of the intersections of the grid lines. Instead, it snaps to seemingly random points in between. Also, with "always snap" enabled, the mouse pointer doesn't cleanly jump from one intersection point to the next but shows a kind of "juddering" behaviour, as if it was snapping to some invisible (smaller) grid that's not precisely aligned with the visible one. When "always snap" is unchecked and very small sensitivities are chosen, it seems to work better, but the precise snapping points are still missed to a certain extent. Furthermore, when assigning a different color to the major grid lines, they are not drawn as continuous lines but only segment-wise and at irregular distances. To me it looks as if the regular grid lines were repainted with the new color, but since both lines are located at the same positions, sometimes one color dominates and sometimes the other. (This may also explain why the segments seem to change when zooming out.) Has anyone else seen this or is it just me? Does this work correctly for you, Johan? I was experimenting with the latest svn version (revision #14815), but this seems to occur with older (yet recent) versions, too. Please tell me if you want me to add this to the bug tracker. Thanks for your help! Cheers, Max P.S.: Wouldn't it make sense to have different colors for regular and major grid lines by default? And IMHO the default spacing for the axonometric grid should be larger than 1.

5 7

Kind reminder from your dedicated LGM organisation !!!
by Louis Desjardins 19 Apr '07

19 Apr '07

Hello all LGM participants and speakers, If you haven't done so yet, please, please take a few secs to register for LGM at http://www.libregraphicsmeeting.org/signup.html This is the best way to help me in the late stages of this big organisation, make sure we have enough food and drink, make sure we can accommodate everyone, etc. Many thanks in advance and looking forward to welcome you in Montréal! Louis p.s. Please forward this message to any list you might think it be important to send it. -- Louis Desjardins Organisateur / Organiser Libre Graphics Meeting 2007 - Montréal www.libregraphicsmeeting.org/fr www.libregraphicsmeeting.org +1 514 934 1353 HAE / EDT GMT -4

1 0

HIG-style frames
by Murray Cumming 19 Apr '07

19 Apr '07

I tried to patch Inkscape to make it use GNOME HIG-style frames [1] for consistency with the rest of GNOME and general attractiveness. For some odd reason I couldn't get it to show any difference. It's in the (awful) sourceforge bug tracker if someone would like to take a look: https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1677542&group_… [1] http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-fram… -- Murray Cumming murrayc@...799... www.murrayc.com www.openismus.com

2 1

NEW: paint bucket fill along dragged path
by John Bintz 19 Apr '07

19 Apr '07

bulia's new "touch selection" and improvements to the Rubberband object have given me what I've needed to properly implement a feature he and I talked about a while back: dragging the cursor while using Paint Bucket now performs the fill operation from all points along the drag path. Just like touch selection, you have to hold [ Alt ] to get this feature; otherwise it works as before, where a single click fills from the one click point. The color used for the drag fill algorithm is the color at the initial click point. This becomes very useful if you have a series of similarly-colored yet separated areas (Ex: inked fingers on a relaxed hand). Normally, to fill this object, you'd have to click once in each of these areas (fingers, thumb, hand) with the same fill color. Now, click and hold [ Alt ] in one of the areas, drag the cursor through the other areas, release the cursor, and all of the areas you've touched are filled. One possible addition to this would be an additional modifier to change the behavior of the fill color selection. Instead of the initial click point, each point along the drag would define the fill color. This way, you could drag from one end of a gradient to the other end and, with a low Threshold, fill the gradient. This would require a little reworking to the fill algorithm, but if there's interest, I'll add it. John

3 3

RFE [ 1700987 ] Window title should contain file name instead of full path
by Jon A. Cruz 18 Apr '07

18 Apr '07

What do people think of RFE [ 1700987 ] Window title should contain file name instead of full path? It seems reasonable to me, and should be fairly simple to implement. Comments? Opinions?

7 13

Plug-In or Extension System???
by Redefined Horizons 18 Apr '07

18 Apr '07

I was bugging the lib2geom folks a few months back when I had to get pulled away on another project of mine. That project has finished and I thought I'd see about helping just a little bit with Inkscape development. I have posted a message on the lib2geom Jabber conference room. I also thought I would find out if Inkscape had a plug-in or extension system just yet. If it did I thought I might take a stab at making small improvements to the program. I'm not an experienced C++ developer and I'm a little scared about trying to build Inkscape. Is there an extension or plug-in system in place? Or will I need to build Inkscape to test any changes I might make? I took a look at the road map and found these items interesting: Revisit coordinate system (move away from Cartesian) Tech Drawing Abilities DXF Import/Export Thanks for the help. I hope I can make time to tinker with Inkscape or lib2geom and improve my C++ skills as I work. Landon

5 13

Lib bundle
by Bob Jamison 17 Apr '07

17 Apr '07

Hi again, I checked the lib bundle that I uploaded last, and yes it does have the defect that Bill mentioned. So I uploaded another bundle here: http://inkscape.modevia.com/win32libs/gtk210-070417.7z It should produce Inkscape builds without the icon artifacts. There will be another build uploaded in a few minutes. bob

1 0

Re: [Inkscape-devel] LPE diff
by Johan Engelen 17 Apr '07

17 Apr '07

Hey Aaron, Thanks a lot for the links to the mail discussion. Very very helpful! I think you won't mind me throwing this on the devel maillist? >From what I gather from the discussion, no consensus was reached on the SVG representation. Perhaps it is best, like Bulia said, to first make it working the 'ugly' simple way, <path original-d= ... d = ... path-effect="sample" path-effect-param1="0.0" path-effect-param2="0.0" path-effect-param3="0.0" path-effect-param4="0.0" /> Then we can see what needs to be improved, what UI needs there are etc. Does that make sense? Once I have this working, we can discuss how to make a more versatile SVG representation. I want to make skeletal strokes first, because it also probes for on-canvas UI needs (on-canvas parameter editing). <path original-d="..." (input curve) d = "..." (result curve) path-effect="skeletal_strokes" (how are we going to name the effects?) path-effect-param1="..." (input curve) /> Cheers, Johan On Sun, 2007-04-15 at 22:13 -0500, Aaron Spike wrote: > I'm already sick of typing Live Path Effects over and over so I'm > abbreviating. :-) > > I believe we can harvest a diff of my changes on the branch with a > command like: > > svn diff > --new=https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/live-effects@...1724... > --old=https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk@...1725... > > Now this takes a long time to execute and I haven't stuck it out all the > way yet. I'll try to remember to leave it running when I go to work > tomorrow. The idea is to diff the current head of the branch with the > last revision merged in from trunk. I think reading this diff will give > you a pretty good idea of what has been done so far. > > Aaron Spike

8 9