June 2008 - Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] [Lib2geom-devel] path parsing - nartbpath optimization?
by unknown＠example.com 30 Jun '08

30 Jun '08

> -----Original Message----- > From: njh [mailto:njh@...1927...] > Sent: zondag 29 juni 2008 19:01 > To: Engelen, J.B.C. (Johan) > Cc: inkscape-devel(a)lists.sourceforge.net; > lib2geom-devel(a)lists.sourceforge.net > Subject: Re: [Lib2geom-devel] path parsing - nartbpath optimization? > > On Sun, 29 Jun 2008 J.B.C.Engelen@...1578... wrote: > > > Hi all, > > > > When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath > optimizes it > > and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom path > parser does > > not. So when writing the path back to svg, nartbpath and > 2geom don't > > match up. > > Write a path optimiser function. If you're going to optimise > this, why not consider more interesting optimisations like > reparameterisation? This may be a good idea for later, but for now I was interested in "the right"(TM) behavior. What Inkscape used to be doing. :) Johan

1 0

Crash in 2geom ellipse parsing
by Jon A. Cruz 30 Jun '08

30 Jun '08

We've gotten bug #243232 that is due to an assertion in 2geom being triggered. terminate called after throwing an instance of 'Geom::RangeError' what(): lib2geom exception: there is no ellipse that satisfies the given constraints (2geom/elliptical-arc.cpp:616) https://bugs.launchpad.net/inkscape/+bug/243232 Can someone familiar with that area take a look? Thanks.

5 7

path parsing - nartbpath optimization?
by unknown＠example.com 30 Jun '08

30 Jun '08

Hi all, When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath optimizes it and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom path parser does not. So when writing the path back to svg, nartbpath and 2geom don't match up. What to do? Should 2geom optimize the path as well? Or should the svg writer optimize it? Or keep it the way the input was? Thanks for thoughts, Johan

5 6

SVGFonts: lot's of questions
by Felipe Sanches 28 Jun '08

28 Jun '08

1. "all text is output to libnr using livarot types, not using cairo" Can you explain that in more detail? I'd like to know: * what livarot types are. * how does livarot distinguish from cairo * does that mean we need to replace livarot? How to proceed? 2. "Getting text layout to use Cairo for output rather than libnr." Can you show me where does that output reside in the code? 3. [09:51:42] <^-> [JucaBlues] so, I guess, we should have in the API a way to provide pango with the metrics specified on svgfonts xml attributes [09:52:03] <^-> [JucaBlues] i mean kerning and stuff like that [09:52:15] <cyreve> yeah which, now I think of it, is exactly what gail is looking at "Finding a way to get the user font through Pango. One (ugly) possibility which comes to mind is to pretend to be sans-serif while going through Pango and then do a fudge afterwards. Gail asked to be a part of this discussion and she's more knowledgable than I am about cleaner approaches which could be taken here, so I've CCed her" I'm still feeling completely lost Juca

5 6

Re: [Inkscape-devel] Crash in 2geom ellipse parsing
by Bob Jamison 27 Jun '08

27 Jun '08

In any case, bad data should be handled gracefully, not with a killer assertion. The general rule is to be forgiving on input, strict on output. bob -----Original Message----- >From: Marco <mrcekets@...400...> >Sent: Jun 26, 2008 11:12 AM >To: Marco <mrcekets@...400...>, "Jon A. Cruz" <jon@...18...> >Cc: "inkscape-devel(a)lists.sourceforge.net" <inkscape-devel(a)lists.sourceforge.net>, "lib2geom-devel(a)lists.sourceforge.net" <lib2geom-devel(a)lists.sourceforge.net>, njh <njh@...1927...> >Subject: Re: [Inkscape-devel] Crash in 2geom ellipse parsing > >On Thu, 26 Jun 2008 17:49:38 +0200, Marco <mrcekets@...400...> wrote: > >> On Thu, 26 Jun 2008 17:02:00 +0200, Jon A. Cruz <jon@...18...> wrote: >> >>> We've gotten bug #243232 that is due to an assertion in 2geom being >>> triggered. >>> >>> terminate called after throwing an instance of 'Geom::RangeError' >>> what(): lib2geom exception: there is no ellipse that satisfies the >>> given constraints (2geom/elliptical-arc.cpp:616) >>> >>> >>> https://bugs.launchpad.net/inkscape/+bug/243232 >>> >>> >>> Can someone familiar with that area take a look? >>> >> >> Could it be a parsing error ? >> I tried to create EllipticalArc instances using the data presents >> in the path command that caused the assertion failure and all seem >> to work fine. >> >> - Marco >> > >No sorry I was wrong! There is really a problem with the passed data. >The following line is the command that causes the assertion: >"M 9.0625 10.21875 A 0.6384567 0.6384567 0 1 0 8.1875 11.15625" > >I'm analizing the problem. > >- Marco > > > >-- >Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

7 14

more on extensions
by Alexandre Prokoudine 27 Jun '08

27 Jun '08

Hi, A recently added "3D polyhedron" extension is actually more useful than it seems at first site, because it can load arbitrary OBJ files which are basically 3D model objects. Nifty, eh? ;-) What is not so cool is that users are supposed to provide full path to an OBJ file in a text input box. Is it actually possible to hook an Open File dialog to extensions? Alexandre

5 7

Support for other than English on OS X
by Jon A. Cruz 27 Jun '08

27 Jun '08

Hi, I finally got time to test a few things about Inkscape.app building on OS X to enable languages other than English. The secret turns out that the Resources folder inside just needs an empty folder with the name of the local and ".lproj" added. For example, to add Spanish it just needs "Spanish.lproj" to be added as an empty directory. And adding an empty "sv.jproj" folder enables Swedish (as "Svenska" in the OS X International control panel). I've attached a simple hack to osx-app.sh for testing. If anyone who's successfully built an Inkscape.app for OSX could test this, that would be a big help. thanks. It's on bug 242105 https://bugs.launchpad.net/inkscape/+bug/242105

3 7

OSX native compile error
by Matt Peterson 27 Jun '08

27 Jun '08

Inkscape wants to use Bitstream Vera Sans as the default font, but I don't have that installed on my system so every character becomes ugly rectangles. I cannot figure out how to change the font to something else. I noticed that there is a Resources folder when embedding Inkscape inside a bundle, but it doesn't seem to work for the native version. Does anyone have any suggestions for putting inkscape native into an application bundle? -- Matthew Peterson Programmer Christa McAuliffe Space Education Center On Fri, Jun 20, 2008 at 3:39 PM, Matt Peterson <revcompgeek@...400...> wrote: > Looks like both were problems. I copied the definitions of IS_FINITE to > 2geom/isnan.h and switched to gcc-4.0 and it compiled fine in about 4 hours. > It seems to run fine, but I was having font problems. However, I recently > screwed up my system fonts and I need to restart, which should fix the > problems. If anyone wants it, I have terminal output of the assertion > failures that happened while running. > > -- > Matthew Peterson > Programmer > Christa McAuliffe Space Education Center > > On Mon, Jun 16, 2008 at 6:06 PM, Michael Wybrow < > michael.wybrow@...38...> wrote: > >> >> On 17/06/2008, at 3:08 AM, Matt Peterson wrote: >> >>> >>> I have been attempting to compile a native version of Inkscape for Mac OS >>> 10.4 on a PowerBook G4, and using the latest SVN I am getting the following >>> error: >>> >>> In file included from 2geom/sbasis.h:43, >>> from 2geom/concepts.h:34, >>> from 2geom/d2.h:39, >>> from libnr/nr-convert2geom.h:16, >>> from sp-item.h:27, >>> from sp-lpe-item.h:17, >>> from sp-shape.h:18, >>> from sp-ellipse.h:18, >>> from arc-context.cpp:27: >>> 2geom/linear.h: In member function `bool Geom::Linear::isFinite() const': >>> 2geom/linear.h:91: error: `__isfinite' undeclared (first use this >>> function) >>> 2geom/linear.h:91: error: (Each undeclared identifier is reported only >>> once for >>> each function it appears in.) >>> make[2]: *** [arc-context.o] Error 1 >>> make[1]: *** [all-recursive] Error 1 >>> make: *** [all] Error 2 >>> >> >> >> My guess would be that the isnan.h in 2geom does not have the fixes we >> have added to the inkscape isnan.h. >> >> Try copying the definitions of IS_FINITE from src/isnan.h over the ones in >> src/2geom/isnan.h. >> >> >> Also, Matt, maybe you are using gcc 3.3? We compile our 10.4 packages >> with gcc-4.0, so maybe we haven't noticed a problem with gcc-3.3 on Mac OS >> X. >> >> >> >> Cheers, >> Michael >> > >

3 4

quick note on "using"
by Jon A. Cruz 26 Jun '08

26 Jun '08

Hi, Just a quick little note on the use of "using namespace" and such in .h files. Please don't have "using" in .h files, since that ends up contaminating any .cpp files that include the .h. Also any that include .h's that in turn include .h's that do... ... but then we get into my personal preference to avoid #include inside of .h's when possible.

1 0

Hackontest
by unknown＠example.com 25 Jun '08

25 Jun '08

Hi all, For long time I've been too lazy apply Inkscape for Hackontest, but next week when I am back in the Netherlands (!!!), I will sign us up for it. But first I'd like to do a check to see whichs devs are interested in teaming up for it. Please let me know if you're interested :-) One of the possible projects we could be working on is getting the whiteboard working. (imho it fits very nicely with the spirit of a teamed effort to code it :) Cheers, Johan

5 7