status & plans
by bulia byak
Looks like the drawing tools crash (1107922) is going to be fixed
soon. The other crash bug (1113187) seems to be easy, and the svgz
loading on windows is a matter of supplying a correct DLL. So, we're
close.
Once all these are resolved, I think we need to make one prerelease
which would be tested for 2-3 days, and then do the final release if
nothing critical is found. This time I'd very much like the prerelease
to have a Windows binary as well (0.40 prereleases didn't).
Will someone be willing to provide it?
18 years, 7 months
new bugs
by bulia byak
I consider these two bugs to be MUSTFIX as well:
- the one found by Kees (without pref file, objects are drawn black),
see my post with more details on why this happens
- the new crash on load:
http://sourceforge.net/tracker/index.php?func=detail&aid=1113187&group_id...
The first of these bugs appears mild, but they both are in the new
repr code by Mental and therefore may be signs of something more
sinister which we haven't found yet. And both are regressions compared
to 0.40.
Mental, will you please look into them? If you need my help I'll do
what I can, though currently I'm swamped by work.
18 years, 7 months
typos and a translation question
by Arpad Biro
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
18 years, 7 months
Papers on Inkscape
by Bryce Harrington
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
18 years, 7 months
RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S
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
18 years, 7 months
incrementing ids and other findings
by bulia byak
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...
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?
18 years, 7 months
Fwd: Re: [office] [Fwd: clarification: OpenDocument and SVG]
by unknown＠example.com
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 -----
18 years, 7 months
Re: Bug Status for 0.41 -- 1/27
by Bryce Harrington
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
18 years, 7 months
default shape prefs?
by Kees Cook
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
18 years, 7 months
Possible delay in Hard Freeze
by Bryce Harrington
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
18 years, 7 months
