- Inkscape Devel - Inkscape Mailman

Crash on start rev 12550 : TypeNotRegistered
by Yann Papouin 13 Oct '13

13 Oct '13

Hi, Launching a clean build on a Win7 64bits raises an exception: terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegistered what(): svg:svg

7 10

Please don't reformat code and fix things in same commit!
by Johan Engelen 13 Oct '13

13 Oct '13

Hi all, Please don't fix a bug or change code in a commit where you reformat a lot of the code aswell. As an example, it is extremely hard to see what part of this commit actually changed code: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12548 Thanks! Johan

2 1

Code style question
by Johan Engelen 13 Oct '13

13 Oct '13

Hi all, Now with the change to C++ objects (very happy about it!), is it OK to change this if (SP_IS_LPE_ITEM(item)) { SPLPEItem *lpeitem = SP_LPE_ITEM(item); to this: A. if (SPLPEItem *lpeitem = dynamic_cast<SPLPEItem *>(item)) { I prefer it over the two other options I can think of: B. SPLPEItem *lpeitem = dynamic_cast<SPLPEItem *>(item); if (lpeitem) { or C. if (dynamic_cast<SPLPEItem *>(item)) { SPLPEItem *lpeitem = dynamic_cast<SPLPEItem *>(item); I like A (more than B or C) because it limits the scope of lpeitem, and avoids duplicating the long dynamic_cast<> thing. Downside is that it makes the if-statement rather long. We use option A in 2geom if I remember correctly. Please discuss, or add better implementations! I think it is worthwhile to add the outcome to the coding style page for reference. Thanks, Johan

3 3

Serious problems resulting from the units improvement GSoC merge
by Krzysztof Kosiński 13 Oct '13

13 Oct '13

https://bugs.launchpad.net/inkscape/+bug/1234216 - large perfomance regression https://bugs.launchpad.net/inkscape/+bug/1235279 - loss of precision These problems should be addressed soon, or the unit-related work might need to be reverted before release. The concept of using a viewBox that makes user units equivalent to inches or other large units is severely broken, because currently we use only 6 digits of precision for all coordinates. That was sufficient for pixels, but is definitely not sufficient for a lossless conversion between pixels and inches. Regards, Krzysztof

3 6

W3C SVG test suite and trunk
by Tavmjong Bah 11 Oct '13

11 Oct '13

Hi, I've run the W3C SVG 1.1 2nd Edition test suite using both Inkscape 0.48 and trunk. There are quite a few improvements in test compliance with trunk but some tests show regressions: http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/coords-un… http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/pservers-… http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/pservers-… http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/text-altg… http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/text-tref… Tav

7 26

Offsetting elliptical arcs
by Markus Engel 10 Oct '13

10 Oct '13

Hi devs, I changed the code that generates ellipses and arcs to using true elliptical arcs instead of cubic Bezier curves. Now there's a little problem: When you create for example a pizza slice and a linked offset, you will see that elliptical arcs are somehow "degenerated", i. e. the number of points decreases with increasing radius. (https://bugs.launchpad.net/inkscape/+bug/1236830) Note that the code for offsetting elliptical arcs has been there for quite some time. I'm not sure now whether this is how "offset" is intended to work. What do you think? Regards, Markus

3 4

Re: [Inkscape-devel] W3C SVG test suite and trunk
by Tavmjong Bah 09 Oct '13

09 Oct '13

On Wed, 2013-10-09 at 11:28 +0200, Guiu Rocafort wrote: > 2013/10/9 Tavmjong Bah <tavmjong@...8...> > > > > On Wed, 2013-10-09 at 00:51 +0200, Guiu Rocafort wrote: > > > Hi ! I've been looking at the GSOC and after solving a few problems I > > > can run the tests now. Now I have to find out a way to update the > > > tests. > > > > I was able to run the tests without too much trouble... however I did > > not have a set of "good" PNGs to test against... so I gave up and went > > back to using the latest SVG 1.1 test suite. > > > > To update the tests, I think you just need to put the new SVG files into > > the directory with the existing SVG files and then create reference PNGs > > in the appropriate files (known good rendering, known bad rendering). > > You can't just use the reference PNG files from the SVG test suite for > > doing automated pixel-by-pixel comparison as the results depend on the > > font used. (The SVG2 test suite will use a WOFF font, I think, to avoid > > this problem.) The existing files from the SVG test suite should be > > replaced by the files from the latest version of the SVG 1.1 2nd Ed test > > suite. > > I see, I wasn't aware of that problems with the fonts. Is the problem > related to the use of the SVGFreeSans font ? I saw this font in some > tests so I'm guessing it's being used in all of them. I noticed this > font is not in my system, so installing it in the machine is going to > perform the tests should solve the problem ? No. A search through the SVG files shows all kinds of different fonts being used. SVGFreeSans is required for some tests as is a number of other specially constructed fonts. > But since we're maybe going to use that ppa automated thing to perform > the tests that probably is not an option. Would it be safe to replace > all the fonts in the test by one of these safe fonts ? [1] No. If you look carefully you'll see that each proposed font-family is actually a list of fonts. For example: "Times New Roman", Times, serif. If the first font "Times New Roman" isn't found, then Times is search for. If that is not found then the generic fallback font serif is used. While "Times New Roman" and Times are similar, they are not exactly the same. For the use on the web they are probably acceptable equivalents but for pixel by pixel comparison, they wont work. The solution is to generate the PNG reference images on the same machine that the tests are going to be run on. Then the same font will be used for both the reference and the test images. > Tavmjong, i saw you're running some tests in [2], so, how are you > solving these font problems ? > > [1] http://www.w3schools.com/cssref/css_websafe_fonts.asp > [2] http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.49/htmlInkscapeHarness/index.html I look at each test manually and just filter out the differences in font. This is OK for a once in a while check but not for automated testing. Also, a few of the text tests really do need special fonts (found in the 'resources' directory). > > > I've set a personal branch in my launchpad account with the changes I > > > made to the original code. > > > https://code.launchpad.net/~neandertalspeople/+junk/inkscape-testsuite > > > > > > > > > After updating the test I'll try to find a way to automate the tests, > > > and perform them regulaly. What do you think about that ? Any idea > > > about how that could be done ? Maybe it is possible to set some kind > > > of trigger when there is a commit in the launchpad inkscape trunk ? > > > > This would be awesome. > > > > Tav > > > > > > > > > > Guiu >

2 1

Ellipses, Circles, and Arcs, oh my!
by unknown＠example.com 08 Oct '13

08 Oct '13

Hi, I see some action on rewriting Inkscape's General Ellipse code. It would be very nice if Inkscape could directly create the SVG circle and ellipse elements rather than use the SVG path element. I realize that this may be outside the scope of the current work but there is one thing that I should bring attention to: The SVG Working Group decided to allow markers on SVG shape elements.[1] Inkscape will actually already draw markers on shapes if there already are markers placed on the shapes in the SVG file (but doesn't draw them "correctly"), however Inkscape does not allow one to add markers to shapes through the GUI. (I'm sure that the drawing of the markers is accidental and not intentional.) It was fairly clear to the SVG WG that for rectangles, there are four markers (one for each corner) and for rounded rectangles, there are eight markers (one at each start and end of a corner arc). See attachment.[2] It wasn't as clear what to do for circles and ellipses. The group decided that there should be four markers on circles and ellipses, located at the 0, 90, 180, and 270 degree points. Inkscape currently represents circles and arcs as two path elliptical arc segments. In order to have four markers, it should be using four elliptical arc segments. I also noticed that the Object->Path command converts a circle/ellipse to a path using eight Bezier curves (and would thus have eight markers). It seems to me that it should be converting to four elliptical arc segments. (After all, converting a rectangle to a path doesn't produce four straight Bezier curves!) Tav [1] http://www.w3.org/2013/06/03-svg-minutes.html#item03 [2] Top row: expected behavior, bottom row: test. Green: Start marker, Yellow: Mid marker, Red: End marker.

6 16

Please Remove Dev Website
by Martin Owens 05 Oct '13

05 Oct '13

Hey Devs, We still have dev.inkscape.org running, I think we should shut it down since staging.inkscape.org takes over from that. I only just noticed because dev is appearing in google search results for inkscape downloads. I forget where it's being hosted though. Ian? Martin,

1 0

More C++ify?
by Johan Engelen 04 Oct '13

04 Oct '13

Hi Markus, all, Markus has done a great job of C++ifying a ton of our C-classes, but... there are still a few left. knot.h display/sp-canvas-item.h ... Are we taking up that task too? :-)) Cheers, Johan

4 4