2012/2/20 alvinpenner <penner@...1856...>:

• running Inkscape from gui gave the error message, missing libintl-8.dll
• problem fixed by copying it from \devlibs\bin\ to \Inkscape\ directory

I fixed the missing library copy in revision 11005. Regards, Krzysztof

On Jun 20, 2012, at 8:40 AM, LucaDC wrote:

I'm having this error when compiling under Windows XP:

Make error line 289: problem compiling: src/live_effects/lpe-skeleton.cpp: In constructor 'Inkscape::LivePathEffect::LPESkeleton::LPESkeleton(LivePathEffectObject*)': src/live_effects/lpe-skeleton.cpp:35:31: error: '_' was not declared in this scope

It came out in rev.11502 (rev.11501 compiles correctly, rev.11502 doesn't).

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 :

I'm back to working on EMF a bit more. (Need to put libUEMF up on sourceforge, as that is what I am using now. That now works on both big and little endian machines.

Anyway, EMF has Arc, Pie, and Chord types and these are not yet implemented for read in inkscape. For write they are currently exported as Beziers and not their native types (which is probably a good idea.)

I understand the geometry in the EMF file, but corresponding structures in Inkscape are a mystery to me. Created a test figure containing one quarter of a grey ellipse with a blue boundary all the way around ("Pie"), and one quarter of a red circle ("Arc"). Inkscape did not seem to have any obvious single object "Chord". When saved as plain svg these two objects (in the order listed above) are:

  <path
     d="m 172.85715,349.50504 a 75.714287,70 0 0 1 75.71428,69.99999

l -75.71428,1e-5 z" transform="matrix(0.94495594,0,0,2.124136,11.598569,-473.66453)" id="path10"

style="fill:#7f7f7f;fill-opacity:1;stroke:#0000ff;stroke-width:1.41166961;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0" /> <path d="M 288.57143,712.36218 A 68.571426,68.571426 0 0 1 220,780.93361" id="path817"

style="fill:none;stroke:#ff0000;stroke-width:10;stroke-miterlimit:5;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" />

whereas when saved in Inkscape SVG they are

  <path
     sodipodi:type="arc"

style="fill:#7f7f7f;stroke:#0000ff;stroke-width:1.41166958;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;fill-opacity:1" id="path10" sodipodi:cx="172.85715" sodipodi:cy="419.50504" sodipodi:rx="75.714287" sodipodi:ry="70" d="m 172.85715,349.50504 a 75.714287,70 0 0 1 75.71428,69.99999 l -75.71428,1e-5 z" sodipodi:start="4.712389" sodipodi:end="6.2831853" transform="matrix(0.94495594,0,0,2.124136,11.598569,-473.66453)" /> <path sodipodi:type="arc"

style="fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:10;stroke-miterlimit:5;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" id="path817" sodipodi:cx="220" sodipodi:cy="712.36218" sodipodi:rx="68.571426" sodipodi:ry="68.571426" d="M 288.57143,712.36218 A 68.571426,68.571426 0 0 1 220,780.93361" sodipodi:start="0" sodipodi:end="1.5707963" sodipodi:open="true" />

Start/end are arc positions in radians. d and transform are SVG objects and I can look up what they mean elsewhere. style I understand.

What are cx,cy and rx,ry? Why are sodipodi:open="true" amd sodipodi:type="arc" required when d="..." is the same in both forms?

Thank you,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

---

Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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:

I am looking into adding features to EMF export where it can (optionally) convert dot/dash to line/bezier segments, and can convert gradients into piles of (near) rectangles to approximate gradients. It turns out that most drawing programs make these two conversions automatically when exporting to EMF. The first one can be done now with convert2dashes.py, but that changes the SVG, which isn't the intent, and there is not, I believe, currently an automatic way to do the gradient conversion.

Anyway, for the first case what I am looking for is a function that will return {x1,y2} given {x1,y1} on a Bezier and the parameter "d", a length along the Bezier. Is there such a method? (The equivalent for a line is not a problem.)

The other conversion looks like it will be fairly tricky, in general. Imagine a gradient at some arbitrary angle that will be approximated by 20 color slices - picture that as a ray extending from the first slice to the last, with the ray perpendicular to the slices. The object that is filled may have a complex geometry (for instance a spiral with 13 turns). The i'th slice would be found by finding a whole bunch of intersections. If that ray has length L, then the front end of the slice would be the intersection of the filled path with the line perpendicular to the ray at offset Li/20 along it. The back end of the slice would be the same at L(i+1)/20. As the spiral case demonstrates, there could be a set of front ends, and a set of back ends, which would need to be paired up, and connected by what would in general by a Bezier segment. In some cases one face or the other of the slice segment could also be a Bezier.

Somewhere in Inkscape the code to find these slice pieces already exists:

PATH INTERSECTION(filled spiral path, long skinny rectangle that lies over it)

reduces to one or more filled paths which make up that slice. Do the same thing N times with a series of slightly overlapping rectangles and the job is basically done. Where in Inkscape are the methods for finding path intersections?

Thanks,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

---

Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

-- Wilfried Hennings

On 14-Aug-2012 16:02, mathog wrote:

Anyway, for the first case what I am looking for is a function that will return {x1,y2} given {x1,y1} on a Bezier and the parameter "d", a length along the Bezier. Is there such a method? (The equivalent for a line is not a problem.)

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:

One of my patches causes the windows version to blow up reliably on save to EMF if and only if it sees a string consisting only of all characters above 127 (that is, all UTF-8 characters need at least one more character).

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:

Hopefully whatever gremlin this was has been permanently cast out of the system!

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