This is an upstream issue, which was fixed in sigc++ 2.2.9. [1,2] The ideal solution is to bump our dependency, but I guess in practice we need to hack it. As long as <cstddef> is always included before using <sigc++/*.h> then we should be OK. AV [1] http://git.gnome.org/browse/libsigc++2/commit/?id=faabe1f90c142a5ea836884... [2] http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.2/libsigc++-2.2.9.news On 15 February 2012 21:23, Kris De Gussem <kris.degussem@...400...> wrote:

I'm not sure this is correct, but here is what I need to have Inkscape run on my Windows XP: - copy the right libintl DLL (Inkscape trunk); - fix the gtkrc for Windows to have rightly sized icons on the toolbar (devlibs). http://inkscape.13.n6.nabble.com/file/n4487355/libintl.patch libintl.patch http://inkscape.13.n6.nabble.com/file/n4487355/MSWindowsgtkrc.patch MSWindowsgtkrc.patch Luca -- View this message in context: http://inkscape.13.n6.nabble.com/Windows-build-issues-tp4473990p4487355.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2012/2/20 alvinpenner <penner@...1856...>: I fixed the missing library copy in revision 11005. Regards, Krzysztof

On Jun 20, 2012, at 8:40 AM, LucaDC wrote: That comes from the .cpp file not including <glibmm/i18n.h> Try just adding that to files that have the '_' symbol problem. In general we want to get accidental side-effects out of our headers and trim them down. Aside from other things, it improves compilation times and makes our usage a little more explicit.

Compilation ok. Thanks. Luca -- View this message in context: http://inkscape.13.n6.nabble.com/Windows-build-issues-tp4473990p4964849.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

[With the dev list] Hi, As you can see, Inkscape is storing pies and arcs as Arcs because in fact there are small differences : one is open (arc, you can see this as a line, an open shape) and the other closed (pie, you can see it as a surface). This is an answer for sodipodi:open. The default value must be "false" and this why it's not used for the Pie. Having FALSE or TRUE is a way to know whether it's a pie or an Arc. About CX and CY : the center of your ellipse (you can see a pie or an arc as a piece of an ellipse...). About RX and RY : the radius, because this "ellipse" can be regular (a circle) or flatten (an... ellipse !). Those values are used to render the arc/pie andfor User Interface purposes (to drag and drop control points for exemple). In plain SVG, you may not have used of those values, so they are not stored and it's simply a Bezier curve whithout knowing it's a pie/an arc. *Romain de Bossoreille* Le 19/07/2012 20:31, mathog a écrit :

Hi! I'm not able to check the source code whether it contains a solution to your question, but you may have a look at http://code.google.com/p/svg2emf/ Conversion works, but unfortunately converts text to pathes. Wilfried mathog <mathog@...1176...> wrote: -- Wilfried Hennings

On 14-Aug-2012 16:02, mathog wrote: The functions for this are in bezmisc.py, of course, otherwise convert2dashes.py wouldn't work. I can translate the Python to C++, but suspect these same functions may already exist elsewhere in the code, and it would be silly to reinvent (retranslate) that wheel. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 17-Aug-2012 17:01, mathog wrote: Strangely, the "fix" seems to have been logging out and back in again. The same code (not even a recompile) magically started working with the heap problem eliminated. Hopefully whatever gremlin this was has been permanently cast out of the system! That said, I would still like to know if there is a way to trace the heap. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

I have a couple of questions related to SVG patterns. First some background. After a bit of experimenting I came up with the following patterns to match the standard hatch patterns available in the EMF file type. Notice that the stroke color is hard coded. The translate 6 lines are needed to prevent visible discontinuities in the pattern for diagonal lines. (Not needed for the diagonal cross hatch because the perpendicular lines fill in each other's discontinuities.) <pattern id="EMFhatch0" patternUnits="userSpaceOnUse" width="6" height="6" x="0" y="0" <path d="M 0 0 6 0" style="fill:none;stroke:black" /> </pattern> <pattern id="EMFhatch1" patternUnits="userSpaceOnUse" width="6" height="6" x="0" y="0" <path d="M 0 0 0 6" style="fill:none;stroke:black" /> </pattern> <pattern id="EMFhatch2" patternUnits="userSpaceOnUse" width="6" height="6" x="0" y="0" viewBox="0 0 6 6" preserveAspectRatio="none" <line x1="-1" y1="-1" x2="7" y2="7" stroke="black" id="subEMFhatch2"/> <use xlink:href="#subEMFhatch2" transform="translate(6,0)"/> <use xlink:href="#subEMFhatch2" transform="translate(-6,0)"/> </pattern> <pattern id="EMFhatch3" patternUnits="userSpaceOnUse" width="6" height="6" x="0" y="0" viewBox="0 0 6 6" preserveAspectRatio="none" <line x1="-1" y1="7" x2="7" y2="-1" stroke="black" id="subEMFhatch3"/> <use xlink:href="#subEMFhatch3" transform="translate(6,0)"/> <use xlink:href="#subEMFhatch3" transform="translate(-6,0)"/> </pattern> <pattern id="EMFhatch4" patternUnits="userSpaceOnUse" width="6" height="6" x="0" y="0" <path d="M 0 0 6 0 M 0 0 0 6" style="fill:none;stroke:black" /> </pattern> <pattern id="EMFhatch5" patternUnits="userSpaceOnUse" width="6" height="6" x="0" y="0" viewBox="0 0 6 6" preserveAspectRatio="none" <use xlink:href="#subEMFhatch2" transform="translate(0,0)"/> <use xlink:href="#subEMFhatch3" transform="translate(0,0)"/> </pattern> Questions: 1. Is it possible to inherit or reference the stroke color in the pattern? For instance, this fills a square with the first EMF hatch pattern (horizontal lines): <path style="fill:url(#EMFhatch0); fill-rule:evenodd;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:8;stroke-dasharray:none;stroke-opacity:1;" d=" M 149.99595 262.49292 L 172.49535 262.49292 L 172.49535 284.99231 L 149.99595 284.99231 z " /> Stroke in the path style is for the line bounding the square, so it isn't available for the fill to reuse. The "fill" value is used to reference the pattern, so it isn't available either. It would be nice to be able to specify a color other than black for the pattern, other than by having to create a second pattern which differs only in its stroke value. In general SVG allows inheritance, but here the obvious routes are blocked. If this isn't possible I guess it will come down to naming the patterns like "EMFhatch0_FF0000", with the color appended to the name. (This is in order to avoid having multiple defines with different names for the exact same pattern.) 2. Because of the free form way patterns are defined it looks really, really hard to map arbitrary user defined patterns onto the standard set of EMF hatch patterns (or CGM, or any other graphics standard that has a predefined set). Is there anything in inkscape presently along these lines (pseudocode): pattern[i].has_horizontal_lines(); // pattern has horizontal line elements pattern[i].has_vertical_lines[]; pattern[i].has_diagonal_lines[]; pattern[i].has_antidiagonal_lines[]; ? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

Sorry to be dense but I still have not found an easy way to locate this sort of information, and I end up wandering around in circles every time I venture into the source code looking for it. There are three kinds of fills that have to go through a print method: paint, pattern, and image. The first is already handled and can be detected with isColor(). The information needed for the other two are somewhere a hop skip and a jump down from "style". In the svg these are in <defs> like this: <pattern y="0" x="0" height="6" width="6" patternUnits="userSpaceOnUse" id="EMFhatch0_3F7FFF"> <path id="path3933" style="fill:none;stroke:#3F7FFF" d="M 0 0 6 0" /> </pattern> and <pattern height="4" width="4" y="0" x="0" patternUnits="userSpaceOnUse" id="EMFimage1"> <image id="image3992" height="4" width="4" y="0" x="0" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAIAAAAmkwkpAAAAFUlEQVQImWMMDQ1lgAEmBiTAglMGAEruAgjcYZR9AAAAAElFTkSuQmCC" /> </pattern> In the print driver "style" is the only link to this information. Presumably the path starts out with style->fill.value.href->getObject(). Where does one go from there? All I need is: 1. The type of the object for the fill (pattern or image). 2. For a pattern, the name of the object (the part that corresponds to "EMFimage1" and "EMFhatch0_3F7FFF" above). 3. For the image case, the width, height, and bitmap. The bitmap can be either an RGB array or the png string as in the SVG. What incantations are need to pull these values out??? Thank you, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 17-Aug-2012 17:39, mathog wrote: No such luck. It comes and it goes. It doesn't crash reliably enough to be sure whatever change was just made was a fix or not. I'm not entirely sure the problem is even in my code exactly, it blows up in the Windows variant but not the linux variant, but when the Windows specific pieces are commented out it still blows up. I have seen things like this before where changes in code in a program far far away causes other bits of memory to move around, so that a preexisting memory access violation is moved into a destructive location. Ran it in valgrind on linux and found a pair of writes outside of allocated memory (not in my patch region.) Will try fixing those on linux, maybe it will heal the windows version. David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech