- Inkscape Devel - Inkscape Mailman

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

clarification: OpenDocument and SVG
by MenTaLguY 02 Feb '05

02 Feb '05

Jon, to restate the issue more concisely: The OpenDocument specification, which is under consideration as an EU standard[1], introduces a number of XML attributes into the SVG namespace that are not part of the SVG standard. For example, there is a non-standard svg:width attribute that is applied to non-SVG elements to specify width[2]. My concern is that if OpenDocument gets standardized by the EU in its current state, that would set a really ugly precedent for putting non-standard extensions in W3C-specified namespaces. I have gone ahead and CCed the SVG WG staff contact and the OpenDocument Committee secretary. Hopefully I've not wasted anyone's time, and they can talk to the appropriate people in each group and put the issue to rest quickly. -mental --- [1] http://www.groklaw.net/article.php?story=20050130002908154 [2] The most recent draft of the OpenDocument specification (Dec 2004) I could find is available here: http://www.oasis-open.org/committees/download.php/10765/office-spec-1.0-cd-2 Section 9.2 of the specification, which starts on page 275, is most relevent. Here is an example from section 9.2.1: <draw:rect svg:x="2cm" svg:y="3cm" svg:width="10cm" svg:height="20cm" svg:transform="rotate(45)" draw:style-name="object-with-shadow"> (in this example the 'draw' prefix is bound to the urn:oasis:names:tc:opendocument:xmlns:drawing:1.0 namespace, and 'svg' to the http://www.w3.org/2000/svg namespace)

1 0

Spammers have found wiki
by Khiraly 02 Feb '05

02 Feb '05

Hi! I think this page does not have the right content: http://www.inkscape.org/cgi-bin/wiki.pl?Inkscape However I dont know what would be the best solution for this. Maybe registration for the wiki? Best regards, -- Khiraly <khiraly123@...240...>

4 5

wiki spam
by bulia byak 02 Feb '05

02 Feb '05

It looks like 82.194.62.17 and 193.188.105.16 automatically spam our wiki, they spammed pages minutes after my reversals. I reverted them several times, but then quit, so they're likely spammed again now. Maybe it's time to change the password, make it random for each page, and less easy to extract from the text. And in any case, please ban those IPs.

7 11