May 2008 - Inkscape Devel - Inkscape Mailman

not-set behaviour of some attributes
by Felipe Sanches 10 May '08

10 May '08

I am working on the parameter loading code for svgfonts. Some attributes of the font-face tag are specified to behave in special ways when not set. One example is this couple of attribute: accent-height = "<number>" The distance from the origin to the top of accent characters, measured by a distance within the font coordinate system. If the attribute is not specified, the effect is as if the attribute were set to the value of the ascent attribute. If this attribute is used, the units-per-em attribute must also be specified. Animatable: no. ascent = "<number>" Same syntax and semantics as the 'ascent' descriptor within an @font-face rule. The maximum unaccented height of the font within the font coordinate system. If the attribute is not specified, the effect is as if the attribute were set to the difference between the units- per-em value and the vert-origin-y value for the corresponding font. Animatable: no. Is there already a established good practice to deal with this kind of thing on the inkscape codebase? I suppose that a good solution would be to implement a container template-class which would take care of the set/unset state of the stored object (in these cases, a double) and a method to compute the nonset value, sometimes refering to the value of other objects. In these cases, it would refer to an ascent object for the computation of a not-set accent-height attribute and both vert-origin-y and units-per-em objects for the computation of a not-set ascent attribute. Am I right? Does this already exist on the codebase? Should I implement it this way? Juca

2 1

Nameclashing with is_finite macro
by unknown＠example.com 10 May '08

10 May '08

Hi all, I am having troubles with the is_finite 2geom macro. In Inkscape code, there are cases where an is_finite function is defined (proj_pt.h for example). This goes okay now, only because no 2geom headers are included before that header is included. If the isnan.h header is included before proj_pt.h, the compiler will place the is_finite macro in the function definition and compilation will fail. (on windows in any case) I see 2 options: 1. change the is_finite function name in proj_pt.h 2. change the is_finite macro name in 2geom/isnan.h to something less clashable Thanks, Johan

2 2

Re: [Inkscape-devel] devlibs
by Bob Jamison 09 May '08

09 May '08

Hi again. I forgot to mention that the latest devlibs does have libgsl in it. bob

1 0

Win32 devlibs in Subversion
by Bob Jamison 09 May '08

09 May '08

Hi all, In grateful appreciation to ACSpike and his friends at Modevia.com for their continuing altruism and generosity, I want to inform people who are using the devlibs that we finally have the devlibs served via Subversion. The devlibs are now available here: https://svn.modevia.com/inkscape/devlibs However, to keep bandwidth down, I beseech people to get the 7zip of the repository: http://inkscape.modevia.com/win32libs/devlibs-2.12-svn-0805081735.7z Unzip that as your initial working copy, then do svn updates after that. Yes, it is huge (117mb), but it is not as bad as a 300mb svn checkout. So in the future, when there are changes to the devlibs, all you need is an occasional "svn up", and no more monolithic downloads. By the way, I have a question: do we still need to have Perl in the /devlibs? bob

3 2

Re: [Inkscape-devel] Inline Function Removal
by MenTaLguY 09 May '08

09 May '08

On Tue, 2008-04-29 at 00:55 -0400, Jimmy wrote: > Thanks. I have created the patch for Inline Function Removal and > therefore believe the task of removal is finished. I have attached the > patch as I don't have commit access yet. Hi Jimmy, Sorry to leave you hanging for so long; I've been having some work stuff I had to deal with. I've committed the patch. -mental

1 0

Rev 18558 fails to build: perl -CI ./utf8-to-roff [patch]
by Bernard Gray 08 May '08

08 May '08

This is on debian sid, perl=5.10.0-9.1 The following error has been occurring for me since Monday ================================= make[3]: Entering directory `/tmp/buildd/inkscape-0.46+svn20080508-cle.0' set -e; \ d=`sed -n 's,/,-,g;s,.*\$[D]ate: $..........$.*,\1,p' inkscape.pod`; \ pod2man inkscape.pod \ | sed 's/^\.TH .*/.TH INKSCAPE 1 "'"$d"'" "Inkscape-0.46+devel" "Inkscape"/' \ | perl -pe 'if (/^\[\% .*INCLUDE.*AUTHORS.* \%\]/) { open(FOO, "./AUTHORS");$_ = join(",\n", map { chomp; $_ } <FOO>) . "\n"; }' \ | perl ./fix-roff-punct \ | perl -CI ./utf8-to-roff \ > tmp.$$ \ && mv -f tmp.$$ inkscape.1 Too late for "-CI" option at ./utf8-to-roff line 1. make[3]: *** [inkscape.1] Error 9 make[3]: Leaving directory `/tmp/buildd/inkscape-0.46+svn20080508-cle.0' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/inkscape-0.46+svn20080508-cle.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/inkscape-0.46+svn20080508-cle.0' make: *** [build] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 pbuilder: Failed autobuilding of package -> Aborting with an error -> unmounting dev/pts filesystem -> unmounting proc filesystem -> cleaning the build env -> removing directory /var/cache/pbuilder/build//20387 and its subdirectories Command /bin/sh -c pdebuild --buildresult /home/bgray/svn/dbw-svn/inkscape/trunk/../build-area failed in <unknown>, how to continue now? [Qri?]: Aborting. =============================== $ rgrep "perl -CI" ./ ./Makefile.am: | perl -CI $(srcdir)/utf8-to-roff \ ./utf8-to-roff:# perl -CI -nae 'my ($ch, $seq) = @F; if (ord($ch) >= 128) { printf(" 0x\%x, q{\%s},\n", ord($ch), $seq); }' =============================== make is calling it with the -CI switch, and so is the hashbang bit of utf8-to-roff. if you remove it from utf8-to-roff it builds ok patch: =============================== --- utf8-to-roff (revision 18558) +++ utf8-to-roff (working copy) @@ -1,4 +1,4 @@ -#! /usr/bin/perl -w -CI +#! /usr/bin/perl -w # Converts a man page from utf8 (not understood by groff 1.18) to groff escapes. # I couldn't find any existing tool to convert from utf8 to groff, though I # seem to recall seeing some code to do so somewhere.

2 6

NEW: LPE Construct Grid
by unknown＠example.com 08 May '08

08 May '08

Hi all, I just committed a new simple LPE: "Construct Grid". It draws a grid using the first and second segment of the original path as constructing lines. I think the UI needs more work, does anybody have ideas for a more userfriendly approach? Thanks! Johan

1 0

Problems running Inkscape v0.46 on OSX 10.5.2
by Diederik van Lierop 08 May '08

08 May '08

Could anyone comment on any known problems running Inkscape v0.46 on OSX 10.5.2? Some users are reporting such problems in our Sourceforge forum, see http://sourceforge.net/forum/forum.php?thread_id=2018385&forum_id=323059 I've never touched a Mac before, but there must be someone who can point those users in the right direction (or tell them they're SOL) Diederik

2 1

Re: [Inkscape-devel] [Lib2geom-devel] GSL dependency
by Bob Jamison 08 May '08

08 May '08

So we have a couple of weeks to get this ready, then? :-) But a little bit of lead time is always nice, so that we are not always trying to catch up with the dependencies, or worrying that the build might break because of them. Actually, I built gsl-1.11 this morning, http://inkscape.modevia.com/win32libs/gsl-1.11-mingw.tar.gz and uploaded it to the rsync repository. I don't know if that directory is anon rsync downloadable yet. But maybe we can change our mechanism for the .7z's in the meantime from how it is now -- me manually zipping and uploading. Merely 7-zipping the rsync/develibs dir on the server would be much more efficient, and less of a pain. And we have an older version (1.8) from 2 years ago in the win32libs dir, too. -----Original Message----- >From: Aaron Spike <aaron@...749...> >Bob Jamison wrote: >> But I must have missed the heads-up for the new dependency in the mail list. > >No you didn't miss it. This is the heads up. We're discussing how adding >GSL will impact 2geom and inkscape. Chime in. :-) > >

3 2

Re: [Inkscape-devel] [Lib2geom-devel] GSL dependency
by Bob Jamison 07 May '08

07 May '08

Hi, all. I have no objection to adding GSL as a dependency (probably easiest for us as a static lib). It's not a big deal, really. But I must have missed the heads-up for the new dependency in the mail list. bob

2 1