Inkscape Project Status Feb 1, 2005
by Bryce Harrington
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
18 years, 8 months
thanks!
by Jakub Steiner
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...>
18 years, 8 months
clarification: OpenDocument and SVG
by MenTaLguY
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)
18 years, 8 months
wiki spam
by bulia byak
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.
18 years, 8 months
Re: [Inkscape-devel] wiki spam
by Bryce Harrington
On Tue, 1 Feb 2005, Alan Horkan wrote:
> On Tue, 1 Feb 2005, Bryce Harrington wrote:
>
> > Date: Tue, 1 Feb 2005 10:53:31 -0800 (PST)
> > From: Bryce Harrington <bryce@...260...>
> > To: mental@...3...
> > Cc: bulia byak <buliabyak@...400...>, inkscape-devel(a)lists.sourceforge.net
> > Subject: Re: [Inkscape-devel] wiki spam
> >
> > All of the suggestions in this thread are viable options, although some
> > will require more work than others:
> >
> > * Changing the password: Trivial, easy to do
> > * Blocking more IP's: Trivial, easy to do
> > * Adding basic auth login: Requires sysadmin work + ongoing account admin
>
> I assumed it was already built in to the wiki and all that would be
> required would be to turn it on.
Well, it does have a sitewide password that can be turned on for
editing, but it'd be the same password for everyone. But that's
essentially what we've got currently so really the next step would be to
turn on either basic auth (implemented in Apache) or a more advanced
auth mechanism (implemented ourselves).
Note that anything we do is going to have have tradeoffs: Either more
implementation work, more administrative work, more work on the part of
the user, or a combination. For example, like you point out,
image-based passwords won't require admin work, but will require some
implementation work, and increases the burden on users (esp. those with
vision imparements). Having two different systems (image passwords or
authentication), gives the users options but at the cost of double
implementation work, and doubling our risk (spammers only need to find a
way to attack one of the systems).
There is one other programmatic defense that I know about for wiki's.
For many bots, there is an inhumanly short period of time between when
they click edit and when they submit the page, so apparently if you make
the wiki keep track of this time and it's less than a few seconds, then
you can make a fairly safe assumption that it's a bot. Our wiki doesn't
have this feature, but I would bet that a good perl hacker could figure
out a good way to implement it. The advantage of this system over
others is that while it wouldn't stop all spamming, at least it would
not impose additional administrative or user effort and it might cut
down some of the spammers. I bet it would be especially effective at
the spammer Bulia was fighting today. Anyone feel like giving it a
shot?
Bryce
18 years, 8 months
bug 1079194
by Jon A. Cruz
Given that bug 1079194 is a bit ambiguous, and that there's ongoing
effort for other bugs that may have alread fixed this, I'm thinking of
bumping it over to pending.
Sound reasonable?
18 years, 8 months
Re: [Inkscape-devel] Updated spanish translation
by Lucas Vieites
On sáb, 2005-01-29 at 13:14 -0800, Arpad Biro wrote:
> Hi,
>
> I'm sending the current CVS version attached.
>
> After receiving your latest translation, I compared it (cmp) to that
> file, and they matched byte by byte.
>
>
You were right, my bad. I had translated the file directly in my local
cvs tree and then I sent you the one in my working directory. I found
out a while ago when I did a cvs update and the es.po file gave an
error.
Now I'm attaching an fresh update from today's cvs.
Cheers,
--
Lucas Vieites Fariña
Dept. Desarrollo <lucas@...212...>
Asix Informática <http://www.asixinformatica.com/>
Tel/Fax: +34 986 54 26 98
18 years, 8 months
Re: [Inkscape-devel] default shape prefs?
by unknown＠example.com
Quoting bulia byak <buliabyak@...400...>:
> On Mon, 31 Jan 2005 13:44:51 -0500, mental@...3... <mental@...3...>
> wrote:
> > Quoting bulia byak <buliabyak@...400...>:
> >
> > > Well, though the function is mine, I didn't write this comparison, but
> > > copied it from somewhere. If you fix it I'll copy the correct idiom
> > > next time :)
> >
> > The correct idiom, provided I had done things properly on my end, would be
> no
> > cast at all. The compiler ought to be aware that SPCSSRepr ISA SPRepr.
>
> does not work:
>
> desktop-style.cpp: In function `SPCSSAttr*
> sp_desktop_get_style(SPDesktop*, bool)':
> desktop-style.cpp:166: error: invalid use of undefined type `struct
> SPCSSAttr'
> xml/xml-forward.h:6: error: forward declaration of `struct SPCSSAttr'
Well, you would still need to make a couple minor cleanups. The forward
declaration in xml/xml-forward.h is (I think) unnecessary (actually the whole
file is unnecessary and a bad idea, but I will rant about that separately).
I think I'm going to go ahead and redo the Repr CSS stuff the right way tonight
though.
-mental
18 years, 8 months
