- Inkscape Devel - Inkscape Mailman

SVG Tiny Article and Question
by Jon Phillips 21 Jul '04

21 Jul '04

Hello All, There is an interesting post on Slashdot about MACROMEDIA's erroneous support of SVG Tiny. The O'Reilly article attached to the post mentions how many cell phone manufacturers are supporting SVG Tiny. http://slashdot.org/article.pl?sid=04/07/20/2250256&tid=152&tid=95 http://www.w3.org/TR/SVGMobile/ Oreilly's Post: http://oreillynet.com/pub/wlg/5212 Macromedia's Post about: http://www.macromedia.com/devnet/devices/articles/msvg_t.html Anyhow, we have been discussing on the chat channel, and I wonder the best way to implement support for this emerging market? Could we make it as simple as an export, or as simple as a save-as, like plain svg? Also, anyone in the know, how long would such a thing take to implement. I'm keeping my eyes on the watchout for where SVG will be supported, and it appears (and this comes from talking to industry folks in US, Japan, and KOREA) that the emerging market for SVG (at least initially) will be for cell phones. What is the best way to go about implementing this? I am going to seek out Macromedia folks and W3C folks at siggraph in a couple of weeks, and would love to have some thoughts and positions on this... Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

1 0

Re: [Inkscape-user] Make fails - freetype problem?
by MenTaLguY 21 Jul '04

21 Jul '04

On Tue, 2004-07-20 at 10:18, John Mellor wrote: > I have freetype-2.1.8 installed. The error sounds quite explanatory but > not sufficiently so for my lack of experience. Can anyone help please? Specific versions of freetype seem to have different requirements for which header files to include. :/ -mental

1 0

The standard for PO files is now UTF-8
by Arpad Biro 20 Jul '04

20 Jul '04

Dear Translators, This is to let you know that all non-UTF-8 translation files have been converted to UTF-8 (and will automatically be in the future if needed). Please use this standard so that we will have fewer i18n problems. Thanks. Arpad Biro __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

1 0

Tarball Release Sizes
by Bryce Harrington 20 Jul '04

20 Jul '04

Stats for how our tarball size has changed over different releases: 1.9M inkscape-0.35.tar.gz 1.9M inkscape-0.36.tar.gz 2.5M inkscape-0.37.tar.gz 3.2M inkscape-0.38.1.tar.gz 4.2M inkscape-0.39.tar.gz I think that's pretty good; I was expecting the size to be about double that. 4.2M should be very little trouble for folks to download. :-) In the current release, here's a rundown of the top 20 largest files: 1124712 ./share/tutorials/elementsofdesign.sl.svg 1097642 ./share/tutorials/elementsofdesign.svg 899283 ./configure 753019 ./src/Makefile.in 321787 ./share/screens/keys.svg 320641 ./share/tutorials/tutorial-advanced.sl.svg 319166 ./share/screens/keys.sl.svg 295727 ./share/tutorials/tutorial-advanced.svg 292340 ./share/tutorials/tutorial-advanced.fr.svg 266949 ./aclocal.m4 253315 ./share/tutorials/tutorial-basic.sl.svg 245013 ./share/icons/icons.svg 232963 ./share/tutorials/tutorial-basic.ru.svg 231423 ./share/tutorials/tutorial-basic.fr.svg 224177 ./share/tutorials/tutorial-basic.svg 184019 ./ltmain.sh 178732 ./share/tutorials/tipsandtricks.sl.svg 149112 ./share/tutorials/tipsandtricks.svg 142727 ./po/sr.po 141439 ./po/fr.po Directory sizes: 32K debian 288K doc 5.0M po 6.7M share (largely the tutorials section) 7.2M src We've batted around the idea of eventually breaking the tutorials out into separate language-specific distribution packages someday maybe in a few releases, especially as we gain additional translations of them. Looks like it isn't a problem right now though. Bryce

3 2

autopackage for 0.39, upcoming patches
by Mike Hearn 20 Jul '04

20 Jul '04

Hi guys, Firstly, some good news. On compiling Inkscape against the GTK 2.2 headers, which is a part of doing an autopackage release of it, my crash mysteriously vanished. So that's an interesting data point. Secondly, there is an package of 0.39 available here: http://navi.cx/~mike/inkscape/0.39/inkscape-0.39.package It's built against a new version of autopackage, 0.6, which will be released properly sometime tomorrow. Likewise the nightlies and the GTKmm/sigc++ packages have also been rebuilt against that release. I checked the server logs the other day, there have been ~1700 downloads of the inkscape autopackage. Of those approximately half also pulled in GTKmm as a resolved dependency. We've had very little feedback from this - I had assumed there simply weren't many people using the service, but clearly this is not the case. I guess it's simply working pretty well for people! :) Because of this I'm feeling pretty confident that the 0.6 release is likewise stable and reasonable compatible with a variety of setups - in fact we've fixed a few distro compatibility bugs in this release, especially for Slackware users. So, if you could link to the 0.39 package from the Inkscape website, that'd be great as I feel a lot of people would benefit from a package of the stable release. Hongli has created some stock HTML that people can embed/tweak for their websites which identify the fact that it's an autopackage and link to the instructions for how to install them: http://www.autopackage.org/docs/howto-install/index.html I don't have that right now, but I'd be interested in your opinions on the stock HTML idea later. Having packaged up Inkscape of course I wanted to play with it - that's where the crash report came from. So I drew an icon/logo for autopackage: http://autopackage.org/logos/logos.html Why not marvel at my lack of artistic talent? If any of the pros on this mailing list want to draw us a better one please feel free! :) Finally, I'm afraid I'm not finished with the patches yet! This: http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/autopackage/apbuild/relaytool ... is likewise a non-work of art. I was originally going to submit a patch to make gtkspell dlopened at runtime, but realised that this was (a) tedious and (b) going to happen a lot. So I wrote relaytool which is designed to automate it. For those who haven't read the above URL, relaytool is a program which generates C files you can compile and link into your app, which replaces the -lfoo option you'd normally use with a "soft link". It uses assembly and ELF magic to perform the link at runtime using dlopen, but it won't fail if the library isn't present. The interesting thing about this approach is that it requires no code changes, and doesn't rely on icky stuff like header rewriting. Code like this: #ifdef HAVE_GTKSPELL gtkspell_attach( ... ) #endif can simply become: #ifdef HAVE_GTKSPELL if (libgtkspell_is_present) gtkspell_attach( ... ); #endif And as long as the binary was compiled in the presence of the gtkspell headers, at runtime Inkscape will use libgtkspell if it's present and continue without spell checking ability if it's not. Therefore we can cut down on the number of hard dependencies for Inkscape, so increasing the reliability and robustness of the installation. It works for exported variables too, though not many libraries use that. In theory it also works for C++ objects but I haven't tried it yet. You use it like this: gcc -o testapp testapp.c -lgtkspell becomes gcc -o testapp testapp.c `relaytool --relay gtkspell -lgtkspell` And the stub file will be generated and compiled transparently on systems that relaytool supports. On systems it doesn't support the -l option is passed through unchanged. relaytool isn't quite ready yet, in particular I need to write an autoconf check for ELF platforms so using it doesn't interfere with the build on Windows and MacOS X. We can use a similar technique to allow Inkscape to use the GTK 2.4 file picker but cleanly fall back to the GTK 2.2/2.0 APIs when GTK 2.4 isn't present. Hope that helps, thanks -mike

3 6

Re: Tarball Release Sizes
by Robert Crosbie 20 Jul '04

20 Jul '04

Can the svg tutorials be saved as svgz? That should reduce their size in the release a bit. Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft� SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN� Premium right now and get the first two months FREE*.

2 1

Re: [Scribus] linked text
by Jon Phillips 20 Jul '04

20 Jul '04

Hi Sebastian, We would love your help on the German translation. If you do, please make a patch and upload to our patch tracker. If you would like to join our project as a developer after that initial patch, then we will welcome you with open arms. (our policy is one good submission and then cvs access) INKSCAPERS: Could someone who deals with translations communicate with Sebastian further please. Thx! Jon On Sat, 2004-07-17 at 04:07, Sebastian Röder wrote: > Hi Jon, > > i didn`t manage to write to the inscape mailing list as annonymous user so > maybe I can write my short "feature request" here: > > I work a lot with Scribus (at least in last weeks) and want to work with > Inkscape to create graphics for my Scribus layouts. But the German > tranlation for inkscape is not up to date (I guess around 80% not translated) > so it is realy hard for the first steps to get to know how things work in > inkscape. I already wrote a Email to the former translater (I found an Email > adress in the .po file) but he was the old sodipodi translater and will nor > update the inkscape .po anymore. Seems like there is a German translater > missing! And seems like I have to sign for the inkscape mailinglist as well. > Maybe you can add my little request to the inkscape list for now? > > Thanks, > Sebastian Roeder - German Scribus (and one day Inkscape) user > _______________________________________________ > Scribus mailing list > Scribus@...119... > http://nashi.altmuehlnet.de/mailman/listinfo/scribus -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

2 1

Is there a reason to not upload the 0.39 autopackage to SF?
by bulia byak 20 Jul '04

20 Jul '04

2 1

Inkscape 0.39
by Ted Gould 20 Jul '04

20 Jul '04

= Inkscape 0.39 = We are pleased to announce the Inkscape 0.39 release. The most important change in this release is the switch to the Pango library for font handling and Unicode support; a lot of work also went into new SVG features, export/import, UI, and usability. Here are the highlights: * Pango: smoother text display, auto kerning, better i18n (automatic font substitution, right-to-left text, bi-directional text), less platform dependence * New SVG features: markers (aka arrowheads), clones (svg:use), pattern tiles, RDF metadata; many SVG compliance bugfixes * New dialogs: Preferences, Find, Metadata * New and improved import/export file formats: PS, EPS, AI, PNG, JPEG, TIFF, BMP, Sketch, Dia, and more * Pure convenience: usable dropper, scale switches, Commands bar, more tool controls (including rounded stars), more import formats, more paper sizes, Revert command, edit inside group, better selection cues, spell checking, window layout configurable, streamlined Fill & Stroke, snapping improvements, better rounded corners in rects, path reversing, persistent rotation crosshair, per-object export hints, and much more * Internals: speedups, more C++ification, garbage collection, SigC++ signals, wider use of new data structures, extensive cleanup * Plus: new documentation, new translations, lots of assorted bugfixes (the infamous "freeze when dragging outside of window" bug on Windows is gone!) The team has placed a great deal of scrutiny into fixing bugs, and while this was not a primary focus as it had been for 0.38.1, we expect this release will be at least as stable as the last. Many thanks go out to all of the users that took the time to write bug reports, you make Inkscape better. For tons more details, see the Release Notes for 0.39: http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes039 Screenshots: http://www.inkscape.org/screenshots/ Download your packages (Linux, Windows, Mac OSX): http://sourceforge.net/project/showfiles.php?group_id=93438

3 2

[Fwd: Re: [Scribus] linked text]
by Jon Phillips 20 Jul '04

20 Jul '04

SCRIBUS meeting after release of 0.40? If agree, I will place on roadmap. Jon -----Forwarded Message----- > From: Craig Bradney <cbradney@...242...> > To: Jon Phillips <jon@...235...> > Cc: Peter Linnell <scribusdocs@...84...> > Subject: Re: [Scribus] linked text > Date: Sat, 17 Jul 2004 11:38:16 +0200 > > Hi Jon > > yep.. for sure.. We will have another meeting. We just need to make a > date and have it. I guess it would be more worthwhile after your 0.39 > release and our 1.2 release. > > Of course.. we are always happy to have one before! > > Craig > > On Sat, 2004-07-17 at 06:36, Jon Phillips wrote: > > I like that. You guys are doing a great job. Hopefully sometime this > > summer we could have another get together between scribus and inkscape > > developers... > > > > Jon > > > > > > > > On Wed, 2004-07-14 at 04:53, Craig Bradney wrote: > > > Yes.. but we need some other code written first, as well as our 1.2 > > > targets to be met. Once the "other code", ie our new text importers are > > > finished, we can investigate the auto update stuff. At a guess it wont > > > be that hard, but no guarantees for before 1.2 at all. > > > > > > Craig > > > > > > On Wed, 2004-07-14 at 03:16, Jon Phillips wrote: > > > > But I've proposed this previously as a great addition to SCRIBUS. It > > > > would dramatically increase the ability for editors and designers to > > > > work together, but not in the same app. > > > > > > > > Jon > > > > > > > > > > > > On Tue, 2004-07-13 at 01:57, Craig Bradney wrote: > > > > > On Tue, 2004-07-13 at 09:58, vaise@...462... wrote: > > > > > > Hi everyone ! > > > > > > I use Scribus 1.0.1 on Mandrake 10. > > > > > > When I insert a text frame, I can Get Text, no problem. But I would like the > > > > > > scribus document to be "linked" to the text file. When the .txt file is > > > > > > modified, the scribus document should change too (next time it is opened of > > > > > > course). > > > > > > Maybe this fonctionality does not exist in 1.0.1 ? > > > > > > > > > > > > Dsant > > > > > > > > > > Hi > > > > > > > > > > No, there is no possibility to do this in any version. > > > > > > > > > > Craig > > > > > > > > > > ______________________________________________________________________ > > > > > _______________________________________________ > > > > > Scribus mailing list > > > > > Scribus@...119... > > > > > http://nashi.altmuehlnet.de/mailman/listinfo/scribus -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

2 1

0.39 PR
by Jon Phillips 20 Jul '04

20 Jul '04

Bryce and all, Could we circulate the PR for this release and place on the wiki prior to being sent. That way we can add our two cents. I think we need to be more descriptive in our releases about what is done and what could be accomplished with new features. http://www.inkscape.org/cgi-bin/wiki.pl?AnnouncementPR Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/) -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

2 1

Current libs in Win32 build
by Bob Jamison 20 Jul '04

20 Jul '04

Getting the Win32 build working with the new libs is still a work-in-progress. However, here are the current libs I am using, FYI: atk 1.6.0 boehm-gc 6.2 freetype 2.1.7-1 gettext 0.13.1 glib 2.4.2 glibmm 2.4.3 gtk+ 2.4.3 gtkmm 2.4.4 gtk-wimp 0.6.0 jpeg 6b-3 libart_lgpl 2.3.14 libcroco 0.6.0 libiconv 1.9.1 libpng 1.2.5-1 libpopt ? <static> libtiff 3.6.1-2 libxml2 2.6.9 pango 1.4.0 sigc++ 2.0.3 zlib 1.2.1 A few of these I have built myself. Others are binaries built by others, over which we have no control. Bob

5 5

RE: [Inkscape-devel] Test strategy
by Gazal, Geraud (MED) 19 Jul '04

19 Jul '04

> Either Wiki or CVS would be suitable places for storing it. There are > roughly equal pros and cons both ways. Wiki would be more widely > accessible to more people, but CVS would allow a little more > flexibility > for manipulating the document (e.g., grep, txt2pdf, etc.) -> workaround : HTML format ( portable, plus support usefull things such as images, links, tables...) maintained in the CVS and linked to a wiki page ? > It may be worthwhile if we have better ideas for the > categorization, to > alter the bug tracker to match. Those categories were decided when we > first started the project, and probably need updated to match what we > people actually support bugs about. If anyone has ideas for > improvements let me know and I'll apply them. Yup, this is directly linked to the test process. I'm preparing (70% done) it. > A subcategory of this is 'Compliance testing', which validates the > features against a spec - in our case the W3C SVG spec. There may be > other specs we can test compliance against, although some (like the > GNOME Human Interface Guidelines) will generally not be automatable. Ok, got it. Will take a look at Gnome HIG see what can be done there (not my #1 priority, but kept on the list) Already diving in SVG standards, plus test tool suite. > There is also performance testing, which can be done in a variety of > ways. For example, startup timing, function-level profiling, etc. > > Also, we should include memory error testing ala purify and valgrind. Already in mind for the categories. > > > Tests: > > Build > > Linux (Debian / Gentoo / Slackware / Mandrake / Fedora > / Suse / Others) > > Windows (98 / 2000 / XP) > > MacOS (X) > > BSD (Free / Open) > > Other Unices (Solaris / Irix) > > Note that an important condition for distros is what installation > options were used. For example, a pure-base SuSE > installation will not > include developer tools like gcc. Most distros also have installation > options which will end up lacking the -devel libs that > Inkscape needs to > compile. So each of these will require specification as to which > installation options must be used during setup. Argh, sounds complicated. The best thing, I suppose is to identify a maintainer by distro (ala Mandrake) and ask them to write down the specs for their respective distro > > Notice : should be automated (example see : > > http://public.kitware.com/Dart/HTML/Index.shtml) > > Interesting - have you used this system? Yes, that's why I was thinking about it :) But I'm trying to find even better and flexible > > - open Inkscape, launch reference editing sequence, > export result as > > bitmap and compare with a reference bitmap provided by a reference > > application on the same sequence (Inkscape itself for non > regression, Batik > > ?) > > Previous sequences can be combined in one in order to save > time, but then > > analysis of results can become more complex. > > Note, I developed a way using motion tracker software to calculate a > "percent similarity" rating given an Inkscape-generated png against a > Batik-generated png, that makes the analysis work easier. There's a > glitch that'll need to be worked out, in that the original > SVG's contain > the description in the image, which throws off the comparison. Simply separate analysis of pixels and metadata (I'm quite used to it : have worked on the dicom standard for 3 years) > > > Verification of robustness > > - testing memory leaks (not a specialist of this : I need help) > > This is an area where our work as testers is really cut out for us, > because there is a ton of memory issues in the codebase, and > we need to > be able to categorize in a way that makes them accessible to the > developers. Right now there's such an overwhelming number that > developers wouldn't know where to start, so if in testing we can > triage and prioritize the "top 10" or whatever, it would make > the fixup > work more tractable. Right. But in fact, as for unit tests, this part of the verification is hard to manage by testing team. It's mainly up to coders to operate this. Testing team can provide help (crash report, reproducibility of malicious scenarii...) but (for example in my case) are not code/design wizzards able to slalom in the memory/architecture maze. > > - provide a shaker tool (this tool would launch > Inkscape and then start > > a predefined number of pseudo-random commands -logging each > action). The > > goal is to detect crashes and analyse their conditions with the logs > > Another idea along these lines is to fire a variety of signals at it, > and detect if it behaves correctly. Just need a few precisions so that I understand better > Again, this plan looks very good, I'm looking forward to > this. I have a > feeling that since there is a *huge* amount of improvement we can gain > by taking a systematic approach to it like this. I think > it'll also be > very intriguing to figure out how to effectively meld systematized > testing with open source practices, and to see how much can be > accomplished in doing so. Ok, I'm pleased if you find the approach interesting. Regards, Matiphas

2 1

Re: Extension Proposal (First Draft)
by Gazal, Geraud (MED) 19 Jul '04

19 Jul '04

Hi Bryce, just need a small precision (paragraph 8.1) You mention plugins as loaded as dynamic objects (so/dll) ans thus being c/c++ (or somewhat compiled). I was wondering about let's say, something written in Python (because I appreciate this language, and because it is availabe on nearly all platforms). Python (or perl, ruby...) programs can nearly behave as dynamic objects. Would it be considered as a script or a plugin ? Main only concern is will it be possible writting plugins in interpreted languages (small memory print, easier to develop/maintain, often more portable...) Regards, Matiphas

2 1

ATTENTION: libgc dependency
by MenTaLguY 19 Jul '04

19 Jul '04

Please note that sometime in the next few weeks we'll be introducing a dependency on the Boehm garbage collector (libgc), and that said library must be compiled with C++ support enabled. I'd encourage all packagers/autobuilders to investigate whether there will be any problems for them. -mental

2 1

Report for 2004-07-18 18:00 GMT-0500
by unknown＠example.com 19 Jul '04

19 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

6 5

AW: [Inkscape-devel] Plain svg format?
by Taraben, Adib 19 Jul '04

19 Jul '04

>On Sun, 2004-07-18 at 20:01, bulia byak wrote: >> Yes, and I'm thinking about _why_ this may be needed, and can only >> think of the two reasons above. > >IMO, the most fundamental (if not most common) reason is to yield an SVG >document which will validate against the SVG DTD. > >Having elements in any non-SVG namespaces would (afaiK) prevent that. > >Of course, I'm not really sure most folks care about DTDs much anymore, >given they don't play well with namespaces in general. > >-mental I care. In my special purpose inkscape is not only a drawing program but a (_THE_) svg-editor. Adib.

2 1

ATTENTION: gtkmm upgrade
by MenTaLguY 19 Jul '04

19 Jul '04

I've just comitted Aubanel's gtkmm upgrade patch. You will need to rerun autogen.sh. >From now on, libgtk+ >= 2.4, libsigc++ >= 2.0 and libgtkmm >= 2.4 are required for Inkscape. I have tried to carefully test and build, but this did require some autofoo changes I do not fully understand. So be aware, and if you have any problems please help me track them down and fix them. -mental

5 9

Plain svg format?
by Øyvind Hvamstad 19 Jul '04

19 Jul '04

Hi, I just dig this app. Good work. However, I have some problems with the new rdf metadata tags when storing plain svg in 0.39. It seems that no namespace declarations are present for rdf, dc and cc. Adding them to the top fixes the problem, but it's really a hazzle when you have some 30 figures in a thesis. :) I added these: xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" You probably know this already, but if not.. Well.. Jimi needs valid xml! Inkscape rocks! (more than sodipodi :)) -- Øyvind Hvamstad <oyvind@...457...>

5 6

All tasks for 0.39 Milestone Completed
by Bryce Harrington 18 Jul '04

18 Jul '04

All of the tasks for milestone 5 "Inkscape 0.39" are now complete (the extension proposal was the last, oft-procrastinated item). I've moved all the completed Milestone 5 tasks to the PastMilestones page. Bryce

1 0

Proposal for Hard Freeze Process
by Bryce Harrington 18 Jul '04

18 Jul '04

As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase. During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary. For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases. Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis. Here's how the process would work: === Hard Freeze Phase === 0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker. 1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found. 2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point. 3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase. === Release Phase === 4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s). 5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms. 6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release. 7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose: a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case. 8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released. 9. Finally, announcements about the release are made. This also marks the end of the Release Freeze. 10. Normal development resumes. Bryce

3 5

tab -> 4 spaces
by Kees Cook 18 Jul '04

18 Jul '04

Is anyone interested it doing this to the source code? I made a test CVS tree to see how much would be changed. The file count is 565. :) I only processed files in /src, but it would be a giant commit. I personally find in valuable, but worry it would really disrupt other folks. On the other hand, doing it after a release seems like the best time to do it. Thoughts? -- Kees Cook @outflux.net

2 3

Re: [Inkscape-devel] Re: [Inkscape-devel] BUG and solution in align dialog
by bulia byak 18 Jul '04

18 Jul '04

> My SF name is o__b Done, you can commit your code now. Welcome to the team! :) > > One idea I had is this: Imagine you have a path consisting of strict > > horizontal and vertical segments, and you want to distribute (some of > > the) vertical segments (not nodes!) equi-spacely. I think it's a > > pretty common situation, but distributing _nodes_ will break the > > verticality of segments. So I propose to add a (perhaps optional) > > rule: If two or more nodes are aligned vertically (within some > > tolerance), consider them one node and move them as a whole during > > horizontal distributions, and the same for horizontal > > alignment/vertical distributions. Makes sense? > > > Looks weird to me, and could be surprising for the user. But I understand the > need for such a functionality. If we generalize a bit, this would be > distributing groups of nodes. But this is hard in terms of UI. Yes, what I propose is a subset of "distribute groups", and yes, fully generalized "distribute groups" is difficult to implement and may be overcomplex in terms of UI. Which is why I propose this special case - I think it's very common in practice and pretty intuitive once you get used to it. Just think of it as nodes "snapping together" when they're on one horizontal or vertical, so that distribution buttons treat them as a whole. This may be switched off by a checkbox in the align dialog (on by default, with the state remembered across sessions in a preference value). > > Another thing I always wanted to have is Random distribution. Maybe > > you can add it while you're working on that dialog, I think it should > > be easy enough? > > > > I'm not sure to understand what it means. Just throw each node on an random > position, or keeping the order and randomize the step size, or even > distribute against a distribution function (gaussian, poisson, etc.) ? In fact there may be many various approaches to randomization, but for practice, what I think will be the most useful is two buttons: Shake and Shuffle. 1. Shake: Each selected object moves by some small random distance from its current position. Here a Gaussian distribution would be appropriate, so that small displacements are more frequent than large ones. The default radius might be 0.05 of the total span (span == the distance between the outermost selected object), with this value ("the force of the shake") settable in preferences. Shake may sometimes change the order of objects if they're close together, but normally it will not. If you need a stronger shake, just keep pressing the Shake button. 2. Shuffle: All objects are placed at random points within the entire span between the outer objects. This does not preserve the order of the objects, but shuffles them like cards in the pack. For example, if you have a row of equispaced objects and you want to change their positions randomly but keep the equispaced distribution, you press Shuffle and then Distribute equispaced to space them evenly again. Note: it is obvious that the overall span of the objects will keep getting narrower if you press Shuffle repeatedly. I'm not sure if this is a problem that we have to live with, or it makes sense to try to compensate for it by artificially expanding the span before shuffling so that, _on average_, the span stays the same across many subsequent shuffles (it's an interesting mathematical problem, by the way - how much we need to expand the span for this condition to satisfy). Also note: in the above, "objects" may be nodes (in node tool) or object centers (otherwise); I don't think we need separate shake/shuffle buttons for left/right edges. However, when calculating the span, it makes sense to measure it between the outer edges of the bboxes of the outer objects, not between their centers. Let me know what you think of this plan. > Done. I'm just wondering why so many enums are anonymous and you pass plain > ints as parameters ? No idea, maybe just Sodipodi legacy... > > > Yes. But as we will refactor all the dialogs, that should be > > > the right time to do it. The only thing needed is to make > > > each dialog inherit from a class. > > > > That's a good idea, as currently there's much shared code that can be > > moved to the parent class (delete/destroy handlers, etc.). Some of the > > shared code is already factored out into dialog-events but not all. > > > OK, I'll look at this. Obviously what needs to go into that class is all the standard global variables in all dialog files (x, y, w, h, dlg, etc.).

2 1

gtkmm 2.4
by MenTaLguY 18 Jul '04

18 Jul '04

Now that we've branched for the release, HEAD is unfrozen. I think my first bit of work will be to merge Aubanel's gtkmm 2.4 patch sometime in the next few days. If this will cause undue problems for anyone, please scream now. -mental

4 6

RPM packaging issue
by Bryce Harrington 18 Jul '04

18 Jul '04

Btw, there was one issue I found in the inkscape.spec file that other RPM packagers will need to look to as well: * Remove the following line from the spec file: %{_libdir}/inkscape/extensions/* We have consolodated extensions into the /usr/share/inkscape directory with the other data files. Bryce

2 2

Crash on editing a circle
by Mike Hearn 17 Jul '04

17 Jul '04

Hi, I have a reproducable crash on CVS from a few days ago, when doing the following: * Start Inkscape * Zoom in a bit on the blank canvas * Add a new circle (made whole) * Press ctrl+shift+f (fill/stroke dialog). Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087436352 (LWP 15995)] 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 256 ~basic_ios() { } (gdb) bt #0 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #1 0x080b15c8 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #2 0x0814be5a in sp_marker_prev_new(unsigned, char const*, SPDocument*, SPDocument*, char*, NRArena const*, unsigned, NRArenaItem*) (size=22, mname=0x87534a0 "Arrow1M", source=0x83134a8, sandbox=0x8313470, menu_id=0x822f56b "marker-start", arena=0x87db328, visionkey=7, root=0x875f600) at sp-object.h:173 #3 0x0814c51a in sp_marker_list_from_doc (m=0x8647700, current_doc=0x8313400, source=0x83134a8, markers_doc=0x0, sandbox=0x8313470, menu_id=0x822f56b "marker-start") at dialogs/stroke-style.cpp:1008 #4 0x0814c9b6 in ink_marker_menu (tbl=0x88c1e58, menu_id=0x822f56b "marker-start", sandbox=0x8313470) at dialogs/stroke-style.cpp:1126 #5 0x0814da4e in sp_stroke_style_line_widget_new() () at dialogs/stroke-style.cpp:1532 #6 0x081481cf in sp_object_properties_dialog() () at dialogs/object-properties.cpp:216 #7 0x081a00aa in sp_action_perform(SPAction*, void*) (action=0x879a3d0, data=0x0) at helper/action.cpp:132 #8 0x0809dcc6 in sp_shortcut_invoke(unsigned, SPView*) (shortcut=50331718, view=0x858b130) at shortcuts.cpp:33 #9 0x081a2816 in sp_window_key_press (widget=0x894c468, event=0x0) at helper/window.cpp:34 #10 0x405c427c in _gtk_marshal_BOOLEAN__BOXED (closure=0xbffff2d4, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8, marshal_data=0x0) at gtkmarshalers.c:82 #11 0x40884dd6 in g_closure_invoke (closure=0x894c450, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8) at gclosure.c:437 #12 0x4089698a in signal_emit_unlocked_R (node=0x831c268, detail=0, instance=0x894c468, emission_return=0xbffff260, instance_and_params=0xbffff2c0) at gsignal.c:2506 #13 0x40895a21 in g_signal_emit_valist (instance=0x894c468, signal_id=0, detail=0, var_args=0xbffff450 "h\2240\bx}\213j@...455...") at gsignal.c:2205 #14 0x40895eab in g_signal_emit (instance=0x894c468, signal_id=52, detail=0) at gsignal.c:2239 #15 0x406a8ebc in gtk_widget_event_internal (widget=0x894c468, event=0x8974620) at gtkwidget.c:3563 ---Type <return> to continue, or q <return> to quit--- #16 0x405c2a16 in gtk_propagate_event (widget=0x894c468, event=0x8974620) at gtkmain.c:2318 #17 0x405c1857 in gtk_main_do_event (event=0x8974620) at gtkmain.c:1582 #18 0x4079844a in gdk_event_dispatch (source=0x0, callback=0, user_data=0x0) at gdkevents-x11.c:2133 #19 0x408d1384 in g_main_dispatch (context=0x82c0000) at gmain.c:1895 #20 0x408d2349 in g_main_context_dispatch (context=0x82c0000) at gmain.c:2441 #21 0x408d266e in g_main_context_iterate (context=0x82c0000, block=1, dispatch=1, self=0x82c24c0) at gmain.c:2522 #22 0x408d2bd6 in g_main_loop_run (loop=0x8982d68) at gmain.c:2726 #23 0x405c11cb in gtk_main () at gtkmain.c:1172 #24 0x08089ead in sp_main_gui(int, char const**) (argc=1, argv=0xbffff6f4) at main.cpp:311 #25 0x08089d24 in main (argc=1, argv=0xbffff6f4) at main.cpp:233 thanks -mike

9 15

Test strategy
by Gazal, Geraud (MED) 17 Jul '04

17 Jul '04

Hi all, here is my workaround for the testing strategy of Inkscape. (sorry it's a copy paste of my doc in the mail, I can forward you the rtf document if you want)(easier to read) I'm currently listing the "specifications", in order to have a reference of features to be tested. The main things that should be defined if you agree with this : - establish a test process - establish communication/coordination tools (wiki / specific web page /mail list ?) - prepare/review specifications,test tools and test cases - begin tests Regards, Matiphas Preliminary note: This is a preliminary/draft document for defining a test strategy for Inkscape projet (http://www.inkscape.org) It is currently in Rich Text Format (rtf), for easy exchange purposes. -> Don't know yet how to manage this document (Dookbook ? Open Office)(specific web page ? wiki ? cvs ?) -> Any way this document will split for the following reasons : - separate specifications of software, test strategy, test traceability, test items, test results... - ease of maintenance - separation of features under test At the moment, it is mainly architectured according to the categories of bug tracking under sourceforge tool for Inkscape (see http://sourceforge.net/tracker/?group_id=93438) Reference: Inkscape testing framework: http://www.inkscape.org/cgi-bin/wiki.pl?TestingFramework (Missing) Inscape "specifications" (not really a pure specification of the software, this would be incompatible with the development process of Inscape, but somewhat a hierarchised and detailed list of features to be tested) Introduction: Why testing ? Just to ensure quality of the software (does it suits user needs ?) and even better the quality of the code/design What are the important concepts of testing : - measure: metrics (specifications and comparison to those specifications) are needed. This is important for the homogeneity of the tests and the correct interpretation of their results - coverage: what are the areas (design / code / features / architectures) covered by the tests. Stronly linked to the efficiency of the testing process - repeatability/reproducibility. The tests must provide coherent results, in order to to be correctly interpreted. Automatisation of the tests and well documented references (vocabulary, procedures...) help a lot. - periodicity: when shall the test be executed. This depends on the criticity, probability of bug and level of test. What is required for having efficient tests : - KISS : tests cases should be very simple in order to be easy to understand, easy to implement, and the results easy to interpret. - well maintained and documented Acronyms and abbreviations: (not used yet, but might become usefull) NA : Not Applicable TBD : To Be Done Levels of tests: Unit testing: at code level, providing tools/script in order to test classes/functions... Mainly depends on coding team Feature testing: the biggest part, and the largest amount of work. After definition of the features to be tested, establish precise test cases and execute them. Can be partially automated (see in this document) Non regression testing: the ability to check nothing has been broken in the code after important/critical development. Can be covered by feature and unit testing, but a non regression analysis after important/critical development is a great help. Plus after finding some new bugs covered by the test plan, prepare new test itemand ensure it covers properly the new bug. Reference tools: Purpose : define a list of reference tool against which the software should be compared. (especially for issues around import/export / rendering / printing / maybe UI) To be refined. At the moment : take a look at http://www.inkscape.org/cgi-bin/wiki.pl?OtherProjects SVG software Vector software Tests: Build Linux (Debian / Gentoo / Slackware / Mandrake / Fedora / Suse / Others) Windows (98 / 2000 / XP) MacOS (X) BSD (Free / Open) Other Unices (Solaris / Irix) Notice : should be automated (example see : http://public.kitware.com/Dart/HTML/Index.shtml) List of tasks : - establish a list of builders and link it with the architectures they can manage - establish a kind of "test contract" defining the tools to be used (compiler, dependancies, test report tool...) and the periodicity of the tests Import Bitmap Vector Export Bitmap Vector Printing Node editing Shape editing Transformations Color Management Internationalization Main tasks : - list the internationalization that are actively maintained - starting with http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeTerminology, prepare a good dictionnary covering the maintained languages (can be very helpful for the reading of test procedures), plus the vocabulary of the application (messages, menus, etc etc) - establish a list of users with the languages they can check and define a kind of "test contract" UI SVG compliance See in 'specifications of software' plus SVG specifications The main idea is to provide a large repository of reference "SVG files" and "editing sequences". then two types of actions : - open reference files with inkscape, export it as bitmap and compare with a reference bitmap provided by a reference application (Batik ?) - open Inkscape, launch reference editing sequence, export result as bitmap and compare with a reference bitmap provided by a reference application on the same sequence (Inkscape itself for non regression, Batik ?) Previous sequences can be combined in one in order to save time, but then analysis of results can become more complex. Performance "Speed benchmarking" (can be automated) - provide a list of criterias to be tested (time to launch, time to open complex docs, time to save complex docs, speed of scrolling, speed of application of different types of transformations) - provide a benchmark tool - establish a list of users with the architecture on which they use the software, then define a kind of "test contract" defining the tools to be used and the periodicity of the tests Verification of robustness - testing memory leaks (not a specialist of this : I need help) - provide a shaker tool (this tool would launch Inkscape and then start a predefined number of pseudo-random commands -logging each action). The goal is to detect crashes and analyse their conditions with the logs - testing against severe conditions (corrupted files / out of memory / out of disk space ...)

2 1

Re: [Inkscape-devel] BUG and solution in align dialog
by aubi＠...373... 17 Jul '04

17 Jul '04

>> BTW, I finished refactoring the align dialog to use gtkmm and more >>OO code. >> Now I'll add the align nodes features. > >How is it going to look in terms of UI? I think the most intuitive >would be to make it work on selected nodes when the node edit tool >is >active on the active desktop, and on selected objects otherwise. >This >way you need no additional buttons or switches in the dialog. > >Also it would be nice to disable all or some of the buttons >depending >on what is selected. Thus, if no objects or only object is selected, >all align/distribute buttons are grayed out; if several nodes are >selected, "distribute top/bottom/right/left" are disabled because >they >make no sense for sizeless nodes (only distribute centers and >equi-spaced remain). That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor). To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop. >> I also would like to talk about the possibility to use the dialogs >>like in >> gimp2 (drag and dropable notebook tabs, multiple instances of the >>same >> dialog, etc) >> I started a very simple implementation, but I'm not sure you want >>to do that. >> Now I'm used to it, I find it easier to remember keyboard >shortcuts and have >> transient dialogs. No mess with tabs. PLease let me know your >>opinions. >Draggable notebook tabs may be a good idea - it will let one combine >all the tabs used frequently into one dialog and have only that >dialog >open, thus saving space. But it's likely to be rather difficult to >implement, it will very much disrupt our old dialogs code. > Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class. For me the main question is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ? >Multiple instances of the same dialog does not sound like a good >idea >at all. I think it will be just confusing without any advantage. OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one. I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ... ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

Inkscape Status July 15, 2004
by Bryce Harrington 17 Jul '04

17 Jul '04

Inkscape 0.39 has been released! It has been amazing to watch everything coming together over the past few weeks. Users have been very attentive to locating, reporting, and following up on wide ranges of bugs across an impressive range of platforms. Meanwhile developers have been grinding away at the bug list; the rate of bug fixing is astounding - it is not unusual for bugs to be fixed the day they're reported. The number of translations that have come in has also been impressive. Statistics Nov 15 May 15 Jun 15 Jul 01 Jul 15 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 930 845 (68.5%) (92.7%) (93.4%) (93.4%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 43 33 (99.6%) (99.8%) (99.8%) (99.8%) (99.8%) Total SF Page Views * 475,000 616,263 678,767 741,681 Total SF Downloads * 27,400 34,015 36,979 39,359 Total Freshmeat URL Hits 746 * 7,333 7,615 7,946 Total Freshmeat Subscriptions 16 74 87 91 93 Lines of Code in src/: 115,901 189,116 280,263 261,927 264,418 Code lines 147,471 210,119 190,519 192,240 Comment line 16,757 40,620 41,422 41,926 Blank 25,886 34,677 35,134 35,422 Lines of Docs in doc/: 1,135 4,544 15,170 15,201 15,217 Lines of content in website: 1,173 6,008 6,372 6,581 6,784 Size of the Inkscape wiki: 3,700 18,638 17,176 16,600 17,854 Minutes since last ChangeLog mod: 360 * * 28 54 Bugs open/total: 9/15 57/365 63/401 88/452 73/496 Features open/total: 18/18 183/238 210/285 222/307 242/331 Patches open/total: 1/ 6 4/ 83 5/ 88 6/ 91 8/110 CVS Commits (as per inkscape-cvs): 481 3391 5549 6033 6314 Inkscape-devel membership: 49 78 84 87 95 Inkscape-announce membership: 9 43 53 58 60 Inkscape-user membership: 71 76 84 90 Num Translations: Translated: 338 405 Fuzzy: 288 270 Untranslated: 349 325 Total number of PO files: 32 32 Ave Translation Ratio: 34.7% 40.5% * - Statistics unavailable

3 7

HELP WANTED: OSX packager for 0.39
by Bryce Harrington 17 Jul '04

17 Jul '04

Hi all, We have not had Mac OSX packages to provide in the past, but we'd certainly like to! OSX is an important platform for artists, and it would make sense for Inkscape to have a good presence there, as it does on Windows and Linux. Kees and others have verified that it builds and can be run on OSX, so the hardest part is done. The notes are available here: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape What we need is someone who can create a package that other OSX users can easily download and install. This probably doesn't require any coding know-how, but does require someone knowledgeable of fink and in compiling under OSX. If you're interested, please go ahead, and when you've got a working package, announce it here, and we'll add it to the Download area. :-) Bryce

1 0

[Fwd: Autopackage: fantastic, thanks.] (fwd)
by Bryce Harrington 17 Jul '04

17 Jul '04

---------- Forwarded message ---------- Date: Sat, 17 Jul 2004 12:42:28 +0100 From: Mike Hearn <mike@...333...> Reply-To: autopackage-dev@...375... To: autopackage-dev@...375... Subject: [Fwd: Autopackage: fantastic, thanks.] -------- Forwarded Message -------- From: Leland McInnes <leland.mcinnes@...456...> To: mike@...333... Subject: Autopackage: fantatsic, thanks. Date: Sat, 17 Jul 2004 03:01:08 -0400 Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Hi, I've been keeping vague tabs on the autopackage project as it looked promising, but mostly it was still in the "unstable API" stage, so wasn't really much to use to me as an end user. I was looking at the latest inkscape however, and noticed an autopackage install. I figured this was a good chance to actually give it a try. It worked flawlessly and elegantly and did everything I would expect of it. I look forward with great anticipation to the 1.0 version and a wide variety of packages available. This is exactly the sort of things linux package management desperately needs. Thanks for all the great work. Leland McInnes. -- "The bitter apple and the bite in the apple. And the ragged and restless waters" -- The Dry Salvages (Four Quartets), T.S. Eliot --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe@...375... For additional commands, e-mail: autopackage-dev-help@...375...

1 0

problems compiling in macosx
by Albert 17 Jul '04

17 Jul '04

Hi inkscapers Inkscape 0.38 compiled in MacOSX after djusting several details as I reported to the inkscape-users list some time ago. Now for 0.39: I have gone already over the gtkmm issue by doing what was suggested by Peter Moulder, that is change 'ink_gtkmm_pkg=gtkmm-2.0' to 'ink_gtkmm_pkg=' But just to find another issue: checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape I know my system has libpng 1.2.5 installed. Note that 0.38 compiled without complaining about this. I've noted the failing test in configure.in has not changed since version 0.38, so I'm pretty lost here. Here the last terminal output lines from ./configure before failing: ... checking GNU compiler version... 3.1 checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking for pkg-config... /sw/bin/pkg-config checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape Any help would be appreciated. Albert

3 7

One thing to do before a branch
by Bob Jamison 17 Jul '04

17 Jul '04

Whoever does the branch, I request you do one thing just before that. Please run: perl mkfiles.pl and perl mkdep.pl and commit make.* This will hopefully ensure that the tarball will compile under win32. Thanks. Bob

4 4

status?
by bulia byak 17 Jul '04

17 Jul '04

Looks like the freeze is going well, with nothing serious showing up. Is there anything preventing us from making a release, say, tomorrow? Actually, Ted, since you are our Release Technician (right? :) what is the best time for you to cut the release? Arpad, thanks for committing the translations. As for the assert, I think it's not very frequent, but its fix is likely to be too dangerous for so late in the freeze. I will fix it for the next version.

8 9

[Fwd: Re: siggraph?]
by Jon Phillips 17 Jul '04

17 Jul '04

Anyone in the LA area for SIGGRAPH. Here is a form for free exhibits + passes. I'm going to go on MONDAY AUG 9. If anyone is there, then we could do a BOFA on INKSCAPE, or just meetup for some rip-off expensive lunch or supper in rip-off-cost land. Jon > >https://reg.jspargo.com/siggraph04/invitations/general/default.asp > >Guest Password: 1208 > > -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

4 4

First experiences with 0.39pre4
by Wolfram Quester 17 Jul '04

17 Jul '04

Hi alltogether! Yesterday I prepared an inkscape package for debian unstable from 0.39pre4. Now, always when I start inkscape I get the message "Couldn't find helper" in my terminal window. Using strace doesn't tell me anything: 3911 access("/usr/share/inkscape/extensions/roundhole", F_OK) = 0 3911 access("/usr/bin/perl", F_OK) = 0 3911 access("/usr/share/inkscape/extensions/ill2svg.pl", F_OK) = 0 3911 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 3911 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30274000 3911 write(1, "Couldn\'t find helper\n", 21) = 21 Is this message just supposed to appear after the last extension is initialized or did I something wrong? Additionally yesterday I had to play with bézier curves. It seems that I forgot to close one of these or inkscape could not properly determine which area is enclosed by the curve. The whole canvas turned black and inkscape became inresponsive. To me, it looked like it was filling infinity and it was to busy with that to react to any keystroke or whatever. I had to kill it at least. The output in the terminal was wolfi@...453...:~/simu $ inkscape Couldn't find helper failed to load unicode charmap ** (inkscape:2508): CRITICAL **: file display/curve.cpp: line 578 (void sp_curve_closepath_current(SPCurve*)): assertion `curve->end - curve->substart > 2' failed Private normalization of gradient linearGradient7951 requested Changing object g7308 fill to gradient linearGradient7952 requested ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed I could not reproduce this with simple curves I drew today, so this is merely an information for you. Perhaps it helps. With best regards, Wolfi

9 23

Snapping
by Bryce Harrington 17 Jul '04

17 Jul '04

What is the difference between 'Snap to Grid' and 'Snap Points to Grid'? Bryce

2 5

Re: OSX packaging?
by Kees Cook 16 Jul '04

16 Jul '04

I asked a friend of mine about OSX packaging... I think we have a patch for a dmg, but I don't know what it means. :) ----- Forwarded message ----- Date: Thu, 15 Jul 2004 10:58:41 -0500 Subject: Re: OSX packaging? On Jul 15, 2004, at 08:10, Kees Cook wrote: >Hey, I want to try and get inkscape (inkscape.org) packaged for OSX. I >assume this is only possible via "fink", but I don't know where to >begin. How do I make an OSX package? :) There are two ways, really (maybe three): http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/Fi… 1) True Mac OS X way: drag and drop the .app from a .dmg file to your Application folder (or whereever else you want it) 2) More complicated OS X Way: Installer.app package. see Package Maker.app 3) UNIX way: fink. basically just a debian apt package. http://fink.sourceforge.net/doc/packaging/index.php If you want to target OS X users I would say 1 is the way to go. Otherwise 3. What are your dependencies? ----- End forwarded message ----- -- Kees Cook @outflux.net

5 6

Using imagemagick or graphicmagick as importer
by Tuukka Pasanen 16 Jul '04

16 Jul '04

Hi, I've been playing around about idea to provide support for Image/Graphicsmagick in inkscape. So we could import 88 Vector- and Imageformats used (http://www.graphicsmagick.org/www/formats.html or http://www.imagemagick.org/www/formats.html) but i been wondering should it been done like ill2svg or something deep cutting in inkscape code? Problem is that SVG output of programs isn't so good it should be. So what do you think? is this just a stupid idea? Tuukka ps. ImageMagick provides C++ bindings.. i think graphicmagick does also;)

2 1

Request for Adobe Illustrator files
by Tuukka Pasanen 16 Jul '04

16 Jul '04

Hi, Sorry about cross-posting.. but if anyone got AI files laying around (And have screenshot but it not must) that he/she could send me it/them to test ill2svg.pl. One could do it by Email (straight to me) or send URL to file (if file is bigger than 2M). I promise to use them only for testing ill2svg.pl script.. you can also create such documents if you have Corel Draw or Adobe Illustrator. Thanks, Tuukka

1 0

0.39 Release
by Bryce Harrington 16 Jul '04

16 Jul '04

Bulia has announced and finalized the 0.39 release, and Ted has established the release branch. What this means: * Packagers, please download the tarball and begin making packages * We will put out an announcement within a few days, once we've got some key packages up there. * We are in Release Phase. You can commit to CVS HEAD openly, but try to limit work to bug fixing for a couple days, just in case. * Users, please download and try out the packages as soon as they're ready. Let the packagers know of successful / unsuccessful installs. Congrats everyone! Bryce

1 0

no wimp please
by bulia byak 16 Jul '04

16 Jul '04

0.39 is up on SF. Whoever will be doing the windows package, please do not include gtk-wimp. The reason is that it gives me a lot of warnings about missing MS Sans Serif fonts. All these warnings flood the console window which therefore always jumps to the top and makes the program almost unusable. This is on windows 98. Normal builds without gtk-wimp work OK. I mentioned this on jabber but just want to reiterate. It's a nice thing but needs more testing before we can use it.

1 0

Linux Format Magazine has an article on Inkscape
by Alan Horkan 16 Jul '04

16 Jul '04

Linux Format Magazine has an article on Inkscape http://www.linuxformat.co.uk/ It has a strange lead in, I think they must have a regular section for the Gimp or something because of the way it is presented in relation to the Gimp. I only very quickly skim read the article (I'm not currently gainfully employed and have only pennies to my name) but it seemed favourable overall. I noted in particular that he found the user interface to be friendly. He mentions the Boolean operators and quotes one of the developers as having said that in the last while 'inkscape has improved 100%' (or suchlike). The article was written by Michael J. Hammel who appears to also be the author of "Essential Gimp for Web Professionals" and owner of the site http://graphics-muse.com/ and this page http://freshmeat.net/~mjhammel/ (his connections to the Gimp would explain the odd context of the Inkscape article). Perhaps someone might contact him and encourage him to write more about Inkscape. (Recommend some topics and I might try my hand at writing an article about Inkscape if I had a place to start). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

3 4

OSX Compiling howto
by Kees Cook 16 Jul '04

16 Jul '04

If you need to run "./autogen.sh": fink install automake1.8 autoconf2.5 Otherwise: fink install \ intltool \ glib2 glib2-dev glib2-shlibs \ gtk+2 gtk+2-shlibs gtk+2-dev \ libpng3 libpng3-shlibs \ libtool14 libtool14-shlibs \ libpng-shlibs \ libsigc++12 libsigc++12-shlibs \ popt popt-shlibs export CPPFLAGS=-I/sw/include export LDFLAGS=-L/sw/lib # Run ./autogen.sh here if things break below... ./configure --prefix=/sw echo "#define ENABLE_NLS" >> config.h make make install -- Kees Cook @outflux.net

2 2

Adobe SVG Viewer 1.0 problems
by Alan Horkan 15 Jul '04

15 Jul '04

I had a problem getting _any_ of the SVG files from OpenClipart.org to display and thought I had stumbled on to a huge problem. Much later I realised that problem only effects Adobe SVG Viewer version 1.0 and updating to Adobe SVG Viewer version 3 made the problem seem to go away. After a lot of trial and error I was able to get the documents to display by removing the non-essential parameters from the opening <svg> tag Sample from OpenClipart.org Balloon_01.svg: <svg id="svg548" sodipodi:version="0.32" width="400pt" height="400pt" sodipodi:docbase="/home/nicu/svg_gal/happy/" sodipodi:docname="/home/nicu/svg_gal/happy/baloon1_01.svg" xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:xlink="http://www.w3.org/1999/xlink"> After even more trial and error I was able to narrow it down to just this line, the removal of which allows the file to display correctly: xmlns="http://www.w3.org/2000/svg" it can also be fixed by changing it to xmlns:svg="http://www.w3.org/2000/svg" Which looks to me more likely to be strictly valid and correct and I hope is the actual fix. Could someone please tell me if it is correct so because having gone to all the trouble of figuring out exactly what the problem was I'd like to finally submit a patch of my own to Inkscape (and then get back to poking holes in the Standard SVG). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

3 4

Italian translation
by unknown＠example.com 15 Jul '04

15 Jul '04

Hi! I'm a "new" user of inkscape and I saw that the italian translation is not complete, there many words/expressions that aren't translated. I would to translate... But, what have I to do?? Is the first time that I work on a project and I'm not a programmer :-)) Let me know, Sergej Ps: greetings from italy Pps: forgive my english! __________________________________________________________________ Tiscali ADSL Senza Canone, paga solo quello che consumi! Non perdere la promozione valida fino al 19 luglio. Per te gratis il modem in comodato e l'attivazione. In piu' navighi a soli 1,5 euro l'ora per i primi tre mesi. Cosa aspetti? Attivala subito! http://abbonati.tiscali.it/adsl/prodotti/640Kbps/

3 2

export issues on windows - Bug 990349
by John Cliff 15 Jul '04

15 Jul '04

Hi folks, Bulia got me looking into ai import yesterday, and led me to realise that the import/export stuff seems pretty broke here on win. the import/open dialogs dont show anything but svg and bitmap formats, and the save as lists 3 formats which dont seem to work (svgz, ai, and epsi) The real problem is the latter as they still appear in the file type selector, and give all the right indications of having worked, but dont actually create any files. So you can think you've saved something when you havent. Saving to one of them then closing the doc causes my inkscape to crash. If anyone out there can confirm this on a windows box, I'd appreciate it. If we can confirm this isn't my box then I think we need to do something about it before cutting 0.39. Easiest is to simply add some lines to makefile.mingw to delete the extensions which are broke on windows so they dont get installed when you do make dist. This would eliminate the appearing to work while not really, and the crash bug. Cheers John __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

6 7

inset path destroys clones.
by Christophe Combelles 15 Jul '04

15 Jul '04

Hello, I don't know whether it is a bug : - create an object (say, a square) - clone it with Alt-D - move the clone to see both objects - select the first original object - apply an "inset" or "outset" on it --> the clone disappears. with 0.39 pre4 on debian sid regards Christophe Combelles PS : please note I'm not subscribed to the list.

4 4

critical assert
by Arpad Biro 15 Jul '04

15 Jul '04

Hi, This gives critical assert with current CVS (and earlier versions also): 1. draw 2 objects 2. drag one of them over the other, but do not release the mouse button 3. press Esc Arpad Biro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

problems compiling in macosx
by Albert 14 Jul '04

14 Jul '04

Hi inkscapers Inkscape 0.38 compiled in MacOSX after djusting several details as I reported to the inkscape-users list some time ago. Now for 0.39: I have gone already over the gtkmm issue by doing what was suggested by Peter Moulder, that is change 'ink_gtkmm_pkg=gtkmm-2.0' to 'ink_gtkmm_pkg=' But just to find another issue: checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape I know my system has libpng 1.2.5 installed. Note that 0.38 compiled without complaining about this. I've noted the failing test in configure.in has not changed since version 0.38, so I'm pretty lost here. Here the last terminal output lines from ./configure before failing: ... checking GNU compiler version... 3.1 checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking for pkg-config... /sw/bin/pkg-config checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape Any help would be appreciated. Albert

1 0

Today's autobuild
by Bob Jamison 14 Jul '04

14 Jul '04

Good morning, all! Since we are frozen, it is impossible to sync the makedep files and adjust paths for compilation, so autobuild will likely not run until the cut. So I did created a manual autobuild (oxymoron intended) this morning. It is on the site. After talking yesterday about syncing with the Makefile.am files, and running a script to generate a .def for making a .dll, I am thinking about requiring Perl for Win32 builds, both on Linux cross-compiling, and on native Windows. Windows users can download ActivePerl. I use it; it is very nice. I hate to add a dependency, but I think it is necessary. What we will likely do is: 1) In src/Makefile.mingw, add a dependency to all of the Makefile.am's in the /src dir. If any of them are touched, implying that files might have been added or deleted, then run mkfiles.pl and mkdep.pl. 2) After libinkscape.a is created, run mkdef.pl, which generates inkscape.def. This .def allows exporting the global symbols in our code without adding those nasty __declspec(dllimport) tags all through the .cpp files. 3) Create inkscape.dll 4) Create inkscape.exe and inkview.exe, both of which will use the dll. This will allow these two and other client apps of the dll to be packaged in the .zip without noticeably increasing download size. This will also eventually aid in providing that "inkscape widget" that other projects seem to want. After the cut, I will update mkfiles.pl with a "new improved" version that allows excluding directories, in addition to files. Just some thoughts. Later! Bob (ishmal) Bob

2 1

Metadata tab localization
by Arpad Biro 14 Jul '04

14 Jul '04

Hi, The captions and tooltips on the Metadata tab (in document prefs) seem to still not be localizable (except for 2 of them: "License" and "Proprietary"). Gettext does extract all the strings, but the translations aren't used on the UI. Arpad Biro __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

2 2

import pdf, ps, eps pstoedit scribus
by John Griessen 14 Jul '04

14 Jul '04

I've searched and found pstoedit makes a partial import of pdf to svg, and several other perl scripts and postscript programs that choke on some pdf content when converting to ai or ps even. What I was looking for was a method of rearranging print articles from current magazines for my own use with margins to make notes in, and with editing and condensing in mind. Is pstoedit, (the gpl part), the best there is now? Can ps2ai be made to not die so easily? Since pstoedit has the best error handling even though output is not just right, is anyone interested to take the source of it and add more? Many pdfs are intended never to be editable, but often legitimate work is going to start with pdfs since adobe made them so popular by effective promotion and "free as in beer" viewers that worked. A big area of legitimate work is in catalogs whose typesetters are nowhere to be found, or not offering their editable layouts, or the layouts are made with ancient Mac SW that no one has anymore, and yet the paper catalog data needs to be mined for starting an online store web catalog. See the inkscape wiki under tutorial ideas for a couple of new images related to pstoedit -f plot-svg John Griessen -- John Griessen Cibolo Design Austin Texas linux counter #249315

2 1

[Fwd: [Inkscape-user] need help to compile inkscape 0.39 in macosx]
by MenTaLguY 14 Jul '04

14 Jul '04

-----Forwarded Message----- From: Albert <albert@...452...> To: inkscape-user(a)lists.sourceforge.net Subject: [Inkscape-user] need help to compile inkscape 0.39 in macosx Date: Wed, 14 Jul 2004 00:04:30 +0200 Hi all I'm trying to compile inkscape-039pre4 in macosx and I'm running into this problem: No package 'gtkmm-2.0' found configure: error: Library requirements (gtk+-2.0 >= 2.0.0 libxml-2.0 >= 2-2.4.24 sigc++-1.2 gtkmm-2.0 ) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. I know I have gtkmm1.2 installed and than I need then to install 2.0, but the question is: inkscape 0.38 did NOT require neither gtkmm1.2 nor 2.0. I thought this would be necessary from 0.40 and onward, not before. When was this changed, or what did I miss? Also, which gtkmm should I install: 2.0-2.2, or 2.4 ? Does anyone know if any of this 2 libs have any problems in macosx ? Thank you for any help. Albert ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-user mailing list Inkscape-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

2 1

2 Compile Issues
by Bob Jamison 14 Jul '04

14 Jul '04

Bryce told me to direct this to Mental or Bulia: Since we are clearing source changes now, I'll mention these two things that need tweaking. Nothing major, but they can break builds: 1. In satisfied_guide_cns.cpp, the prototype for void satisfied_guide_cns(SPDesktop const &desktop, std::vector<NR::Point> &snappoints, std::vector<SPGuideConstraint> &cns) ...needs to match the .h file. This can cause a linking problem in some situations, such as dynamic instead of static, or link order. 2. This one is my fault. I recoded prefix.cpp to use gthreads; it works nicely, but this file is not our responsibility. The original binreloc version needs to be put back. (OOPS. sorry) I'll not touch any sources until after the release :) Bob

4 3

configure patch
by Mike Hearn 14 Jul '04

14 Jul '04

Hi, The binreloc code uses gthread to achieve thread safety in the Inkscape tree, but gthread isn't passed to pkg-config. This patch fixes this. thanks -mike Index: configure.in =================================================================== RCS file: /cvsroot/inkscape/inkscape/configure.in,v retrieving revision 1.70 diff -u -r1.70 configure.in --- configure.in 11 Jul 2004 22:30:53 -0000 1.70 +++ configure.in 13 Jul 2004 16:42:58 -0000 @@ -221,7 +221,7 @@ dnl Unconditional dependencies dnl ****************************** -PKG_CHECK_MODULES(INKSCAPE, gtk+-2.0 >= 2.0.0 libxml-2.0 >= 2-2.4.24 $ink_sigc_pkg $ink_gtkmm_pkg $ink_spell_pkg) +PKG_CHECK_MODULES(INKSCAPE, gtk+-2.0 >= 2.0.0 libxml-2.0 >= 2-2.4.24 gthread-2.0 >= 2.0.0 $ink_sigc_pkg $ink_gtkmm_pkg $ink_spell_pkg) dnl Shouldn't we test for libpng and libz? INKSCAPE_LIBS="$INKSCAPE_LIBS -lpng -lz"

2 1

submitting freeze items
by MenTaLguY 14 Jul '04

14 Jul '04

I'd like to leverage the patch tracker to provide a work queue for bulia and me. To this end, I created an "0.39 FREEZE" tracker group. The proposed procedure is as follows: 1. create an entry in the patch tracker; if your change is complicated enough to warrant a patch, attach it. otherwise, just describe what you need done (as Bob did) -- make sure to select the aforementioned "0.39 FREEZE" group when you submit the entry. 2. also send an email to the mailing list so we can discuss the patch/change here 3. any updates/fixes to your patch go in the tracker item so they don't get lost -- be sure to include a note indicating the fix/change also 4. bulia or I can claim items to work on by assigning them to ourselves, and will close the tracker entry when the task is done Sound reasonable? -mental

1 0

Extra main() symbol
by Bob Jamison 14 Jul '04

14 Jul '04

Another Mental/Bulia thing: I have been working on the new build stuff for 0.40, such as making an inkscape.dll. This exercise in exporting symbols reveals some minor problems in our code, like I reported earlier. I just found another one. In the Win32 build, there is an extra main() being added to libinkscape.a. This is much easier to do manually than a patch. 1. Could you add this line: extension/script/js/js.c to src/make.exclude, 2. and then run perl mkfiles.pl and perl mkdep.pl 3. ...and then commit make.* (will be 3 or 4 files) Bob

2 1

Complete spanish po for 0.39
by Lucas Vieites 13 Jul '04

13 Jul '04

Do translations get into a hard freeze? Just in case, I finished the four or five pending strings in this file. Attached it goes... -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

4 6

Explicit destructor calls for libstdc++
by Aubanel MONNIER 13 Jul '04

13 Jul '04

Somebody knows why there are so many explicit destructor calls like : sp_desktop_dispose (GObject *object) { SPDesktop *dt = SP_DESKTOP (object); dt->sel_modified_connection.disconnect(); dt->sel_modified_connection.~connection(); dt->sel_changed_connection.disconnect(); dt->sel_changed_connection.~connection(); dt->_set_colorcomponent_signal.~signal(); Why not a simple delete (dt->sel_modified_connection); ?

2 4

Re: Bug Stats
by Bryce Harrington 13 Jul '04

13 Jul '04

Date Reqd Crit Open Total Ratio ----------------------------------------- 7/1 88 452 19.5% 7/4 8 89 464 19.2% 7/5 21 86 464 18.5% 7/6 19 85 464 18.3% 7/7 20 88 467 18.8% 7/8 13 81 471 17.2% 7/9 10 78 471 16.5% 7/10 3 9 78 478 16.3% 7/11 2 6 74 479 15.4% 7/12 1 6 70 483 14.5% ------------------------------------------ Goals 0 10 (71) (15.0%)

2 3

Text writing and font changing
by Tuukka Pasanen 12 Jul '04

12 Jul '04

hi, Inkscapes font editing capabilities are getting better but there is two major problems. At least for me. 1. One can't change font in middle of text (If inkscape is using pango this should be so hard) 2. One can't put text in textbox (so you can't say be this large and if your text is longer cut it to next row) Have someone thought about this. I could take and make part 1 but thing i don't know how to mark up things when font changes?? part 2 should also be doable? Tuukka

2 1

Required bugs to fix for 0.39
by Bryce Harrington 12 Jul '04

12 Jul '04

The following bugs have been identified as 'required fixes' for the Inkscape 0.39 release: 984902 (CLOSED) "paint-selector.cpp: patternmenu getting destroyed" 979858 (OPEN 9) "image xlink: pixmaps linked with relative path don't work" 978391 (OPEN 9) "Autopackage installation" 978250 (OPEN 9) "mkinstalldirs error." Bulia also mentioned some export dialog issues, but there isn't a ticket number associated with it yet, so it's unclear what the status is. I've reduced the other other critical bugs to level 8. Bryce

2 4

testing...
by Bryce Harrington 12 Jul '04

12 Jul '04

Is this thing on...?

1 0

Re: [Inkscape-devel] autopackage now requires explicit --enable-binreloc
by Kees Cook 11 Jul '04

11 Jul '04

On Sun, Jul 11, 2004 at 03:34:39PM -0700, Mike Hearn wrote: > On Sun, 2004-07-11 at 14:04 -0700, Kees Cook wrote: > > We've disabled binreloc by default so that some of the other developers > > aren't disturbed by it. In the meantime, if your nightly builds can be > > changed to add "--enable-binreloc" to the "configure" run, Inkscape will > > correctly compile binreloc. > > Yes, I modified the specfile to do that. I tracked it down to header > ordering - in some cases config.h was being included after prefix.h > which was redefining the relevant macros. I think it's fixed now - I > guess prefix.h including config.h would fix that too. > > As to -D flags vs config.h entries, well, I don't know enough about > autoheader/autoconf to comment I'm afraid so I'll let Hongli deal with > that. Whoops, I'm not on the list, can you CC me on replies? :) Bryce forwarded me your response. I have an updated patch that makes prefix.c C++ type-safe. As for the config.h entries, I'd love to see where autoheader is considered deprecated. At least according to the documentation from autoconf 2.59, I see no mention of autoheader going away. Using "make" to detect changes in your build system won't pay attention to -D flags, but it will see changes in the config.h. With large packages (like inkscape), I don't want to have to do a full recompile. Also, for the end user who is attempting to compile the program, they shouldn't have to know which files to delete or to do a "make clean" if they decide to change a "configure" option. I should be able to run "configure --disable-binreloc", "make", and then "configure --enable-binreloc", "make" and have things correctly rebuild. Without the config.h entries, this is not happening. If people aren't using config.h, then they won't have an "AM_CONFIG_HEADER"/"AC_CONFIG_HEADER" call in their configure.ac, so my patch stands: for those using CFLAGS, it will work. For those using config.h it will work. And neither will step on the others' toes. :) -- Kees Cook @outflux.net

1 0

Re: [Inkscape-devel] autopackage now requires explicit --enable-binreloc (fwd)
by Hongli Lai 11 Jul '04

11 Jul '04

Bryce Harrington wrote: > - The code for enable-binreloc=auto (which was previously the default) > checked the build environment rather than the execution environment. ??? What does this mean? > - autopackage code prevents running inkscape from the build directory. > (This problem is reduced if the source directory and the build > directory are the same.) > > It should fall back to using the configure-supplied PREFIX value. I don't think this is possible except if you explicitly code fallback functions in the application. > - br_locate uses sscanf("%x-%x") and unsigned ints whereas > linux/fs/proc/array.c uses printf("%08lx-%08lx") and unsigned > longs. This presumably leads to bugs on 64-bit platforms. That's because Mike's patch uses an old version of BinReloc. The CVS BinReloc uses unsigned longs and "%lx" (maybe I should change that to "%08lx" instead? not sure). > - br_prepend_prefix needlessly requires that its path argument be > writable. It doesn't. br_prepend_prefix doesn't modify the content of the path argument in any way. I just didn't use the 'const' keyword, that's all. ;) > - br_strcat uses calloc, only to write over the space. It in > effect calculates strlen(str1) 3 times and strlen(str2) twice. Should be fixed in the autopackage CVS now. > - br_strndup has buffer overflow if size excedes the length of str > by more than one. Thanks for the tip. Fixed in CVS now. > - br_extract_prefix doesn't behave as its documentation indicates. This is a typo in the documentation. Fixed. > Also it does an unnecessary strndup when it could use memrchr. I'm not sure which line exactly you're referring to.

4 4

Clarification of 0.40 tasks?
by Bryce Harrington 11 Jul '04

11 Jul '04

Could someone elaborate on what the following task items mean? In particular, I'm wondering if they still belong in the 0.40 release todo list. * Make clones respond sensibly to original duplication * Reenable fuzzy font matching * Make gradient management & chaining work similar to patterns ** Fix fill-opacity ignored with gradients * Implement "Select Under" * Complete the cursor icons set * Redraw old icons to look decent Thanks, Bryce

4 5

Bug Stats
by Bryce Harrington 11 Jul '04

11 Jul '04

Date Crit Open Total Ratio 7/1 88 452 19.5% 7/4 8 89 464 19.2%

1 9

SEGV & SIGABRT handlers
by Bryce Harrington 11 Jul '04

11 Jul '04

Kees, Do you feel that the handlers for SEGV and SIGABRT reliably auto-save and put up crash dialogs? This is an item on the roadmap for 0.40, but I think you probably already took care of it. If so, we can cross that item off the list. Bryce

2 2

svg align icons
by Aubanel MONNIER 11 Jul '04

11 Jul '04

just to let you know I attached new svg align icons to the patch tracker.

1 0

gtkmm and sigc++ version
by Aubanel MONNIER 11 Jul '04

11 Jul '04

Hi list, while trying to resolve some basinc problems I had with tentatives of gtkmmification, I jumped on the #c++ channel on irc.gnome.org, and founs very nice people explaining that we should not rely on a deprecated version of gtkmm and sigc++. So with their help I made the port to gtkmm2.4 (nothing to do, configure.in was ready) and libsigc++2.0, which took a bit more time. This does not fix my problem, but it works. So if anyone is interested, I can semd a patch. Let me know what the procedure is. Thx, obi.

4 7

Proposal for 0.39 freeze
by Bryce Harrington 11 Jul '04

11 Jul '04

It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound? 1. 'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing. 2. 'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features. 3. 'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in. 4. 'Release' Bryce

12 28

Update on release process
by Bryce Harrington 11 Jul '04

11 Jul '04

There are still a few remaining Must-Fix items prior to going into the Hard Freeze, so we'll be giving it a bit more time. Hopefully by the end of the weekend we'll be ready. Tomorrow morning, I will send out a proposal for how to conduct the Hard Freeze segment of the release process. Bryce

1 0

Check ReleaseNotes
by Bryce Harrington 11 Jul '04

11 Jul '04

Just as a reminder, everyone who has done work on the codebase between 0.38.1 and now, please go review the ReleaseNotes and doublecheck that those changes are accounted for. Minor bug fixes, optimizations, etc. can be omitted, but it's worthwhile to include anything major, both for educating users about the new stuff, and for testing/troubleshooting purposes. http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes Thanks, Bryce

4 4

libccc: criawips' cairo-based canvas (using gtkcairo)
by Sven Herzberg 10 Jul '04

10 Jul '04

Hi all, I just started to play around with gtkcairo because I got stuck with some limitations of the gnome-canvas that I hope to be able to solve when developing a cairo based canvas. My current aims are: * get a high level canvas using cairo * get rid of issues like we have in gnome-canvas (e.g. text cannot zoom) * have a gnome-canvas-like api * use gobject interfaces for some things and lots of signals to make extending more easy (e.g. 'zoom canged' signal would have helped to fix the GnomeCanvasText things) I'm playing around within the criawips CVS repository on cvs.gnome.org. There's neither something that works yet nor much stuff, I just want to tell you about my plan to be able to get feedback before I introduce some issues that you had with something similar. The code is located in the criawips/src directory and consists of the cc-* files. Regards, Sven PS: I hate cross-postings, please continue this thread within criawips-devel@...448... and DO NOT reply to other lists. Thank you -- Sven Herzberg <herzi@...449...> · GNOME Deutschland <www.gnome-de.org> Jabber <herzi@...450...> · ICQ <177176642> GnuPG Fingerprint: <F020 B158 2696 6D6A 2870 F53C 0565 FD6B B1C3 0AFE>

1 0

export to bitmap: very bad behaviour
by Artemio 10 Jul '04

10 Jul '04

Hello all! I noticed several changes in the recent snapshot (20040706) that make my work much slower. 1. The exported image name defaults to drawing.svg.png instead of drawing.png. What is this for? Generally, you'll want shorted and simpler names, just drawing.png. Currently I have to delete the .svg portion each time. 2. The behaviour of the export dialogue is inconvenient. One thing it should be able to do IMHO is to detect whether a selection is active and automatically set the export mode to selection. 3. Also, compared to a snapshot of 20040628, Inkscape forgot how to update the export x/y/size on the fly. For example, I have three drawings on a single canvas and I want them exported to drawing[123].png. Previously, I could fire up the export dialogue, and hit export three times while selecting different drawings and changing 1 to 2 and then 2 to 3 in the target file name. In the current snapshot, if I change a selection while the export dialogue is up, the selection range is not updated. So if I want to do what I explained, I have to select a drawing, then hit "selection", then adjust the file name and hit export. This adds one exrta action which makes you work longer. I think the export x/y range should update on the fly. Just my 2 cents ;-) Artemio.

4 3

Working locally
by Gazal, Geraud (MED) 09 Jul '04

09 Jul '04

As my home internet connection is not up at the moment, I was wondering if there was a way for easily downloading the complete list of RFEs and Bugs in order to be able to read/sort it locally... Anyone having already done this ?

4 4

Updated spanish po
by Lucas Vieites 09 Jul '04

09 Jul '04

Hi, attaching updated spanish po. Will there be a 'translation freeze' before the 0.39 release so we can have translation at 100%? And now for something completely different: I found at least two strings containing "sodipodi" in the po file. Is this correct? msgid "Could not create sodipodi-svg-doc factory" msgid "Export document to plain SVG file (no sodipodi or inkscape namespaces)" -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

4 3

AW: [Inkscape-devel] isnan
by Taraben, Adib 09 Jul '04

09 Jul '04

>> isnan without the std:: qualifier doesn't compile for me on mingw gcc >> 3.2.3. Are we going to need a platform-specific hack here? > Same for me (cross-compiling). Is there a way to change is so that > everyone is happy? using namespace std ??? Adib.

5 5

autopackage now requires explicit --enable-binreloc
by Peter Moulder 09 Jul '04

09 Jul '04

The autopackage code has the following problems: - The code for enable-binreloc=auto (which was previously the default) checked the build environment rather than the execution environment. - autopackage code prevents running inkscape from the build directory. (This problem is reduced if the source directory and the build directory are the same.) It should fall back to using the configure-supplied PREFIX value. - Also, there are a few problems with prefix.cpp code that make me wonder what other problems the autopackage code has: - br_locate uses sscanf("%x-%x") and unsigned ints whereas linux/fs/proc/array.c uses printf("%08lx-%08lx") and unsigned longs. This presumably leads to bugs on 64-bit platforms. - br_prepend_prefix needlessly requires that its path argument be writable. - br_strcat uses calloc, only to write over the space. It in effect calculates strlen(str1) 3 times and strlen(str2) twice. - br_strndup has buffer overflow if size excedes the length of str by more than one. - br_extract_prefix doesn't behave as its documentation indicates. Also it does an unnecessary strndup when it could use memrchr. Therefore I've changed configure.in to default to enable-binreloc=no. Autopackage binary builders, you may wish to add --enable-binreloc to your configure options. pjrm.

2 1

"layers"
by MenTaLguY 09 Jul '04

09 Jul '04

I think I've fixed most of the layer-related bugs I could find now. If you guys could give the "Edit group" feature a workout and see if there's anything I missed... (I think I still need to add transformation compenstation to Paste, at least) -mental

3 2

Re: [Inkscape-devel] Joining and help on gtkmm
by aubi＠...373... 09 Jul '04

09 Jul '04

On Wed, 2004-07-07 at 13:33, bulia byak wrote: > > this code works > > Gtk::Image *pImg= new Image ("/x/y/z/toto.png"); > > > > while this one don't > > Gtk::Image *pImg= new Image > > (Gdk::Pixbuf::create_from_file("/x/y/z/toto.png")); > > Judging by http://www.gtkmm.org/gtkmm2/docs/reference/html/classGtk_1_1Image.html, > both uses are valid. But we haven't yet used Gtkmm in this project so > I can't tell. Mental, can you comment? As far as I know both examples are valid (and should be essentially interchangable), but I've not tried either. There are occasionally some gotchas which the documentation does not make clear. Aubi, does "doesn't work" mean that it doesn't compile, or that it misbehaves when run? What are the error messages or deviations from expected behavior you encounter? -mental The failure is at run time. As far as I remember (I doesn't have my machine right now), there is an assertion on the Pixbuf, something like could not bind pixbuf. And of course, nothing is displayed. Talking about GTKmm doc, I was wondering if we could put it in a wiki, this way we could add comments as we gain experience. I also have more general questions about gtkmm ification and widgettery. Do we try to redo custom widgets (ie inheriting from drawables) for the SPIcon and SPButton thingies, or do we provide static Images widgets with the according content (ie pixbuf) already loaded ? I would vote for the second solution as I remarked an important performance hit since we display SVG icons in eg the Fill dialog. The result would be something like class SVGIcons { public : const Gtk::Image & get (std::string name); private : static const Gtk::Image &icon1; static const Gtk::Image &icon2; static const Gtk::Image &icon3; etc ... } ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

Re: inkscape - tspan - baseline-shift
by bulia byak 09 Jul '04

09 Jul '04

> Dear Mr. Buliabyak, thank you for the explanation of the complexity of > implementation of the "baseline-shift" tag and tspan sections into > inkscape. I'm ready for helping with the development of the application, > but there is one big obstacle: I can't do C language. There are many ways to help other than coding: testing, documentation, discussions... > I understand, that you - and the development team as well - are not > interested in the text part of SVG. This is wrong. We are doing a lot for text. Since we forked from Sodipodi, we added letterspacing and kerning, and recently switched to Pango for much better Unicode text support (not counting hundreds of bugfixes). All this is necessary for any further improvements of text support. > As the SVG is only suitable vector graphics format, many chemical > structure drawing programs have export to the SVG. And as we need some > other graphic elements (frames, boxes, splines) when we prepare chemical > structures for the presentations or publications, the only way is usage > of some vector graphic editor. Chemical structures are made of thin > lines, the chemical bonds, and the export to the raster image degrade > such lines completely. But alas, almost every such chemical structure > include the subscripted text. There is no way through. Right now you can approximate sub/superscripts by vertical kerning. For example type "H2O", position text cursor before 2 and press Alt+down a few times, then move after 2 and press Alt+up a few times. The only problem with this method is that you can't make "2" smaller than "H". See http://inkscape.org/screenshots/gallery/inkscape-0.38-linux-kerning.png for an example of what is possible using kerning. > I do not understand the reason for existence of two similar projects on > the sourceforge, inkscape and sodipodi. See the FAQ on our site. In short, Sodipodi was too closed and inflexible so we had to start a new project from Sodipodi codebase so we could all work freely on what we wanted to see in a vector editor. > I look into the sodipodi source code and in my opinion to extend the > tspan routines is not such a big problem (if you don't need GUI for > editing of tspans, but only the interpretation of it when drawing on the > canvas). Yes, the rendering part is easier to do, but what is the use if you cannot create a subscript except by manual XML editing?

2 1

isnan
by Carl Hetherington 09 Jul '04

09 Jul '04

Hi, isnan without the std:: qualifier doesn't compile for me on mingw gcc 3.2.3. Are we going to need a platform-specific hack here? Carl -- http://carlh.net/pony

2 1

Joining and help on gtkmm
by aubi＠...373... 08 Jul '04

08 Jul '04

Hi list, as a convinced Inkscape user and former C++ developper, I decided to at least try to join the developpment team. I don't want to promise anything, as real life work keeps me quite busy, but sure I could spend a few hours a week on it. So I pulled the code from cvs and started to look at something intersting me : aligning nodes. Well, this is C code. I'm not a great fan of C, so I wanted to start the C++ ification of the align dialog. And still pulling away, fall in front of SPButton and SPIcon. I first tried to wrap (GtkButton::wrap for example) them, but could not get it working. So I went deeper and figured that it could be a good idea to take it at the pixbuf level. But I can't understand how this works, even with a simple png image : this code works Gtk::Image *pImg= new Image ("/x/y/z/toto.png"); while this one don't Gtk::Image *pImg= new Image (Gdk::Pixbuf::create_from_file("/x/y/z/toto.png")); Looks like I missed something ... If you have some answers, or even pointers (google is not very talkative about this), please post them in my blog here : http://un.regne.net/dotclear/index.php/2004/07/01/20-firsts-tries-on-inksca… sorry for the inconvenience, I'm in trouble with my email setup. Thanks in advance for any answer, aubanel. ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

3 2

RE: [Inkscape-devel] General and Specific Meta-Data
by unknown＠example.com 07 Jul '04

07 Jul '04

> On Wed, 7 Jul 2004, Jon A. Cruz wrote: >> >> >> XMP >> >> >> XMP > > We left implementation of that for you... ;-) Why, how kind and thoughtful of you. Thanks. :-D (look for things after the thaw)

1 0

RE: [Inkscape-devel] General and Specific Meta-Data
by Jon A. Cruz 07 Jul '04

07 Jul '04

> -------- Original Message -------- > Subject: Re: [Inkscape-devel] General and Specific Meta-Data > From: "Bryce Harrington" <bryce@...260...> > Date: Sat, July 03, 2004 11:27 pm > To: "Kees Cook" <inkscape@...62...> > Cc: "inkscape" <inkscape-devel(a)lists.sourceforge.net>, "clipart-list" > <clipart@...330...> > > On Sat, 3 Jul 2004, Kees Cook wrote: > > On Sat, Jul 03, 2004 at 08:40:07PM -0700, Jon Phillips wrote: > > For now, I just want to get the "General" RDF editor working. :) > > *Nod* Agreed - this will take care of 99% of the cases; the last 1% > will be more challenging. XMP XMP

2 1

RE: [Inkscape-devel] Polyline and polygon point specification patch submitted
by Jon A. Cruz 07 Jul '04

07 Jul '04

> -------- Original Message -------- > Subject: [Inkscape-devel] Polyline and polygon point specification > patch submitted > From: "Mark Nyrup Mortensen" <nightcap@...58...> > Date: Fri, July 02, 2004 10:44 pm > To: inkscape-devel(a)lists.sourceforge.net > And then another question somewhat related to the patch (and probably > other places in Inkscape?): > Does anyone know whether the "g_ascii_strtod" function actually is > capable of reading and returning numbers sufficiently large to allow for > the numbers available in SVG? From what I have seen so far i would say > no, but again my knowledge of C/C++ and GTK+ is fairly limited. Ahhh..... This is where I'd suggest getting it in the unit tests. Just find out the range that could be needed, and then set up tests for those on either side of any boundary. Of course, we'd probably have to have some unit test framework first to make it easy. :-) But, seriously, it is good to at least make a note of the range that it would need to support, allong with samples to exercise it.

2 1

RE: [Inkscape-devel] General and Specific Meta-Data
by Jon A. Cruz 07 Jul '04

07 Jul '04

> -------- Original Message -------- > Subject: Re: [Inkscape-devel] General and Specific Meta-Data > From: "Kees Cook" <inkscape@...62...> > Date: Sat, July 03, 2004 10:09 pm > To: "inkscape" <inkscape-devel(a)lists.sourceforge.net>, "clipart-list" > <clipart@...330...> > > > > I wonder how we can have it so that when an object or collection of > > objects is copied and pasted, imported and transformed, that its > > specific meta-data (beyond specified graphics attributes) can be copied > > along with itself (making a media object). In the future this will be > > vital for algorithmic composition of graphics. > > You could test for clashing licenses! Hah. > > > Thoughts? > > I'd need to read a lot more about RDF itself. For example, how do we > reference a specific SVG group or shape within the doc? > XMP?

1 0

RE: [Inkscape-devel] joining development
by Bryce Harrington 07 Jul '04

07 Jul '04

On Tue, 6 Jul 2004, Gazal, Geraud (MED) wrote: > > > As I really appreciate the tool you're developping, I'd really like to > > > contribute, as soon as my home internet connection is up again. > > > Ah, cool, welcome aboard. :-) > > Yeah, will subscribe to inkscape devel/user as soon as possible (damned > internet provider) Note that there's also a news feed available via gmane.org, if mail is an issue. > OK, there we are. I really want to help this project as it really helps me. > Here are the tasks on which I can help : > > - writing test plan (it used to be my job a few years ago) I've been (slowly) working on exploring some different aspects for testing Inkscape, and would love to work with you on this. So far our testing has been organic as opposed to systematic; planned testing likely could help identify issues more intently. > - translation : my English is not perfect (and my accent is terrible/fic), > but I'got some good dictionaries. I'm native French speaker (this can > explain the accent), correct in Spanish and German, poor in Slovak and Czech > (but my girlfriend is native :) ). Translators are always welcome. :-) I think we've got people involved in all those languages, but the translations may benefit from additional sets of eyes. > - doing some tests This is definitely needed; I can give lots of tips and ideas on testing. We don't have much in the way of unit tests, but I've been finding a number of other effective approaches to doing it. > - working on specifications (my current job : project coordination) An immediate area we need help here is with the extensions system. It's been on our roadmap to write a spec for this, and some work has been done and many of the ideas are out there, but it needs to be written up and pushed to completion. The reason why extensions would benefit from a spec whereas most other features haven't needed one, is because by definition the system needs to be used by a lot of different developers coming at it from a lot of different ways (different programming languages, operating systems, etc.) So specifically detailing the API, capabilities and limitations, etc. etc. will be vital for making it successful. > - providing some example svg (mostly technical/mapmaking oriented, not > artiscal value) / screenshots Also definitely check out www.openclipart.org, one of Inkscape's sister projects; technical symbols and examples are quite welcome there. > - work on some small tutorials > - test test test > > I fact, here is my proposal : > > - begin working on a list of specifications in order to get a traceability > matrix for test/user manual/tutorial/screenshots. (see example below > attached as rtf doc). Maybe to be posted on your wiki someday > - will try to do the same for RFEs in order to sort/orgize them (sounds > huge) By the way, note that I did this too, back when we were all part of Sodipodi. What I came up with is here: http://www.sodipodi.com/index.php3?section=development/tasks I believe rejon ported these writeups into the RFE tracker, so you hopefully should find some good order in the older RFE's. For what it's worth, I think for the RFE what we need is not so much organizing them, but more about identifying ones that are completed or duplicates, or that need further elaboration. Also, to date we've focused more intently on the bug list than the rfe list, although hopefully this will shift towards rfes a little more in the future. Note that one area of testing that can be directly beneficial is to try to replicate some of the reported bugs (esp. the ones with comments "I can't recreate it"), and provide additional info like back traces, error messages, etc. > - begin working on some test documents > - start a 'Need for contribution' wiki page listing points where > coders/artists/dummies_like_me can help Looking forward to seeing this. :-) > Wainting for your feedback and if this souds good to you, please forward to > the devel-mail-list Definitely sounds good, and am forwarding. Thanks, Bryce

5 4

RE: [Inkscape-devel] joining development
by Gazal, Geraud (MED) 07 Jul '04

07 Jul '04

OK, then. Here are my priorities then : 1 provide a test framework, based on the following notions : feature testing non regression testing unit testing -> thus providing - a kind of test matrix - some test cases/documents - a test report template (maybe script/interface) in order to automatically generate test reports I insist on the fact that having Inkscape being scriptable would be a huge plus for automated tests, especially for : - SVG compliance, rendering, printing (automaticaly loads svg files, compare to 'reference', and provide a status). - editing features (automatically generates svg files according to scenario and compare to reference. 2 Test (of course). 3 Work on a 'help/work needed' page. And a the same time get a look on extensions specifications. 4 work on French translation. Regards, Matiphas

3 2

EPS import
by Ted Gould 07 Jul '04

07 Jul '04

Using an idea from Artis Rozentals in this enhancement request: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=957916&group_i… I've implemented all the of the .inkmod files to do this. Basically it goes like this: EPS -> PS -> Sketch -> SVG Kind of convoluted, but most users won't have to see that. To see this work you'll need to have pstoedit, ghostscript, and Sketch installed. If other people could look at this and comment that would be great. If you have those installed, all you need to do is open a bunch of EPS files. --Ted

3 3

Inkscape 0.39pre3
by Ted Gould 07 Jul '04

07 Jul '04

Has been put on to Sourceforge (actually it happened last night, but I forgot to write the e-mail :) This signals the feature freeze for 0.39, and the start of bug fixing. Hopefully they'll all be easy and we should have a pre4 here shortly ;) http://prdownloads.sourceforge.net/inkscape/inkscape-0.39pre3.tar.gz?downlo… Testing of this release is strongly encouraged (along with bug reporting) so that we can find all the bugs and release a very stable 0.39. http://sourceforge.net/tracker/?group_id=93438&atid=604306 --Ted

1 0

export problems
by bulia byak 06 Jul '04

06 Jul '04

Ted, Thanks for implementing the export hints. There are a number of problems that I found in testing them today: 1 Why "Custom" is the default? As before, when I open Export, it must switch to Selection if there's selection, otherwise to Drawing if there's a drawing, otherwise to page. Switching to Custom must be possible either manually, or automatically when you change any of the x, y, w, h parameters (i.e. when they no longer correspond to selection, drawing, or page). 2 The dialog does not track selection change. It did before. Now it must not only change x/y/w/h when selection is changed or modified (as before) but also reread the filename and resolution hints when the selection is changed. 3 When I do export and the hints are remembered, the document is not considered changed. So I cannot save it (unless I change something else) and the hints are lost on close. 4. When there's no filename hint and the export filename is constructed from the document filename, it does not remove .svg which results e.g. in "wa.svg.png". This did not happen before. Please fix these problems and we'll have another killer feature for this release! I'm very excited about it.

1 0

export problems
by bulia byak 06 Jul '04

06 Jul '04

Ted, Thanks for implementing the export hints. There are a number of problems that I found in testing them today: 1 Why "Custom" is the default? As before, when I open Export, it must switch to Selection if there's selection, otherwise to Drawing if there's a drawing, otherwise to page. Switching to Custom must be possible either manually, or automatically when you change any of the x, y, w, h parameters (i.e. when they no longer correspond to selection, drawing, or page). 2 The dialog does not track selection change. It did before. Now it must not only change x/y/w/h when selection is changed or modified (as before) but also reread the filename and resolution hints when the selection is changed. 3 When I do export and the hints are remembered, the document is not considered changed. So I cannot save it (unless I change something else) and the hints are lost on close. 4. When there's no filename hint and the export filename is constructed from the document filename, it does not remove .svg which results e.g. in "wa.svg.png". This did not happen before. Please fix these problems and we'll have another killer feature for this release! I'm very excited about it.

1 0

Updated 0.39 spanish translation
by Lucas Vieites 06 Jul '04

06 Jul '04

Attached it goes -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

2 1

inkscape-0.39pre3 delayed
by Ted Gould 06 Jul '04

06 Jul '04

Because it isn't passing distcheck. Here is the error that I'm getting. It's correct that there is no libtool in that directory... I've compared pre2 and pre3 pretty extensively and can't find any differences related to libtool. Hmmm... I'll keep looking, but anyone has ideas I'd love to hear them. /bin/sh ../libtool --mode=link ccache g++ -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -o inkscape --export-dynamic main.o libinkpre.a dialogs/libspdialogs.a xml/libspxml.a svg/libspsvg.a widgets/libspwidgets.a display/libspdisplay.a helper/libspchelp.a libnrtype/libnrtype.a libnr/libnr.a livarot/libvarot.a extension/libextension.a extension/implementation/libimplementation.a extension/internal/libinternal.a inkjar/libinkjar.a libinkpost.a -Wl,--export-dynamic -lxml2 -lpthread -lz -lgtkmm-2.0 -lgdkmm-2.0 -latkmm-1.0 -lgtk-x11-2.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpng -lz -lpopt -L/usr/X11R6/lib -lXft -lfreetype -lz -lXrender -lX11 -lfontconfig -Wl,--export-dynamic -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lfreetype -lz ../libtool: ../libtool: No such file or directory make[3]: *** [inkscape] Error 127 make[3]: Leaving directory `/home/ted/Development/inkscape.release/inkscape-0.39pre3/_build/src' --Ted

1 0

crazy idea: map ourselves
by Kees Cook 06 Jul '04

06 Jul '04

After working on this locale stuff, I got curious about where everyone else lived who working on inkscape. I found a nice (but large) SVG of the world (http://www.wherearewe.co.nz/svg/world.svgz), and I wanted to map everyone's names onto it. Can everyone who's interested in appearing on such a thing send me their long/lat (or an address I can go convert). I think it would be cool to see an "about" screen (or even a "users of inkscape" map) that shows what a diverse set of places we come from. -- Kees Cook @outflux.net

11 18

ill2svg.pl image support. Anyone?
by Tuukka Pasanen 05 Jul '04

05 Jul '04

hi, Have anyone tested ill2svg.pl image export support? Is it just me who needs it?? I like to get feed back so I could improve it.. Tuukka

2 1

Header Include Report
by Bryce Harrington 05 Jul '04

05 Jul '04

Header Include Report for Inkscape-0.35 to Inkscape-CVS (2004-07-05) -------------------------------------------------------------------- The following report measures Inkscape's current include file hierarchy, using inkscape-0.35 as a baseline. IDC (Include Dependency Count) - the number of source files that need to be recompiled if this file changes. IC (Include Count) - the number of files that could trigger a rebuild of any files that include this file. IDP (Include Dependency Product) = IDC x IC - an indicator of how much impact the file has on the include hierarchy of the project. Inkscape-0.35 Inkscape-CVS Filename IDC IC IDP IDC IC IDP ------------------------------------------------------------------------- sp-item.h 72 16 576 111 22 2442 sp-marker.h 3 12 36 86 28 2408 style.h 25 12 150 79 30 2370 sp-item-group.h 24 18 216 97 23 2231 desktop.h 44 22 484 53 38 2014 libnr/nr-rect.h 76 10 380 150 11 1650 libnr/nr-matrix.h 83 10 415 152 10 1520 libnr/nr-rect-l.h 97 13 1261 selection.h 33 10 165 46 24 1104 libnr/nr-rotate.h 153 7 1071 sp-shape.h 25 20 250 34 31 1054 libnr/nr-point-fns.h 162 6 972 libnr/nr-matrix-fns.h 88 11 968 display/sp-canvas.h 45 20 900 libnr/nr-pixblock.h 55 8 220 61 14 854 sp-root.h 17 30 255 30 26 780 libnr/nr-scale.h 153 5 765 display/nr-arena-item.h 20 14 140 32 22 704 libnr/nr-point-ops.h 172 4 688 view.h 51 4 102 73 9 657 libnr/nr-translate.h 152 4 608 libnr/nr-matrix-ops.h 46 12 552 libnr/nr-point.h 183 3 549 sp-object.h 94 6 282 123 4 492 libnr/nr-point-l.h 98 5 490 document-private.h 6 38 114 16 30 480 sp-path.h 10 22 110 15 32 480 sp-text.h 7 38 133 17 28 476 sp-chars.h 8 34 136 18 26 468 sp-paint-server.h 19 16 152 24 19 456 verbs.h 4 4 16 27 14 378 document.h 77 10 385 93 4 372 display/nr-arena-group.h 10 8 80 16 23 368 extension/extension.h 35 10 350 helper/action.h 9 6 27 29 12 348 interface.h 6 6 18 22 15 330 sp-gradient.h 10 22 110 13 24 312 desktop-events.h 7 12 84 8 39 312 libnr/nr-values.h 103 6 309 153 2 306 libnr/nr-path.h 40 6 120 101 3 303 libnr/nr-maybe.h 150 2 300 display/canvas-bpath.h 13 23 299 uri-references.h 4 2 8 96 3 288 sp-pattern.h 2 10 20 10 28 280 svg/svg.h 43 8 172 55 5 275 sp-use.h 2 10 20 11 24 264 sp-polygon.h 6 11 66 8 32 256 sp-rect.h 5 12 60 8 32 256 display/sp-canvas-util.h 12 21 252 sp-star.h 5 12 60 7 33 231 message-stack.h 76 3 228 sp-spiral.h 5 11 55 7 32 224 xml/repr.h 112 2 112 108 2 216 sp-namedview.h 14 12 84 18 12 216 nodepath.h 5 30 75 6 36 216 display/curve.h 52 4 208 libnr/nr-coord.h 194 1 194 config.h 71 2 71 192 1 192 sp-ellipse.h 4 12 48 6 32 192 color.h 36 8 144 95 2 190 display/sodipodi-ctrl.h 9 21 189 livarot/Shape.h 21 9 189 desktop-handles.h 48 6 144 62 3 186 inkscape.h 45 6 135 62 3 186 xml/repr-private.h 22 6 66 46 4 184 libnr/nr-dim2.h 183 1 183 helper/sp-intl.h 58 4 116 90 2 180 libnr/nr-forward.h 55 2 55 179 1 179 libnr/nr-macros.h 106 6 318 177 1 177 seltrans.h 6 7 42 8 22 176 libnrtype/font-instance.h 10 17 170 select-context.h 5 10 50 6 28 168 file.h 9 20 90 15 11 165 node-context.h 4 18 72 4 40 160 forward.h 114 2 114 150 1 150 message-context.h 75 2 150 libnr/nr-i-coord.h 150 1 150 livarot/ShapeUtils.h 21 7 147 xml/xml-forward.h 146 1 146 print.h 10 5 50 13 11 143 snap.h 27 5 135 libnr/nr-blit.h 7 5 35 9 15 135 extension/system.h 11 12 132 extension/db.h 12 11 132 libnrtype/font-style.h 10 13 130 sp-typeset-utils.h 3 43 129 sp-offset.h 4 32 128 display/sodipodi-ctrlrect.h 6 21 126 sp-typeset.h 5 25 125 display/nr-arena-forward.h 82 2 82 125 1 125 gradient-chemistry.h 5 24 60 5 25 125 display/canvas-arena.h 3 13 39 5 25 125 version.h 124 1 124 libnr/nr-object.h 49 4 98 60 2 120 sp-anchor.h 5 20 50 5 24 120 sp-defs.h 11 8 44 24 5 120 sp-image.h 4 10 40 5 24 120 shortcuts.h 7 2 7 8 15 120 knot.h 13 10 65 19 6 114 livarot/Path.h 19 6 114 sp-object-group.h 18 8 72 22 5 110 svg/svg-types.h 64 2 64 107 1 107 display/sp-ctrlline.h 5 21 105 toolbox.c[pp] 1 45 45 1 105 105 libnr/nr-gradient.h 4 12 24 5 21 105 xml/repr-action.h 25 2 25 52 2 104 uri.h 101 1 101 require-config.h 101 1 101 helper/helper-forward.h 70 2 70 100 1 100 sp-guide.h 7 5 35 11 9 99 verbs.c[pp] 1 65 65 1 98 98 enums.h 29 2 29 98 1 98 display/nr-arena-glyphs.h 2 18 36 3 32 96 sp-line.h 2 12 24 3 32 96 sp-polyline.h 2 11 22 3 32 96 desktop.c[pp] 1 56 56 1 95 95 libnr/nr-pixblock-pattern.h 5 10 25 6 15 90 display/nr-gradient-gpl.h 4 22 88 event-context.h 21 6 63 22 4 88 knotholder.h 6 6 36 11 8 88 dialogs/stroke-style.c[pp] 1 84 84 file.c[pp] 1 45 45 1 82 82 refcounted.h 81 1 81 seltrans-handles.h 3 13 39 3 27 81 tools-switch.c[pp] 1 80 80 display/nr-arena-shape.h 1 21 21 2 40 80 sp-shape.c[pp] 1 45 45 1 78 78 selection-chemistry.c[pp] 1 32 32 1 78 78 widgets/button.h 4 8 16 6 13 78 interface.c[pp] 1 50 50 1 77 77 select-toolbar.c[pp] 1 77 77 message.h 76 1 76 dialogs/find.c[pp] 1 76 76 sp-text.c[pp] 1 42 42 1 75 75 libnr/nr-render.h 4 10 20 5 15 75 widgets/paint-selector.h 2 2 4 3 25 75 toolbox.h 3 1 3 5 15 75 select-context.c[pp] 1 45 45 1 74 74 event-context.c[pp] 1 37 37 1 74 74 sp-typeset.c[pp] 1 74 74 seltrans.c[pp] 1 35 35 1 74 74 sp-object-repr.c[pp] 1 54 54 1 72 72 splivarot.c[pp] 1 72 72 inkscape-private.h 13 8 52 18 4 72 nodepath.c[pp] 1 34 34 1 71 71 widgets/gradient-vector.c[pp] 1 71 71 node-context.c[pp] 1 39 39 1 70 70 widgets/sp-widget.h 4 6 24 10 7 70 sp-typeset-kplayout.c[pp] 1 70 70 star-context.c[pp] 1 35 35 1 70 70 sp-typeset-layout.c[pp] 1 70 70 dialogs/desktop-properties.c[pp] 1 70 70 display/nr-arena.h 7 10 35 14 5 70 dialogs/text-edit.c[pp] 1 70 70 dialogs/xml-tree.c[pp] 1 69 69 spiral-context.c[pp] 1 35 35 1 69 69 rect-context.c[pp] 1 34 34 1 69 69 arc-context.c[pp] 1 32 32 1 69 69 dialogs/export.c[pp] 1 68 68 main.c[pp] 1 38 38 1 68 68 dropper-context.c[pp] 1 27 27 1 68 68 draw-context.c[pp] 1 41 41 1 66 66 widgets/gradient-position.h 2 33 66 desktop-events.c[pp] 1 33 33 1 66 66 document.c[pp] 1 32 32 1 66 66 svg-view.h 5 4 20 6 11 66 text-context.c[pp] 1 41 41 1 65 65 dialogs/fill-style.c[pp] 1 65 65 sp-item.c[pp] 1 37 37 1 65 65 inkscape.c[pp] 1 27 27 1 65 65 libnrtype/RasterFont.h 4 16 64 dyna-draw-context.c[pp] 1 32 32 1 64 64 extension/implementation/script.c[pp] 1 63 63 object-edit.h 2 7 14 7 9 63 display/guideline.h 3 21 63 display/nr-arena-glyphs.c[pp] 1 62 62 sp-use.c[pp] 1 30 30 1 61 61 desktop-affine.h 20 4 80 20 3 60 sp-metrics.h 10 10 50 10 6 60 sp-symbol.c[pp] 1 33 33 1 60 60 libnr/nr-pixblock-pixel.h 1 5 5 4 15 60 object-ui.c[pp] 1 35 35 1 59 59 widgets/paint-selector.c[pp] 1 59 59 sp-marker.c[pp] 1 34 34 1 58 58 dialogs/item-properties.c[pp] 1 58 58 display/nr-arena-shape.c[pp] 1 58 58 sp-root.c[pp] 1 31 31 1 58 58 dialogs/transformation.c[pp] 1 58 58 path-chemistry.c[pp] 1 37 37 1 57 57 sp-typeset-utils.c[pp] 1 56 56 sp-namedview.c[pp] 1 28 28 1 56 56 widgets/gradient-position.c[pp] 1 56 56 sp-offset.c[pp] 1 56 56 sp-chars.c[pp] 1 29 29 1 56 56 object-edit.c[pp] 1 22 22 1 56 56 knot.c[pp] 1 23 23 1 55 55 extension/internal/ps.c[pp] 1 54 54 sp-gradient.c[pp] 1 33 33 1 53 53 sp-image.c[pp] 1 30 30 1 53 53 sp-star.c[pp] 1 27 27 1 52 52 zoom-context.c[pp] 1 25 25 1 52 52 sp-symbol.h 2 12 24 2 26 52 sp-pattern.c[pp] 1 29 29 1 51 51 dialogs/object-properties.c[pp] 1 50 50 sp-item-group.c[pp] 1 30 30 1 50 50 selection.c[pp] 1 23 23 1 50 50 widgets/gradient-selector.h 2 25 50 dialogs/stroke-style.h 2 25 50 dialogs/dialog-events.h 25 2 50 widgets/gradient-image.h 1 12 12 2 25 50 prefs-utils.h 49 1 49 widgets/gradient-selector.c[pp] 1 49 49 dialogs/dialog-events.c[pp] 1 49 49 dialogs/align.c[pp] 1 48 48 print.c[pp] 1 30 30 1 48 48 widgets/sp-widget.c[pp] 1 48 48 help.c[pp] 1 27 27 1 48 48 libnr/nr-scale-ops.h 8 6 48 selcue.h 24 2 48 style.c[pp] 1 24 24 1 48 48 selcue.c[pp] 1 48 48 satisfied-guide-cns.c[pp] 1 47 47 knotholder.c[pp] 1 21 21 1 46 46 rubberband.c[pp] 1 16 16 1 46 46 display/nr-arena-image.h 1 8 8 2 23 46 helper/stock-items.c[pp] 1 46 46 macros.h 31 2 31 45 1 45 sp-rect.c[pp] 1 27 27 1 45 45 sp-ellipse.c[pp] 1 24 24 1 45 45 star-context.h 3 4 12 4 11 44 livarot/AVL.h 22 2 44 gradient-chemistry.c[pp] 1 28 28 1 44 44 dialogs/display-settings.c[pp] 1 44 44 spiral-context.h 3 8 24 4 11 44 desktop-affine.c[pp] 1 22 22 1 43 43 desktop-handles.c[pp] 1 14 14 1 43 43 sp-path.c[pp] 1 24 24 1 42 42 sp-line.c[pp] 1 19 19 1 42 42 display/gnome-canvas-acetate.h 2 21 42 display/canvas-grid.h 2 21 42 svg/stringstream.h 21 2 42 extension/internal/gdkpixbuf-input.c[pp] 1 41 41 widgets/spw-utilities.c[pp] 1 41 41 sp-anchor.c[pp] 1 22 22 1 40 40 sp-spiral.c[pp] 1 19 19 1 40 40 extension/implementation/implementation.h 10 4 40 libnr/nr-rotate-ops.h 5 8 40 sp-guide.c[pp] 1 16 16 1 40 40 sp-object-repr.h 11 6 33 13 3 39 slideshow.c[pp] 1 26 26 1 39 39 sp-polygon.c[pp] 1 15 15 1 39 39 sp-object.c[pp] 1 14 14 1 39 39 display/canvas-bpath.c[pp] 1 39 39 widgets/sp-xmlview-content.c[pp] 1 38 38 sp-clippath.c[pp] 1 23 23 1 38 38 widgets/dash-selector.c[pp] 1 38 38 sp-mask.c[pp] 1 23 23 1 38 38 svg-view.c[pp] 1 22 22 1 38 38 sp-polyline.c[pp] 1 15 15 1 37 37 libnrtype/RasterFont.c[pp] 1 37 37 display/sp-ctrlline.c[pp] 1 37 37 widgets/menu.h 16 2 16 37 1 37 widgets/font-selector.c[pp] 1 36 36 widgets/icon.c[pp] 1 36 36 dyna-draw-context.h 3 5 15 3 12 36 widgets/button.c[pp] 1 36 36 selection-chemistry.h 8 8 32 12 3 36 dropper-context.h 3 7 21 4 9 36 draw-context.h 3 5 15 3 12 36 libnrtype/FontFactory.h 7 5 35 extension/extension-forward.h 35 1 35 document-undo.c[pp] 1 21 21 1 35 35 livarot/LivarotDefs.h 35 1 35 extension/system.c[pp] 1 33 33 rect-context.h 3 4 12 3 11 33 libnrtype/font-style-to-pos.c[pp] 1 33 33 libnrtype/FontInstance.c[pp] 1 33 33 livarot/livarot-forward.h 33 1 33 attributes.h 27 1 27 33 1 33 arc-context.h 3 4 12 3 11 33 display/canvas-arena.c[pp] 1 32 32 selection-describer.c[pp] 1 31 31 sp-item-update-cns.c[pp] 1 31 31 dialogs/object-attributes.c[pp] 1 31 31 sp-item-notify-moveto.c[pp] 1 30 30 sp-clippath.h 3 6 18 3 10 30 widgets/gradient-image.c[pp] 1 30 30 sp-mask.h 3 6 18 3 10 30 sp-item-rm-unsatisfied-cns.c[pp] 1 30 30 livarot/Ligne.h 10 3 30 extension/internal/ps.h 2 15 30 sp-item-transform.c[pp] 1 15 15 1 29 29 livarot/PathCutting.c[pp] 1 29 29 dialogs/filedialog.c[pp] 1 29 29 dialogs/in-dt-coordsys.c[pp] 1 28 28 seltrans-handles.c[pp] 1 14 14 1 28 28 display/nr-arena-image.c[pp] 1 28 28 display/nr-arena-item.c[pp] 1 27 27 widgets/sp-color-selector.h 2 6 12 9 3 27 text-context.h 3 4 12 3 9 27 display/nr-gradient-gpl.c[pp] 1 26 26 libnrtype/TextWrapper.c[pp] 1 26 26 display/sp-canvas.c[pp] 1 26 26 libnr/nr-svp.h 3 8 12 2 13 26 extension/init.c[pp] 1 26 26 display/nr-arena-group.c[pp] 1 25 25 display/canvas-grid.c[pp] 1 25 25 zoom-context.h 5 4 20 5 5 25 display/guideline.c[pp] 1 25 25 libnr/nr-gradient.c[pp] 1 25 25 dialogs/rdf.h 3 8 24 display/sp-canvas-util.c[pp] 1 24 24 display/nr-arena.c[pp] 1 24 24 libnrtype/nrtype-forward.h 24 1 24 extension/extension.c[pp] 1 24 24 rubberband.h 4 4 16 4 6 24 dialogs/filedialog.h 2 12 24 display/sodipodi-ctrlrect.c[pp] 1 23 23 display/sodipodi-ctrl.c[pp] 1 23 23 livarot/DblLinked.h 23 1 23 display/gnome-canvas-acetate.c[pp] 1 22 22 svg/ftos.h 22 1 22 inkview.c[pp] 1 22 22 libnrtype/FontFactory.c[pp] 1 22 22 extension/internal/eps-out.c[pp] 1 21 21 selection-describer.h 7 3 21 sp-paint-server.c[pp] 1 10 10 1 21 21 snap.c[pp] 1 21 21 extension/internal/svg.c[pp] 1 21 21 libnr/nr-types.c[pp] 1 20 20 livarot/PathConversion.c[pp] 1 20 20 helper/unit-menu.h 8 4 16 10 2 20 libnr/nr-path.c[pp] 1 20 20 widgets/sp-color-scales.h 4 5 20 path-chemistry.h 6 2 12 10 2 20 libnr/nr-svp.c[pp] 1 20 20 libnr/nr-svp-render.c[pp] 1 19 19 libnr/nr-pixops.h 10 2 10 19 1 19 helper/window.c[pp] 1 19 19 helper/window.h 18 2 18 19 1 19 libnr/nr-rect.c[pp] 1 19 19 livarot/PathStroke.c[pp] 1 19 19 libnr/nr-types.h 141 4 282 1 19 19 libnr/nr-values.c[pp] 1 19 19 extension/implementation/script.h 3 6 18 libnr/nr-blit.c[pp] 1 18 18 libnr/nr-pixblock-line.c[pp] 1 18 18 display/nr-plain-stuff-gdk.c[pp] 1 18 18 extension/internal/ps-out.c[pp] 1 18 18 libnr/nr-pixblock-pattern.c[pp] 1 17 17 libnr/nr-svp-render.h 2 7 14 1 17 17 livarot/ShapeSweep.c[pp] 1 17 17 libnr/nr-pixblock-pixel.c[pp] 1 17 17 svg/svg-affine.c[pp] 1 17 17 livarot/PathSimplify.c[pp] 1 16 16 dialogs/object-attributes.h 6 2 12 8 2 16 view.c[pp] 1 9 9 1 16 16 widgets/spw-utilities.h 1 1 1 16 1 16 livarot/ShapeRaster.c[pp] 1 16 16 widgets/sp-color-notebook.c[pp] 1 16 16 widgets/sp-color-notebook.h 4 4 16 livarot/Path.c[pp] 1 16 16 shortcuts.c[pp] 1 6 6 1 16 16 libnr/nr-rotate-fns.h 2 8 16 libnr/nr-pixblock.c[pp] 1 15 15 libnr/nr-compose-transform.c[pp] 1 15 15 libnr/nr-pixblock-line.h 1 15 15 extension/db.c[pp] 1 15 15 extension/implementation/implementation.c[pp] 1 15 15 widgets/sp-color-wheel.c[pp] 1 15 15 libnr/nr-svp-private.h 2 5 10 1 14 14 libnr/nr-rect-l.c[pp] 1 14 14 livarot/ShapeMisc.c[pp] 1 14 14 helper/action.c[pp] 1 14 14 widgets/ruler.h 1 6 6 2 7 14 livarot/Shape.c[pp] 1 13 13 livarot/ShapeSweepUtils.c[pp] 1 13 13 libnr/nr-matrix.c[pp] 1 13 13 widgets/sp-color-wheel-selector.c[pp] 1 13 13 helper/sp-marshal.h 14 2 14 13 1 13 libnr/nr-matrix-fns.c[pp] 1 12 12 livarot/BitLigne.h 6 2 12 libnr/nr-convex-hull.h 1 12 12 libnrtype/TextWrapper.h 6 2 12 libnrtype/raster-glyph.h 3 4 12 widgets/sp-color-wheel-selector.h 2 6 12 sp-use-reference.h 3 4 12 widgets/spinbutton-events.c[pp] 1 11 11 inkscape-stock.h 11 1 11 widgets/sp-color-scales.c[pp] 1 11 11 dialogs/rdf.c[pp] 1 11 11 helper/units.h 86 2 86 11 1 11 livarot/ShapeDraw.c[pp] 1 10 10 extension/internal/eps-out.h 2 5 10 livarot/PathOutline.c[pp] 1 10 10 sp-animation.h 2 4 8 2 5 10 extension/internal/gdkpixbuf-input.h 2 5 10 display/bezier-utils.h 5 2 10 geom.c[pp] 1 10 10 sp-defs.c[pp] 1 8 8 1 10 10 widgets/icon.h 5 2 5 10 1 10 livarot/AlphaLigne.h 5 2 10 libnr/nr-rotate-fns.c[pp] 1 10 10 extension/internal/ps-out.h 2 5 10 display/bezier-utils.c[pp] 1 10 10 sp-object-group.c[pp] 1 8 8 1 10 10 dialogs/sp-attribute-widget.c[pp] 1 10 10 extension/internal/svg.h 2 5 10 prefs-utils.c[pp] 1 9 9 svg/svg-path.c[pp] 1 9 9 xml/repr-util.c[pp] 1 9 9 libnrtype/font-style-to-pos.h 3 3 9 svg/svg-length.c[pp] 1 9 9 uri-references.c[pp] 1 7 7 1 9 9 widgets/sp-xmlview-attr-list.c[pp] 1 9 9 streams-zlib.h 3 3 9 libnrtype/nr-type-pos-def.h 9 1 9 widgets/sp-color-gtkselector.c[pp] 1 9 9 widgets/ruler.c[pp] 1 9 9 widgets/sp-color-wheel.h 3 3 9 sp-metrics.c[pp] 1 6 6 1 9 9 widgets/sp-color-selector.c[pp] 1 8 8 xml/sp-repr-attr.h 4 2 8 widgets/sp-color-gtkselector.h 2 4 8 sp-guide-constraint.h 4 2 8 helper/unit-menu.c[pp] 1 8 8 dir-util.h 5 2 5 8 1 8 sp-use-reference.c[pp] 1 8 8 display/curve.c[pp] 1 8 8 tools-switch.h 4 2 8 widgets/widget-sizes.h 8 1 8 sp-item-transform.h 5 18 45 4 2 8 widgets/sp-xmlview-content.h 1 3 3 2 4 8 streams-handles.h 4 2 8 libnrtype/nr-type-primitives.h 6 2 6 8 1 8 sp-guide-attachment.h 4 2 8 svg/gnome-canvas-bpath-util.h 2 4 8 svg/svg-color.c[pp] 1 7 7 xml/repr-io.c[pp] 1 7 7 sp-animation.c[pp] 1 6 6 1 7 7 widgets/sp-color-preview.h 1 1 1 7 1 7 xml/repr.c[pp] 1 7 7 libnr/nr-point-fns.c[pp] 1 7 7 dialogs/fill-style.h 1 2 2 3 2 6 widgets/sp-xmlview-tree.h 1 2 2 2 3 6 widgets/sp-color-slider.c[pp] 1 6 6 widgets/sp-xmlview-tree.c[pp] 1 6 6 widgets/dash-selector.h 1 2 2 2 3 6 libnr/nr-translate-ops.h 1 6 6 xml/repr-get-children.h 3 2 6 object-hierarchy.c[pp] 1 6 6 dialogs/sp-attribute-widget.h 2 3 6 xml/repr-get-children.c[pp] 1 6 6 xml/repr-css.c[pp] 1 6 6 sp-item-rm-unsatisfied-cns.h 3 2 6 dialogs/item-properties.h 2 2 4 3 2 6 widgets/sp-xmlview-attr-list.h 1 2 2 2 3 6 prefix.h 6 1 6 svg/gnome-canvas-bpath-util.c[pp] 1 5 5 message-context.c[pp] 1 5 5 streams-jar.c[pp] 1 5 5 dialogs/object-properties.h 3 1 3 5 1 5 livarot/Ligne.c[pp] 1 5 5 display/nr-plain-stuff-gdk.h 5 1 5 streams-gzip.c[pp] 1 5 5 xml/repr-action.c[pp] 1 5 5 libnr/nr-compose.h 1 1 1 5 1 5 helper/units.c[pp] 1 5 5 marker-status.h 4 1 4 widgets/spinbutton-events.h 4 1 4 libnr/nr-object.c[pp] 1 4 4 object-ui.h 2 2 4 2 2 4 libnr/nr-compose-transform.h 1 3 3 2 2 4 dialogs/export.h 3 1 3 4 1 4 widgets/sp-color-slider.h 2 1 2 4 1 4 streams-gzip.h 1 4 4 dialogs/in-dt-coordsys.h 2 2 4 inkscape_version.h 4 1 4 satisfied-guide-cns.h 2 2 4 select-toolbar.h 2 2 4 splivarot.h 2 2 4 sp-item-notify-moveto.h 2 2 4 sp-item-update-cns.h 2 2 4 widgets/font-selector.h 1 10 10 2 2 4 sp-cursor.h 4 1 4 4 1 4 display/nr-plain-stuff.h 4 1 4 inkscape-stock.c[pp] 1 4 4 libnrtype/raster-position.h 1 4 4 display/nr-plain-stuff.c[pp] 1 4 4 approx-equal.h 4 1 4 libnr/nr-compose.c[pp] 1 4 4 streams-zlib.c[pp] 1 4 4 streams-jar.h 1 4 4 widgets/gradient-vector.h 2 2 4 geom.h 2 2 4 message-stack.c[pp] 1 4 4 livarot/AVL.c[pp] 1 4 4 helper/gnome-utils.h 2 1 2 4 1 4 livarot/MySeg.c[pp] 1 3 3 help.h 2 1 2 3 1 3 mod360.h 3 1 3 dialogs/text-edit.h 2 1 2 3 1 3 widgets/menu.c[pp] 1 3 3 livarot/BitLigne.c[pp] 1 3 3 widgets/sp-color-preview.c[pp] 1 3 3 dialogs/desktop-properties.h 2 1 2 3 1 3 libnrtype/font-glyph.h 1 3 3 livarot/AlphaLigne.c[pp] 1 3 3 inkjar/jar.c[pp] 1 3 3 remove-last.h 3 1 3 color.c[pp] 1 5 5 1 3 3 streams-handles.c[pp] 1 3 3 dialogs/align.h 2 1 2 3 1 3 libnrtype/nr-type-primitives.c[pp] 1 3 3 attributes.c[pp] 1 2 2 1 3 3 helper/png-write.c[pp] 1 3 3 helper/sp-marshal.c[pp] 1 2 2 marker-status.c[pp] 1 2 2 livarot/DblLinked.c[pp] 1 2 2 extension/init.h 2 1 2 fixes.c[pp] 1 2 2 sp-cursor.c[pp] 1 2 2 1 2 2 livarot/MySeg.h 1 2 2 helper/gnome-utils.c[pp] 1 2 2 dialogs/transformation.h 2 1 2 2 1 2 extract-uri.h 2 1 2 uri.c[pp] 1 2 2 preferences-skeleton.h 1 1 1 1 2 2 dialogs/display-settings.h 1 1 1 2 1 2 object-hierarchy.h 2 1 2 libnrtype/nr-type-pos-def.c[pp] 1 2 2 version.c[pp] 1 2 2 mod360.c[pp] 1 2 2 inkjar/jar.h 2 1 2 helper/stock-items.h 1 2 2 dir-util.c[pp] 1 2 2 1 2 2 svg/ftos.c[pp] 1 2 2 helper/png-write.h 1 1 1 2 1 2 extract-uri.c[pp] 1 2 2 prefix.c[pp] 1 2 2 svg/round.c[pp] 1 1 1 pixmaps/cursor-node-m.xpm 1 1 1 1 1 1 pixmaps/cursor-spiral.xpm 1 1 1 1 1 1 pixmaps/cursor-zoom.xpm 1 1 1 1 1 1 pixmaps/cursor-text-insert.xpm 1 1 1 pixmaps/cursor-select-d.xpm 1 1 1 1 1 1 pixmaps/cursor-text.xpm 1 1 1 1 1 1 pixmaps/cursor-select-m.xpm 1 1 1 1 1 1 dialogs/find.h 1 1 1 dialogs/xml-tree.h 1 1 1 1 1 1 pixmaps/handles.xpm 1 1 1 1 1 1 pixmaps/cursor-node-d.xpm 1 1 1 1 1 1 pixmaps/cursor-node.xpm 1 1 1 1 1 1 livarot/MyMath.h 1 1 1 svg/itos.c[pp] 1 1 1 pixmaps/cursor-star.xpm 1 1 1 1 1 1 brokenimage.xpm 1 1 1 1 1 1 pixmaps/cursor-rect.xpm 1 1 1 1 1 1 pixmaps/cursor-arc.xpm 1 1 1 1 1 1 pixmaps/cursor-zoom-out.xpm 1 1 1 slideshow.h 1 1 1 1 1 1 pixmaps/cursor-dropper.xpm 1 1 1 helper/sp-canvas.h 30 14 210 libnrtype/nr-font.h 16 18 144 libnrtype/nr-typeface.h 16 18 144 libnrtype/nr-rasterfont.h 16 18 144 libnr/nr_config.h 143 2 143 module.h 16 16 128 desktop-snap.h 10 12 120 modules/sp-module.h 10 18 90 helper/canvas-bpath.h 9 18 81 sp-canvas.h 9 7 63 sp-canvas-util.h 7 8 56 sp-module-doc.h 5 11 55 nr-arena-item.h 7 7 49 helper/sodipodi-ctrl.h 6 8 48 sp-module-exec.h 4 12 48 modules/sp-module-sys.h 4 12 48 sp-module.h 5 9 45 modules/sp-module-doc.h 4 11 44 event-broker.c[pp] 1 40 40 helper/sp-canvas-util.h 5 16 40 helper/curve.h 39 2 39 stroke-style.c[pp] 1 38 38 sp-module-exec-ext.c[pp] 1 35 35 text-edit.c[pp] 1 35 35 gradient-vector.c[pp] 1 34 34 gradient-selector.c[pp] 1 34 34 nr-type-directory.h 3 11 33 libnrtype/nr-type-directory.h 3 22 33 nr-arena-shape.c[pp] 1 32 32 desktop-properties.c[pp] 1 32 32 helper/sp-ctrlline.h 4 8 32 nr-type-ft2.h 3 10 30 fill-style.c[pp] 1 30 30 gradient-position.h 2 15 30 ps.c[pp] 1 28 28 object-properties.c[pp] 1 28 28 nr-arena-glyphs.c[pp] 1 27 27 sp-module-exec-ext.h 2 13 26 nr-type-xft.h 2 13 26 document-properties.c[pp] 1 25 25 gradient-position.c[pp] 1 25 25 nr-arena.h 5 5 25 paint-selector.c[pp] 1 25 25 icon.c[pp] 1 25 25 export.c[pp] 1 24 24 nr-arena-group.h 3 8 24 helper/sodipodi-ctrlrect.h 3 8 24 item-properties.c[pp] 1 24 24 spw-utilities.c[pp] 1 24 24 transformation.c[pp] 1 24 24 sp-module-sys.h 2 12 24 xml-tree.c[pp] 1 23 23 align.c[pp] 1 23 23 stroke-style.h 2 11 22 sp-widget.c[pp] 1 21 21 helper/nr-gradient-gpl.h 3 14 21 nr-arena-shape.h 1 21 21 sp-module-sys.c[pp] 1 20 20 font-selector.c[pp] 1 20 20 canvas-arena.c[pp] 1 19 19 nr-rasterfont.c[pp] 1 19 19 nr-type-directory.c[pp] 1 19 19 desktop-snap.c[pp] 1 18 18 module.c[pp] 1 18 18 nr-arena-glyphs.h 1 18 18 button.c[pp] 1 17 17 gradient-image.c[pp] 1 17 17 node-edit.c[pp] 1 17 17 object-attributes.c[pp] 1 17 17 svg.h 4 4 16 helper/guideline.h 2 8 16 nr-type-xft.c[pp] 1 16 16 nr-typeface.c[pp] 1 16 16 nr-arena-item.c[pp] 1 15 15 repr-private.h 5 3 15 nr-font.c[pp] 1 15 15 nr-gradient-gpl.c[pp] 1 14 14 nr-arena-image.c[pp] 1 14 14 nr-arena-group.c[pp] 1 14 14 sp-module-exec.c[pp] 1 14 14 nr-type-ft2.c[pp] 1 14 14 sp-module.c[pp] 1 13 13 canvas-arena.h 1 13 13 gradient-image.h 1 12 12 guideline.c[pp] 1 12 12 sp-color-selector.h 2 6 12 dash-selector.c[pp] 1 12 12 sp-canvas.c[pp] 1 12 12 tool-options.c[pp] 1 12 12 nr-arena.c[pp] 1 12 12 sp-module-doc.c[pp] 1 12 12 tool-attributes.c[pp] 1 12 12 canvas-bpath.c[pp] 1 11 11 sp-toolbox.c[pp] 1 11 11 font-selector.h 1 10 10 ps.h 1 10 10 nr-font.h 1 10 10 modules/ps.h 1 10 10 sodipodi-ctrl.c[pp] 1 10 10 sp-color-selector.c[pp] 1 10 10 nr-rasterfont.h 1 10 10 sp-ctrlline.c[pp] 1 10 10 canvas-grid.c[pp] 1 10 10 sodipodi-ctrlrect.c[pp] 1 10 10 nr-typeface.h 1 10 10 sp-attribute-widget.c[pp] 1 9 9 gnome-canvas-acetate.c[pp] 1 9 9 sp-canvas-util.c[pp] 1 9 9 helper-forward.h 9 1 9 helper/bezier-utils.h 3 3 9 canvas-bpath.h 1 9 9 display-settings.c[pp] 1 8 8 guideline.h 1 8 8 sp-ctrlline.h 1 8 8 sodipodi-ctrl.h 1 8 8 helper/canvas-grid.h 1 8 8 canvas-grid.h 1 8 8 gnome-canvas-acetate.h 1 8 8 nr-plain-stuff-gdk.c[pp] 1 8 8 helper/gnome-canvas-acetate.h 1 8 8 button.h 2 4 8 nr-arena-image.h 1 8 8 sodipodi-ctrlrect.h 1 8 8 gradient-selector.h 2 4 8 svg-affine.c[pp] 1 8 8 nr-arena-forward.h 7 1 7 ruler.c[pp] 1 7 7 sp-xmlview-attr-list.c[pp] 1 7 7 nr-gradient-gpl.h 1 7 7 sp-xmlview-content.c[pp] 1 7 7 svg-length.c[pp] 1 6 6 sp-attribute-widget.h 3 2 6 action.c[pp] 1 6 6 svg-path.c[pp] 1 6 6 ruler.h 1 6 6 sp-widget.h 1 6 6 repr.h 5 1 5 sp-xmlview-tree.c[pp] 1 5 5 nr-type-primitives.c[pp] 1 5 5 unit-menu.c[pp] 1 5 5 repr-action.h 5 1 5 svg-color.c[pp] 1 5 5 libnr/nr-stroke.h 1 5 5 repr-util.c[pp] 1 4 4 fill-style.h 2 2 4 nr-plain-stuff.c[pp] 1 4 4 repr-action.c[pp] 1 4 4 repr-css.c[pp] 1 4 4 repr-io.c[pp] 1 4 4 units.c[pp] 1 4 4 gradient-vector.h 2 2 4 repr.c[pp] 1 4 4 bezier-utils.c[pp] 1 4 4 helper/nr-plain-stuff-gdk.h 4 1 4 sp-xmlview-content.h 1 3 3 sp-color-slider.h 3 1 3 menu.c[pp] 1 3 3 window.c[pp] 1 3 3 nr-type-primitives.h 3 1 3 event-broker.h 3 1 3 bezier-utils.h 1 3 3 sp-color-preview.c[pp] 1 3 3 icon.h 3 1 3 action.h 1 3 3 gnome-canvas-bpath-util.h 2 1 2 menu.h 2 1 2 paint-selector.h 1 2 2 png-write.c[pp] 1 2 2 arikkei-token.c[pp] 1 2 2 dialogs/node-edit.h 2 1 2 helper/nr-plain-stuff.h 2 1 2 sp-xmlview-tree.h 1 2 2 curve.h 2 1 2 sp-color-slider.c[pp] 1 2 2 object-attributes.h 1 2 2 gnome-utils.c[pp] 1 2 2 curve.c[pp] 1 2 2 sp-color-preview.h 2 1 2 item-properties.h 1 2 2 gen_nr_config.c[pp] 1 2 2 arikkei-dict.c[pp] 1 2 2 nr-plain-stuff.h 2 1 2 sp-marshal.c[pp] 1 2 2 dash-selector.h 1 2 2 units.h 2 1 2 sp-intl.h 1 2 2 unit-menu.h 1 2 2 sp-xmlview-attr-list.h 1 2 2 gnome-canvas-bpath-util.c[pp] 1 2 2 tool-attributes.h 1 1 1 nr-plain-stuff-gdk.h 1 1 1 tool-options.h 1 1 1 object-properties.h 1 1 1 libarikkei/arikkei-token.h 1 1 1 dialogs/tool-options.h 1 1 1 gnome-utils.h 1 1 1 node-edit.h 1 1 1 extension.h 1 1 1 png-write.h 1 1 1 export.h 1 1 1 text-edit.h 1 1 1 widgets/sp-toolbox.h 1 1 1 spw-utilities.h 1 1 1 window.h 1 1 1 arikkei-token.h 1 1 1 sp-toolbox.h 1 1 1 display-settings.h 1 1 1 extensions-skeleton.h 1 1 1 arikkei-dict.h 1 1 1 desktop-properties.h 1 1 1 dialogs/tool-attributes.h 1 1 1 document-properties.h 1 1 1 dialogs/document-properties.h 1 1 1 align.h 1 1 1 ------------------------------------------------------------------------- File Count 464 562 Total 3486 5415 16178 8290 10960 59277 Average 7 11 34 14 19 105 Notes ----- * This analysis was performed with the 'Cumulative Include Dependency Checker' (CIDC) on 2004-07-05 by B. Harrington. * CIDC sometimes loses track of which subdirectories a file comes from, so there may be multiple entries for a given file. * IDP should be expected to increase due to a natural increase in codefiles in the project, so an increase in IDP is to be expected. * Inkscape 0.35 preceded our conversion to C++, so its code files are .c, rather than .cpp; this has been compensated by treating the same-named .c and .cpp files as the same file. * The file count in the above report does not match the count obtained from a wc -l of the cidcSummary.csv; this appears to be due to duplicate entries due to path confusion on cidc's part, and has been corrected for in the parsing scripts. The number shown above is expected to be more accurate than the linecount of the .csv. * If you suspect any discrepencies, please flag it so it can be corrected for future runs.

1 0