- Inkscape Devel - Inkscape Mailman

typos and a translation question
by Arpad Biro 03 Feb '05

03 Feb '05

Hi, A typo in src/extension/extension.cpp: beacuse Double colon in src/extension/dependency.cpp: out_file << _("Dependency::") << std::endl; Also a question: in this piece of code from src/extension/dependency.cpp: gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute") does "path" mean "filesystem path" (as opposed to "vector path")? Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

4 6

Papers on Inkscape
by Bryce Harrington 03 Feb '05

03 Feb '05

Hi all, A week ago we talked about Inkscape technical papers. Several people were interested in writing on particular relevant topics, which is great! I think we should make several attempts, that way if some aren't accepted, we'll have multiple chances. Here's what to do if you're interested: 1. First, read through this email and think about a) what you would like to write on, and b) which conference(s) you'd like to author or co-author a paper for. Reply back here with this info, so co-authors can link up. 2. Next, look at their Call for Papers and see what they require for submitting a proposal (some just need abstracts, others need paper drafts), and when the due date is. Also look through their archives to see examples of types of papers that conference accepts. 3. Make a first stab at a short abstract. It should state in 1-3 paragraphs everything that the paper will discuss. Doesn't have to be perfect. :-) 4. If you want to work on the paper in a version control system, please feel free to create a subdir in the inkscape_project CVS module. It sounds like papers could be written on the following topics. I would be interested in co-authoring on any of these papers. Packaging Inkscape on Linux: Autopackager and Other Options ============================================================ Mike Hearn is interested in a paper that presents Autopackager and tells how it has provided a convenient option for Linux users to try. We can compare and contrast our experiences with it along with other packaging options, including use of (near-)static binaries. There are probably other related issues we could discuss, such as the C++ ABI change that caused problems on gentoo, and maybe our experiences with portability of Gtk apps to Windows and OSX. Quality Control in Open Source Desktop Linux Applications ========================================================= Kees is interested in writing up something related to bug fixing in Inkscape. I think there's a really engaging story in how over the course of a year we went from a codebase plagued with bugs and crashes, we were able to stabilize it and achieve a level where today reviewers remark that they "simply could not get it to crash". :-) Part of the story could explain how we rely on and use the bug tracker to prevent any bug from slipping through the cracks unexamined. Another part I think would be worth describing is how we include the larger community as teammembers in the process. Encouraging users to file bugs, showing them how to use gdb for making back traces, and involving them with validating our patches (perhaps via the nightly snapshots) is something that seems like a really obvious process, but a lot of projects and companies don't know how this works, so our experiences with making it work will be valuable. Drawing File Format Conversion Scripting in Inkscape ==================================================== Ted is interested in a paper describing our scripting system, and the clever ways we've been able to bend other open source applications to do our bidding. We can describe the crude stdin/stdout extension mechanism that we've been using for the last year to add support for various kinds of file formats, and describe the successes and problems we've seen. Also, it would be valuable to outline some of the other ways we've looked at extending Inkscape, including the ECMA and DOM work Ishmal's been doing (esp. if he'd be willing to participate in the paper). I think this paper would have a huge side benefit in that it'd give us really good motivation to create a complete but concise piece of documentation on our extension system. Since we have several upcoming milestones focusing on extensions, this would probably help in firming up those efforts. It would also gain us something we can give to new developers that would like to extend Inkscape. This might be a good OSCON paper. Best Practice in Open Source Graphic Design =========================================== Andy is interested in helping out with a paper on graphic design, and thinks this could be a good collaboration with Scribus as well. The paper would explain the benefits of using SVG for illustration, and explore reasons and methodology. This could be a good way to showcase examples of the more complex uses that Inkscapers have put the tool to use. I know that people recognize Inkscape can be used for simple, small scale stuff, but I think a lot of people aren't aware of the huge, complex, beautiful works that some folks have done with Inkscape (Scislac's work, for instance). Some other ideas for possible things worth mentioning in a paper like this: The Deviant Art Inkscape group, OCAL, SVG compatibility between other tools/projects (cairo, batik, illustrator, oodraw, et al), bitmap tracing tricks, node and gradient editing techniques, etc. This paper may be best given in a conference geared around art or svg, rather than a strictly technical convention, since it would be aiming at artists rather than developers. Rejon mentioned OpenSVG in the Netherlands, which might be a bit of a trip for most of us. This paper may be something that could be shopped out to several conferences, each near one of the authors (Australia, California, France...) so depending on which conference accepted it, we'd potentially have someone to present there. Conferences =========== Here's some info about what conferences are coming up, how much they cost, when things are due, etc. OSCON - O'Reilly Open Source Convention Proposals: Due Feb 13, 2005 Date: Aug 1-5, 2005 Loc: Portland, Oregon URL: http://conferences.oreillynet.com/os2005/ FOSSTEC - Int'l Symp on Free/Open Source Software, Technologies and Content Abstracts: Due March 2, 2005 (500-1500 words) Date: July 10-13, 2005 Loc: Orlando, Florida URL: http://www.iiisci.org/fosstec05/website/callforpapers.asp OpenSVG Papers: Due March 1st Date: Loc: Netherlands Cost: URL: http://www.svgopen.org/2005/registration.html LWE - Linux World and Expo, SF Proposals: Due March 22, 2005 Date: Aug 8-11, 2005 Loc: San Francisco URL: http://www.linuxworldexpo.com/live/12/speakers//callforpapers LWE tends to be sort of business-ish. The Autopackager paper may fit here, but the others would probably have a tougher chance. LISA Drafts: May 10, 2005 Date: Dec 4-9, 2005 Loc: San Diego, CA URL: http://www.usenix.org/events/lisa05/cfp/ STARWest - Software Testing Analysis & Review Proposals: Due May 20, 2005 Date: November 14-18, 2005 Loc: Anaheim, CA URL: http://www.sqe.com/starwest/speak.asp Might be good for the paper on our bug fixing process... And there's probably more conferences out there... Google around to see if there's an appropriate you think would be worth submitting a proposal to. Bryce

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 02 Feb '05

02 Feb '05

Yah, we had done that for the files in src and in dialogs. I don't think it was even attempting to build them before we edited the Makefile_insert files... Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Bryce Harrington Sent: Saturday, January 29, 2005 3:30 PM To: Montgomery, Steven S Cc: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkboard linking/dependencies On Sat, 29 Jan 2005, Montgomery, Steven S wrote: > Where/how do you set dependencies in the Inkscape makefile setup? When > integrating this new code(which is of course in it's own file) to be > called from a dialog, we're having issues with linking. It finds the > function definition, but then gives the following error: > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xa91): In function > `sp_inkboardConnect_dialog_inkboardConnect(_GObject*, _GObject*)': > dialogs/inkboard-connect.cpp:226: undefined reference to > `connect_and_auth(char*, char*, char*)' > > connect_and_auth is defined in src/inkboard.cpp and is called from > src/dialogs/inkboard-connect.cpp when the user clicks a button on the > new dialog. > > I ran mkfiles.pl and mkdep.pl. Make.dep lists inkboard-connect.o being > dependent on inkboard.h, but it's not picking up the function > definition. > > We appreciate any help/direction on this. Thanks, > Steven Hi Steven, Whenever you add a new file to the codebase, you need to add that file to the makefile as well. Look in src/Makefile_insert, and try adding a line to the libinkpre_a_SOURCES = .... section like this: inkboard.cpp inkboard.h \ You may also need to add inkboard-connect.cpp to the Makefile_insert in the src/dialogs directory as well. Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 2

incrementing ids and other findings
by bulia byak 02 Feb '05

02 Feb '05

OK, I think I understand now why removing "count++" was wrong in this commit: http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/src/sp-object.cpp?r… and why I had to restore it, having run into a bug. I think it might be interesting to others too, so I'm copying to the list. (Mental: one question/request for you is at the bottom.) Since count is a global static variable, before that change it was incremented on every object added to any document, no matter was there a conflict or not, including adding object on document loading. As a result, at each point of time, count was no less than the total number of element nodes in all loaded documents. After pjrm's change, count was incremented only for conflicting ids, i.e. very unfrequently. This produced nice small ids and worked fine, but only so long as you are within a single document. The badness of this approach was only evident when you copied things across documents. For example, imagine that you copy a group which has three objects, two of which use the same gradient and the third uses some other gradient. Then the defs_clipboard will contain three objects with ids, for example. gradient100 gradient100 gradient56 The second one is a copy of the first, but when it will be added on pasting to a different document, it will be re-ided. By itself this does not matter because the first copy of gradient100 will still be there and will be used, and the re-ided second copy will just be unused. However, since after pjrm's change count is small, and since the second document (where I'm pasting) may have few objects yet, the generated id for the second copy of gradient100 will have a small number in the new id. For example, 56. So when it's time to insert the gradient56 from the clipboard, it will clash and be re-ided too - now that's a big problem because the object that uses it will now refer to a wrong gradient. Sure, making count big enough does not prevent problems still. Clashes will occur until we reimplement the clipboard properly, with not only re-iding but also updating references to re-ided objects. But until then, the original approach which increments count on each added object is much safer, because it starts finding a new id skipping at least as many numbers as there are objects in _all_ loaded documents. (By the way, Peter, probably your idea in this change was to make ids shorter, but you didn't go far enough in that. You could just as well remove the global count altogether and start counting from 0 each time, until there's no conflict in the current document. This would have approximately the same effect as your change, but the code would become simpler. However, the entire idea behind the global count is to prevent not only the real intra-document conflicts, but also the potential cross-document conflicts, and from this viewpoint it would be still safer to do not only count++ on each added object, but even count+=99 or something like that.) You may ask, why does clipboard pastes two copies of the same gradient? This is a result of another change made by Mental. Pasting defs_clipboard has this check: SPObject *exists = doc->getObjectByRepr(repr); if (!exists){ SPRepr *copy = sp_repr_duplicate(repr); sp_repr_add_child(SP_OBJECT_REPR(defs), copy, NULL); sp_repr_unref(copy); } In 0.40 and before, this worked, i.e. after the first gradient100 was added, the second one would have exists != NULL and will be skipped. This was before getObjectByRepr was implemented via getObjectById and therefore only compared ids. Now it is rewritten differently and this check no longer works (i.e. exists is always NULL). Mental: I'm not sure why (or if) the new behavior is better, I just want to point out that it's different from the old one, and therefore there's a danger that it broke something else as well. Should we restore the old behavior, if only for backwards compatibility?

1 1

Fwd: Re: [office] [Fwd: clarification: OpenDocument and SVG]
by unknown＠example.com 02 Feb '05

02 Feb '05

FYI, we seem to have sparked some needed discussion... ----- Forwarded message from Bjoern Hoehrmann <derhoermi@...240...> ----- Date: Wed, 02 Feb 2005 16:20:29 +0100 From: Bjoern Hoehrmann <derhoermi@...240...> Reply-To: Bjoern Hoehrmann <derhoermi@...240...> Subject: Re: [office] [Fwd: clarification: OpenDocument and SVG] To: Michael Brauer <Michael.Brauer@...678...> * Michael Brauer wrote: >this is not the case on the element level. Reusing attributes from SVG >is considered to be very reasonable by our TC, because SVG is a >widespread and established standard already. However, we face the >problem that, if we want to reuse attributes from SVG, we need to >reference them from our own schema, although the attributes themselves >are contained in anonymous or per-element partition namespaces. (Note that www-svg is a public mailing list for SVG discussions, people on the list do not necessarily represent the SVG WG.) The cited example: <draw:rect svg:x = "2cm" svg:y = "3cm" svg:width = "10cm" svg:height = "20cm" svg:transform = "rotate(45)" draw:style-name = "object-with-shadow" xmlns:draw = "urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:svg = "http://www.w3.org/2000/svg" > is semantically equivalent to <qenj:erpg fit:k = "2pz" fit:l = "3pz" fit:jvqgu = "10pz" fit:urvtug = "20pz" fit:genafsbez = "ebgngr(45)" qenj:fglyr-anzr = "bowrpg-jvgu-funqbj" xmlns:qenj = "hea:bnfvf:anzrf:gp:bcraqbphzrag:kzyaf:qenjvat:1.0" xmlns:fit = "uggc://jjj.j3.bet/2000/fit" > which is semantically equivalent to <x/> unless you define something else. So you would have a specification that defines how user agents are expected to process a svg:width attribute on a draw:rect element. In that specification you could as well call the attribute { "file:///usr/bin/dahut", "largeur" } or { "", Breite" }, or whatever you like. From a specification point of view there is nothing to be gained from calling it { "http://www.w3.org/2000/svg", "width" }. So there is no actual need to use the SVG namespace (or any other name- space) to refer to "SVG attributes" and whether there is a benefit is quite questionable in my opinion. Using "http://www.w3.org/2000/svg" does however limit the ability of the SVG Working Group to define what {"http://www.w3.org/2000/svg", "width"} means in a specific context, in particular, if the SVG WG defines some- thing that is not compatible with the definition of the OpenDocument XML format, integrating the OpenDocument format with SVG would be difficult as you have to remove the ambiguity. As far as I can see, unless one considers familiarity with the string "http://www.w3.org/2000/svg" of any importance (like, easier to type/ remember than e.g. urn:oasis:names:tc:opendocument:xmlns:drawing:1.0), there is not really much point in using the SVG namespace, or in fact any other namespace. Why not call it { "", "width" } instead? -- Björn Höhrmann · mailto:bjoern@...679... · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ----- End forwarded message -----

1 0

Re: Bug Status for 0.41 -- 1/27
by Bryce Harrington 02 Feb '05

02 Feb '05

Wow, 45 points worth of bugs closed today has put us well over the top of our goals. Nice! :-) Bug ID# PRI Owner Description ------------------------------------------------------------------------ 1095300 6 ishmal WIN: Save as: no formats to choose from 1082188 9 joncruz Linux: File->Import crash 1044322 6 joncruz Relative Locations <image> tags. 1085586 6 bulia Error in opening AI / EPS file 1103936 6 bulia Bad markup found in translations 1109223 6 mental CVS: Error using calligraphy tool 1108231 6 mental sp_repr_set_position_absolute breakage 1108620 9 joncruz Drag and drop case sensitive 1107775 3 pjrm wrong paper sizes 1105787 9 johncl Installation problem: libatk-1.0-0.dll not found 990677 6 ted readme needed for extensions 1107562 9 bulia Node Align Crash 1101210 3 bulia CVS: Flowtext not working 1103001 3 ted Grid is shown non-uniform 1102318 9 kees Crash on "save as" 1104741 6 bulia Printout 25% too large 1105352 6 pjrm Markers are not shown in Plain-SVG-Export 1075860 9 pjrm WIN: assert when doing stamping during move 1080252 9 bryce crash on intersectiion 1068116 6 mental complie error in gc.cpp with inkscape-20041116 1076872 6 kees ngettext isn't used 933461 6 kees Win32 Install Directories 1068299 6 kees Build failure on mips(el) 1100675 6 mental svg tag requires xmlns attribute in CVS2005-01-10 1097652 9 pjrm crash on whitespace property value ------------------------------------------------------------------------ Current: 165 Goal: 150 Feature Freeze - Jan 26 Hard Freeze - Feb 1 Release - Feb 5-6 Bryce On Sat, 8 Jan 2005, Bryce Harrington wrote: > Okay, since there were no comments to the contrary, I suppose it's safe > to assume this proposal is acceptable to everyone. If not, lemme know. > We'll shoot for 150 points for low/med/high (3/6/9 pts) that are closed > as FIXED (i.e., no points for dups, won't fix, invalid, etc.) and that > are confirmed as present in 0.40 or in CVS. > > Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

4 9

default shape prefs?
by Kees Cook 02 Feb '05

02 Feb '05

Can we make the default shape prefs as colorful as they used to be? Right now if I start up inkscape without prefs, they're just black shapes. I liked the partially see-through yellow, blue, red, etc. -- Kees Cook @outflux.net

7 22

Possible delay in Hard Freeze
by Bryce Harrington 02 Feb '05

02 Feb '05

We're scheduled to hard freeze today 2/1, however it sounds like there are still some outstanding must-fix bugs, and that some new bugs have appeared in the codebase recently. I think we can hold off making a decision until later tonight, and it sounds like the remaining bugs are simple fixes, so it's possible that we could still make it, if people can make some time tonight to fix bugs. We've been doing good at slaughtering bugs lately so I think there's a good chance of this. :-) If not, then we can postpone the release a bit. It'd be impressive if we could make the date, but we're in no particular hurry so can delay if it'll result in a better product. In any case, please be especially communicative about the status of the must-fix bugs you know about; the more we know, the quicker we can get more eyes on the ones that need it. Bryce

3 3

Inkscape Project Status Feb 1, 2005
by Bryce Harrington 02 Feb '05

02 Feb '05

We're getting close to the 0.41 release. We're not quite ready for a hard freeze, as there's still several must-fix bugs left, but hopefully soon we'll enter that phase soon. It's worth special mention that there has been some surprisingly successful work done during this bugfix phase on fixing some nasty old crash bugs that have been sitting in our bug tracker for quite a while. It looks like the past two weeks have seen a number of new Inkscaper's judging from the jump in Inkscape-devel@ mailing list membership numbers. Welcome aboard everyone. Looking forward beyond 0.41, once the release is out the door the focus will shift fully towards the GUI redesign work. Much has already been done in this area, but even more work remains. Fortunately for us, GUI work tends to be quite noticeable by nature, so I think in coming months our progress will be highly visible. Statistics Jan 1 Jan 15 Feb 1 ========== ===== ====== ===== Lifetime Rank on SourceForge: 598 570 569 (95.8%) (96.0%) (96.0%) Max Week's Rank on SourceForge: 45 72 * (99.8%) (99.6%) * Total SF Page Views 2,213,324 2,283,160 2,296,458 Total SF Downloads 110,182 114,695 115,645 Total Freshmeat URL Hits 14,291 14,634 15,108 Total Freshmeat Subscriptions 149 151 156 Lines of Code in src/: 321,883 323,251 323,324 Code lines 227,114 227,965 227,872 Comment line 56,048 56,308 56,438 Blank 45,398 45,664 45,624 Lines of Docs in doc/: 17,901 17,901 17,918 Lines of content in website: 9,234 9,328 9,486 Size of the Inkscape wiki: 21,030 20,931 23,576 Bugs open/total: 135/829 145/858 148/917 Features open/total: 340/514 353/530 352/556 Patches open/total: 5/145 6/148 7/154 CVS Commits (as per inkscape-cvs) 9,450 9,625 9,975 Inkscape-devel membership: 132 131 143 Inkscape-announce membership: 147 155 166 Inkscape-user membership: 172 177 181 Num Translations: 33 33 33 Ave Translation Ratio: 43.7 42.0 44.7 * - Statistics unavailable

1 0

thanks!
by Jakub Steiner 02 Feb '05

02 Feb '05

Hi guys, before I get to provide some hopefully useful feedback to you guys, I just wanted to say thank you guys for the work you've done on Inkscape. I can see you're steering the ship towards the right direction - making a nice tool for an _artist_ to draw vector illustrations. I'm aboard! ;) -- Jakub Steiner <jimmac@...659...>

10 11