- Inkscape Devel - Inkscape Mailman

Where is clipping information stored relative to an sp object?
by mathog 24 Mar '14

24 Mar '14

Along with implementing more of the EMF clipping records I'm looking into implementing clipping output to that format, which at present is completely unsupported. All the EMF output code sees is a pointer to "style", but it can get back from there to the object. Can one of you enlighten me as to the "path" from the object back to the stored clipping paths and the logic that ties them together? The data that needs to be extracted by working back up the data tree is like this: pathvector1 (a simple clippath with one path, references nothing else) done pathvector1 AND pathvector2 (a clippath that is itself clipped by another clippath) done pathvector1 OR pathvector2 (a clippath that has two paths) done Ideally this would be as C++ variables and not as the corresponding SVG text, so it would not need to be parsed again. Also on a related point, EMF clipping has modes that support AND, OR, XOR, and DIFF. EMF input goes through a text SVG intermediate, so the first two can be done using <clippath> syntax that I'm already aware of. Does SVG have path combination syntax for XOR and DIFF (subtract)? I know Inkscape has code that will operate on pathvectors to do this, but what I'm asking is if there is a standard SVG syntax that Inkscape supports more or less along these lines: <path> id="XORofPath1AndPath2" operator="XOR" path1="(a path specification)" path2="(another path specification)" </path> Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

libcroco fix
by Johan Engelen 24 Mar '14

24 Mar '14

To the maintainer of our libcroco copy, Please have a look at rev. 13178, where I fixed errors in pointer type signed-ness (Glib functions like g_strdup want a gchar*, not a guchar*). I guess you'd want to upstream the small change. cheers, Johan

5 7

Windows builds: enable -Werror
by Johan Engelen 23 Mar '14

23 Mar '14

Hi all devs on Windows, Please consider enabling -Werror for your work. I added stuff to build.xml to make it easy for you to see the status of trunk. Just remove the space between "-" and "->" to enable -Werror on line 356. Currently, there are 3 warnings/errors left (tdm-gcc 4.6.1). They are very likely to be false positives. But I am not sure yet. Make sure you don't add any new ones! Thanks for your effort in improving the code quality and stability of Inkscape. cheers, Johan

1 0

Possibly unitialized used of variable
by Johan Engelen 23 Mar '14

23 Mar '14

Hi all, GCC 4.6.1 gives an uninit var warning in sp-canvas.cpp: src/2geom/generic-interval.h: In static member function 'static void SPCanvasGroup::update(SPCanvasItem*, const Geom::Affine&, unsigned int)': src/2geom/generic-interval.h:144:8: error: '*((void*)(& bounds)+24).Geom::GenericInterval<double>::_b[1]' may be used uninitialized in this function [-Werror=uninitialized] src/display/sp-canvas.cpp:1051:19: note: '*((void*)(& bounds)+24).Geom::GenericInterval<double>::_b[1]' was declared here ... I have been working on this warning for hours, but I cannot find the problem. Because I have already found a (serious) bug from another warning like this, I am very reluctant to conclude that it is a compiler mis-analysis. I would greatly appreciate someone else having a (thorough) look at this. Thanks, Johan

5 10

I want to help and I want help……
by MARK BUCHALTER 23 Mar '14

23 Mar '14

To the developers. (GREAT PROGRAM) I am a web developer and created an app using mostly inkscape…that works well… but unfortunately, no mater how great a program this is,…... it is still a work in progress…. I am getting many bugs when try to revise and want to share what I have done and get some feedback. AND Try to help solve some of this issues. I would be happy to discuss this with anyone who thinks they can assist…please look at the App…located here….. http://www.digitaldudes.com/1-visualizer/9-link-visualizer.svg this is a swim suit / active ware designer I created…. I have not seen anyone else doing this kind of stuff… maybe because it is hard to make money BUT…PLEASE LOOK THANKYOU MARK BUCHALTER captbuck@...2857... cell" 340-642-3740

2 1

make doing unneeded compilations?
by mathog 22 Mar '14

22 Mar '14

Lately I have noticed that when I come back to Inkscape on another day, modify a single cpp (today's was drawing-text.cpp) and "make" it starts rebuilding all sorts of things that would seem to be utterly unrelated. In fact, the build is so extensive it may well be a complete rebuild. Here is just a fraction of the things it compiled: ... CXX sp-mesh-gradient.o CXX sp-mesh-patch.o CXX sp-mesh-row.o CXX sp-object.o CXX sp-path.o CXX sp-pattern.o CXX sp-rect.o CXX sp-shape.o CXX sp-stop.o CXX sp-style-elem.o CXX sp-text.o CXX sp-tref.o CXX sp-tspan.o CXX sp-use.o CXX style.o ... If the same file is later modified again, "make" the next time does the expected thing and just compiles that one file and then links everything. Any idea why it is doing that? It almost seems like the Make files now have some concept of "old" object files and anything over a day old gets rebuilt. Trunk 13168, Ubuntu 12.04.4 LTS Configure was run with export CPPFLAGS="-DWITH_SVG2" ./configure --disable-strict-build Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 6

libuemf: upmf.c
by Johan Engelen 22 Mar '14

22 Mar '14

Hi David, In libuemf/upmf.c, what is this line of code supposed to do? line 3096: U_SERIAL_DESC *List = List; Thanks for fixing, Johan

1 0

filter2D_IIR problem
by Johan Engelen 22 Mar '14

22 Mar '14

Hi all, There may be a bug in nr-filter-gaussian.cpp. The following warning is emitted: src/display/nr-filter-gaussian.cpp: In function 'void Inkscape::Filters::filter2D_IIR(PT*, int, int, const PT*, int, int, int, int, const IIRValue*, const double*, IIRValue* const*, int) [with PT = unsigned char, unsigned int PC = 1u, bool PREMULTIPLIED_ALPHA = false, IIRValue = double]': src/display/nr-filter-gaussian.cpp:504:45: instantiated from here src/display/nr-filter-gaussian.cpp:342:13: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] src/display/nr-filter-gaussian.cpp:343:13: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] src/display/nr-filter-gaussian.cpp:504:45: instantiated from here src/display/nr-filter-gaussian.cpp:358:17: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] The warning is emitted because the (incredibly ugly!) #define PREMUL_ALPHA_LOOP for(unsigned int c=0; c<PC-1; ++c) will resolve to #define PREMUL_ALPHA_LOOP for(unsigned int c=0; c<0; ++c) for the template instantiated value for PC = 1. Meaning that the loop will never run. Is this intended? If so, please fix the code to not emit that warning. If it's a bug, please fix the bug! :) Thanks, Johan

2 1

Re: [Inkscape-devel] Warning on explicit cast in libuemf
by Johan Engelen 21 Mar '14

21 Mar '14

Back to on-list. On 21-3-2014 20:07, mathog wrote: > > 1. Why do we need libiconv in devlibs at all since it is already in > mingw? It is not in my copy of MinGW (TDM-GCC). > 2. Why is the version in devlibs 1.09 (from 2003 or 2004) when 1.14 > is current (and the version in mingw)? Don't know. How harmless is upgrading without upgrading our other dependencies? ciao, Johan

1 0

Warning on explicit cast in libuemf
by Johan Engelen 21 Mar '14

21 Mar '14

Hello David, in libuemf/uemf_utf.c, there is /** \cond */ /* iconv() has a funny cast on some older systems, on most recent ones it is just char **. This tries to work around the issue. If you build this on another funky system this code may need to be modified, or define ICONV_CAST on the compile line(but it may be tricky). */ #ifdef SOL8 #define ICONV_CAST (const char **) #endif //SOL8 #if !defined(ICONV_CAST) #define ICONV_CAST (char **) #endif //ICONV_CAST /** \endcond */ An example of the macro usage: ... status = iconv(conv, ICONV_CAST &src, &srclen, &dst, &dstlen); ... This generates a warning because, at least on Windows, iconv expects a (const char **) and gcc complains about an unsafe cast. This is not at all trivial, and is a very valid compiler warning. Please read this: http://stackoverflow.com/questions/14562845/why-does-passing-char-as-const-… I do not know how to fix this at the moment. Of course I could do an #ifdef for Windows to replace the cast with what iconv wants, but.... Thanks for having a look, Johan

3 3