Inkscape Trademark Policy
by Bryce Harrington
Hi all,
One of the Inkscape Board's actions in 2013 was to establish a trademark
policy for the Inkscape name and logo. With the Software Freedom
Conservancy's help we've completed the registration and documented under
the About menu item on the website:
http://inkscape.org/en/about/trademark-policy/
The motivation for doing this was due to questions that kept cropping up
from people wanting to use it for legitimate purposes (e.g. using our
unmodified logo on merchandise), and from people noticing our trademark
used illegitimately (e.g. selling unrelated software using our name or
logo). We wanted a policy that would provide clear guidance for all
these uses, that would be liberally permissive for non-commercial and
FOSS-friendly commercial uses, while prohibiting obviously fraudulent
uses.
Along with this, I've added a FAQ entry (below) with a brief summary.
Bryce
== FAQ: How are the Inkscape name and logo protected? ==
The Inkscape name is trademarked under U.S. Trademark Law, and held and
administered by the Software Freedom Conservancy. Our policy is
available on the website, and describes the conditions under which you
can use our name and logo. We've aimed to make our requirements
reasonable and friendly: We want to avoid things like other groups
claiming to be or represent us when they don't, or to distribute our
software in ways that aren't consistent with our license.
The logo is similarly trademarked and covered by our trademark policy.
We're cool with people creating derivative works that help promote
Inkscape or make it fit in with a given user interface style, but we
don't want to see it abused by companies that might incorporate it into
their own logos. For merchandising, you are welcomed to use our
unmodified logo; for anything else, please contact the Inkscape Board
for permission.
9 years
Waf build system, second try
by Krzysztof Kosiński
Hello everyone,
I conducted an experiment in building Inkscape with Waf, redoing the
work I did a long time ago with a newer version (1.7.15) and using
more of its features. A correct build of Inkscape, with internal
libraries built separately, "inklib" built as a shared library, Bazaar
revision fetching and .po file compilation, requires less than 250
lines of Python script (!!!).
I read on some mailing lists that Debian refused to package some
software using Waf, because Debian considers shipping the "Waf binary"
to be incompatible with the DFSG. I circumvented this problem by
adding the Waf source distribution to the tree, which is a little
bigger, but DFSG-compliant and works exactly the same.
The code will be up shortly at lp:~tweenk/inkscape/waf-build, if
anyone wants to check it out.
Regards, Krzysztof
9 years
Re: [Inkscape-devel] Waf build system, second try
by Johan Engelen
Hi Isobel,
I'll be on vacation for a week, can't give a detailed answer now. But I am not the right person to ask anyway :)
I think _building_ is the easy part, but getting all the include flags correct for all platforms is not. (which is "configuration" that you mean?)
An example of what would be nice to have is the ability to specify additional compiler flags for each folder.
Current architecture's biggest problem is that it is not crossplatform. Note that on Windows, cygwin is cumbersome and not something we want to do.
ciao, Johan
----- Reply message -----
From: "Isobel Knowles" <ik5@...2950...>
To: "Johan Engelen" <jbc.engelen@...2592...>
Cc: <inkscape-devel(a)lists.sourceforge.net>
Subject: [Inkscape-devel] Waf build system, second try
Date: Fri, Jan 31, 2014 00:14
On Thu, 30 Jan 2014 20:11:14 +0100
Johan Engelen <jbc.engelen@...2592...> wrote:
>
> On 30-1-2014 20:02, Isobel Knowles wrote:
> > PS. My offer to write some 'nice' makefiles is still open.
>
> No-one is stopping you :-)
> Make us dazzle...
>
> :)
> Johan
Dear Johan,
OK. Before I do, do you think you could tell me what it is you want
from the build? What are the essentials and what are the nice-to-haves?
Where do you see the problems in the current architecture and what are
its strengths?
I'm only after some pointers so I don't set off in the wrong direction.
I'll start the ball rolling with these:
- Documentation. People who are new to Inkscape should find it easy to
edit the makefiles.
- Separate configuration and build cleanly so when the configuration
phase doesn't do what you want for one reason or another, it is
straight-forward to manually configure the build options in one or
two files.
- Separate compilation and installation/packaging. Installation is
generally performed as root, and all too often in GNU software libtool
and the like get their teeth into a 'make install', turning it into
compilation job. This is wrong.
- An ordinary build job should do the minimum work in the minimum time.
For this I propose a flat makefile structure, perhaps composed of
included makefiles. Parallel makes like this perform correctly and
have no scalability issues whereas recursive makefiles are beset with
problems and complication.
- It should be simple to modify build flags and make alternative
targets for debugging purposes.
I wouldn't describe it as dazzling, but it's a start.
Yours,
Is.
9 years
Copying text with pattern stroke and fill + text decoration issue
by mathog
Hi all,
After adding pattern fill and stroke support for text decoration I found
that if both text decoration and a pattern are active, then trying to
copy a text object with that combination crashes inkscape. That is, in
rough terms, if the input file contains:
<text >
<tspan
style=" pattern fill " >
A
<tspan style="text-decoration:underline">B</tspan></tspan></text>
it loads and renders properly. But if "AB" is selected as an object
(not as the text) and "^c" to copy, it crashes in style.cpp in
sp_style_paint_server_ref_modified because "server" is not the same as
style->getStrokePaintServer() (or
style->getTextDecorationStrokePaintServer(), but these last two are
identical in the test cases.) That is (sorry about the wrap):
(gdb) print *server
$1 = {<SPObject> = {_vptr.SPObject = 0x8a13e48, cloned = 0, uflags = 0,
mflags = 0, xml_space = {set = 0, value = 0}, hrefcount = 1,
_total_hrefcount = 1, document = 0x9232a80, parent = 0xa082ad8,
children = 0xa086210, _last_child = 0xa086210, next = 0xa0c2ea8,
id = 0xbadc000 "Packedcircles", repr = 0xbbb26f0, refCount = 4,
style = 0xa096200,
_release_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> =
{<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0},
impl_ = 0xa0f6d48}, <No data fields>}, <No data fields>},
_delete_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> =
{<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0},
impl_ = 0x0}, <No data fields>}, <No data fields>},
_position_changed_signal = {<sigc::signal1<void, SPObject*,
sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> =
{callback_list_ = 0x0},
impl_ = 0x0}, <No data fields>}, <No data fields>},
_modified_signal = {<sigc::signal2<void, SPObject*, unsigned int,
sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {
callback_list_ = 0x0}, impl_ = 0xa0765e8}, <No data
fields>}, <No data fields>}, _successor = 0x0,
_collection_policy = SPObject::ALWAYS_COLLECT, _label = 0x0,
_default_label = 0x0}, swatch = false}
(gdb) print *style->getTextDecorationStrokePaintServer()
$2 = {<SPObject> = {_vptr.SPObject = 0x8a13e48, cloned = 0, uflags = 0,
mflags = 0, xml_space = {set = 0, value = 0}, hrefcount = 7,
_total_hrefcount = 7, document = 0x9232a80, parent = 0xa082ad8,
children = 0x0, _last_child = 0x0, next = 0xa099530,
id = 0xa059ab0 "pattern5506", repr = 0xbbb5ff0, refCount = 1, style
= 0xa07be48,
_release_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> =
{<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0},
impl_ = 0xa0ccfc0}, <No data fields>}, <No data fields>},
_delete_signal = {<sigc::signal1<void, SPObject*, sigc::nil>> =
{<sigc::signal_base> = {<sigc::trackable> = {callback_list_ = 0x0},
impl_ = 0x0}, <No data fields>}, <No data fields>},
_position_changed_signal = {<sigc::signal1<void, SPObject*,
sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> =
{callback_list_ = 0x0},
impl_ = 0x0}, <No data fields>}, <No data fields>},
_modified_signal = {<sigc::signal2<void, SPObject*, unsigned int,
sigc::nil>> = {<sigc::signal_base> = {<sigc::trackable> = {
callback_list_ = 0x0}, impl_ = 0xa0e8fd0}, <No data
fields>}, <No data fields>}, _successor = 0x0,
_collection_policy = SPObject::ALWAYS_COLLECT, _label = 0x0,
_default_label = 0x0}, swatch = false}
It seems like the objects are put together differently when they are
copied than when they are just read in. The clue comes from the
"pattern5506" above. That ID isn't in the original file, it is somehow
created during the copy operation. Can somebody tell me where that is
happening? The object construction when the file is opened or reverted
is in style.cpp, if the copy feeds through there too, I guess the
question becomes "where is the SVG created" that is fed into it.
If the text-decoration just uses solid colors and fills there are no
issues copying a complex formatted text object with text decorations.
It is only when patterns and text decorations are both present that
things go south.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Trunk is broken enough to merit complaining
by Josh Andler
Hey All,
Thankfully it's been a while since this has been an issue, but it
seems that a reminder is needed. The only real rule we tend to have
for committing to trunk is "don't break trunk". Unfortunately, trunk
is currently pretty broken when trying to work with imported bitmaps.
If whomever broke it can get back to fixing it, it would be greatly
appreciated.
In the future, just remember, if you won't have the free time within 1
day to fix something you might have accidentally broken... please wait
to commit it until you do. If you can not figure out an appropriate
fix, please revert the changes and work via patches in the tracker or
in a branch until you can figure it out (so others can help test).
Cheers,
Josh
9 years
Re: [Inkscape-devel] Trunk is broken enough to merit complaining
by mathog
> Thankfully it's been a while since this has been an issue, but it
> seems that a reminder is needed. The only real rule we tend to have
> for committing to trunk is "don't break trunk". Unfortunately, trunk
> is currently pretty broken when trying to work with imported bitmaps.
> If whomever broke it can get back to fixing it, it would be greatly
> appreciated.
It's more broken than that, unfortunately, since on my Ubuntu test
machine the inkscape binaries from 12978 on no longer even get to the
point where they put any graphics on the screen. The reason it is
crashing is complex enough that it really is above and beyond the call
of duty for other developers to have to figure it out. (For instance,
the failure mode is different in the debugger than outside of it.) So,
Martin, please pull out all of the image changes from around 12939
through 12978 and test them for a while in a separate branch. Before
resubmitting them to trunk, please have people test your branch on other
platforms. Or at the very least run valgrind on it and make sure there
are no (new) memory access issues in the code you are adding.
(Admittedly this is a bit of a pain since there are already so many
memory issues in Inkscape.)
These image changes must have worked on Martin's machine, presumably
because the memory problems didn't happen to blow up anything there, but
they are show stoppers for me.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Writing Tests for URI
by Martin Owens
Hi devs,
I want to write a test suite for uri.h/uri.cpp; I had a look to see if
there are existing tests for the code and I admit I find myself a little
confused. There's a directory called cxxtest which contains tests and
then there are *-test.h files in the actual codebase.
My feeling is to use extract-uri-test.h, copy it for a new uri-test.h
file. But this might be wrong.
New URI functionality includes: dealing with data uri, getting full path
name (previous work) and further intergration between it and
io/uristream.cpp to feed that lovely data in transparently when needed.
Should conclude with the ability to quickly move any href from attribute
to workable data.
Martin,
9 years
Bug Hunt for 0.91
by Bryce Harrington
Welcome to the first bug hunt for the 0.91 release. This hunt focuses
on regression bugs.
Traditionally, we specify a point target for us to reach, and award us
points based on the severity of the bug: 3, 6, 9, or 12 points for low,
medium, high, and critical. This bug hunt's goal is 500 points worth of
bugs from the following list:
http://tinyurl.com/bughunt91a
You'll note a few dozen regressions were already fixed, so we'll count
that as a (207 point) headstart on the effort. Here's a couple more
links to list only the open or closed bugs:
http://tinyurl.com/bughunt91a-open
http://tinyurl.com/bughunt91a-closed
[I'll write a launchpadlib script to calculate the score from the latter
list, unless someone's ambitious and beats me to it!]
We only give points for true bug fixes - not bugs simply closed due to
being dupes, invalid, works-for-me, or whatnot. Once the bug is fixed
in the mainline branch, set its status to Fix Committed, and it'll tally
as a fixed regression.
Bug Hunt Goal: 500 points
Current: 207 points
If you're not a developer, you can still help by seeing if you can
reproduce the bug yourself, and posting your findings.
If you have an idea on how to fix the bug, but don't have the time to do
it yourself, then outlining your thoughts on the bug may help junior
developers pick it up and implement the changes.
If you're an experienced developer, consider posting an invitation to an
IRC bug party for the time period you'll be working, if you're willing
to help pilot junior developers and sponsor their patches.
I will be posting scoring updates a couple times a week until we're
done.
Bryce
9 years
Cairo and ISO C++
by Tavmjong Bah
Hi,
There is a proposal before the ISO C++ standards group for a technical
specification for 2D graphics based on the Cairo API.[1] It seems to
have gained some traction. My question here is what is missing in the
Cairo API that would be useful for rendering SVG?
Tav
[1] http://isocpp.org/files/papers/N3888.pdf
9 years
Strange Error
by Arshdeep Singh
Hi,
I participated is GSoC 2013 and wrote code for Inkscape. I was working in
WIndows last year and sometime around December I decided to port my branch
to Linux (Ubuntu 12.10 , in my case) . Strangely, I am caught up with this
error, which doesn't trouble me at all in my Windows branch:
"ui/dialog/dialog-manager.o: In function
`Inkscape::UI::Dialog::RecolorArtwork::getInstance()':
/home/arshdeep/Desktop/InkS-Repo/recolor/src/./ui/dialog/recolor-artwork.h:38:
undefined reference to
`Inkscape::UI::Dialog::RecolorArtwork::RecolorArtwork()'
collect2: error: ld returned 1 exit status
"
This happens only when I am associating a dialog box of the tool that I
made last year thorugh the codeline:
" registerFactory("RecolorArtwork", &create<RecolorArtwork,
FloatingBehavior>); "
inside of dialog-manager.cpp.
The RecolorArtwork class is mirrored directly from FillAndStroke class and
I can't pin point why this error crops up ? If someone can help , please do
so.
--
Arshdeep Singh
Third Year, Computer Engineering
Delhi Technological University
Ph: +91-9654115614
https://sites.google.com/site/adsingh1729/home
9 years
