Re: [Inkscape-devel] Version number
by Jared Meidal
My vote is for Inkscape 5, pointing to maturity of the .4x.x line, and to demonstrate overall reliability and maturity of the application.
My secondary vote, would be for Inkscape 0.91, moving toward a 1.0 release.
Overall it would be great to update a features-to-version-number page to help map where we are, and where going.
--Jared
> I wrote that in as more a placeholder, way, way back when. At the time
> we had consensus that Inkscape wasn't mature enough in terms of features
> and stability to justify calling it 1.0. I wanted to keep that as a
> goal in the roadmap, and to tie it to something tangible. SVG 1.0
> seemed like a logical place to put a pin in, but there wasn't a huge
> amount of thought put into it. It could easily have been "Switch to
> Cairo for rendering."
> > I can see the next major release after 0.48.x as a candidate for change as the "9'er" may lend itself toward a new scheme.
> >
> > * 0.49.0 --> 0.90.0 (followed by 1.0, 1.1, 2.0...)
> This sounds like a good approach. Might go to 0.91 just to avoid the
> usual confusion people have with our 0.x0 releases (i.e. people will
> call it version 0.9.
> > * 0.49.0 --> Inkscape 9 (followed by Inkscape 9.1, 10.0...)
> Seems like tooo big of a jup.
> We also discussed date based version numbers. At the time it was quite
> a fad and a lot of projects were adopting that. Seems less widely used
> now, except by projects that follow strict time-based release
> schedules, like distributions.
> > There have been a lot of excellent developments to be release in the next release, including C++, cairo, alignment/distribution along with new possible builds on win64-bit (Partha's help), and native Mac OS X (some almost-ready builds are out there). If these all reach maturity for the release the new builds are providing an increase audience and userbase. A changing version numbering scheme could reflect the developers' acknowledgement of this and demonstrate the activity of the software project.
> Yep.
> Bryce
> >
> > Just IMHO,
> >
> > --Jared
10 years
Gradients with objectBoundingBox coordinates not being preserved or rendered correctly
by Bryan Hoyt | Brush Technology
If I create a gradient in Inkscape, the default coordinate space is
userSpaceOnUse, as opposed to objectBoundingBox (see
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/gradientUnits).
This is ok, but if I edit a gradient manually (via a text editor or the XML
editor) to change it to objectBoundingBox coordinates, I would like it to
stay that way.
objectBoundingBox gradients are very useful if you want to animate or
otherwise interact with the SVG using javascript in a browser -- the
gradient will move relative to the object, and you don't have to write
extra complicated code to try and keep it lined up.
Currently,
*a)* Inkscape initially renders the gradient nodes in the correct position,
but does not render the gradient colours themselves. So the object has a
flat colour.
*b) *As soon as I drag one of the endpoints, it reverts to userSpaceOnUse
coordinates.
Which means that it becomes quite difficult to edit my SVG file in Inkscape
ever after! Ideally, the object would be coloured correctly, and if I move
a node or endpoint, it would remain in objectBoundingBox coordinates.
Better yet, there would be a way to switch to objectBoundingBox coordinates
from within the GUI, to avoid having to calculate the conversion maths in
the XML editor.
How hard would those things be to fix?
- Bryan
--
Bryan Hoyt, *Software Developer* -- Brush Technology
*Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955
*Web:* brush.co.nz
10 years
clang-format
by Johan Engelen
Hi all,
clang-format seems like a great tool to reformat our whole codebase
once and for all, and keep it that way.
I've added a configuration file "_clang-format" to trunk, hoping that
others can have a look at it too and tweak the settings for our project.
Can you have a look at this Krzysztof?
(my bigger ambition is to run clang-format on the whole codebase after
we branch-off the next release)
Thanks,
Johan
10 years, 1 month
clipping and filters, import and export for formats other than SVG?
by mathog
SVG supports both clipping and filters. Some other formats do as well,
for instance, EMF+, (although the supported filters do not match very
well between SVG and EMF+).
I can see how one would convert those features from other graphics
formats to SVG during import (more or less).
However, for output to another file type I do not see where either the
clipping or filters would be passed, perhaps buried in style?
I thought that maybe the clipping was applied upstream somehow, so that
the driver level would just draw what was left, but could not test the
idea because it seems that clipping has some problems in Trunk right
now.
For instance, I found this SVG example on the web:
http://svg-whiz.com/svg/clipRect.svg
and while it loaded into Inkscape (linux or Windows) without throwing a
warning or error, and the contents show up in the XML editor, nothing is
visible on the screen. That example works in 0.48.4, but not r12721.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
10 years, 1 month
Re: [Inkscape-devel] clipping and filters, import and export for formats other than SVG?
by Krzysztof Kosiński
2013/10/30 mathog <mathog@...1176...>:
> On 30-Oct-2013 11:51, Krzysztof Kosiński wrote:
>>
>> 2013/10/30 Martin Owens <doctormo@...400...>:
>>>
>>> I'd take our workspace at 1:1 and use that. Otherwise it's not really a
>>> useful value since the svg isn't being used as a fragment.
>>
>>
>> Perhaps we should pick some totally arbitrary default values in this
>> case, such as 640x480px.
>
>
> Arbitrary for sure, since it is not specified in the SVG.
>
> Use the default page size?
The default page size depends on the locale, so I'd rather not use that.
Regards, Krzysztof
10 years, 1 month
message: 8 svg width 100%
by Jelle Mulder
Krzysztof,
<svg width='100%' height='100%' xmlns='http://www.w3.org/2000/svg'
xmlns:xlink='http://www.w3.org/1999/xlink'>
This actually is valid SVG and can be quite useful for web design (I would
use only one direction BTW). I always found it a pity Inkscape does so
little with % as part of the beauty of SVG is the use of such values for
scaling of objects. I believe % are not accepted in Inkscape and setting
the size of an object to 50% will just scale the object rather than make
it set to 50% values.
Use case for it is for web designs that align objects to a centre point,
scale rects to 20% of the right edge of the screen etc. It is valid SVG,
but probably a lot of work to implement. Now though I always have to
handcode that kind of stuff, so it would be way cool to let Inkscape set
those values. Basically all you need to know is the size of the user
screen, which can't be that hard either.
Think how easy it would be to use % for doing hatch patterns, using
nothing but a dash array and a line in a clip area the size of the object
the hatching should be in. One line, line hatch + dash array, two lines +
dash array, cross hatch with patterns. It renders fine in a browser.
At least Inkscape can figure out that 100% should display the document in
the screen resolution in this example.
Cheers,
Jelle
On Thu, 31 Oct 2013 00:36:14 +0800,
<inkscape-devel-request(a)lists.sourceforge.net> wrote:
> Message: 8
> Date: Wed, 30 Oct 2013 17:36:04 +0100
> From: Krzysztof Kosi?ski <tweenk.pl@...400...>
> Subject: Re: [Inkscape-devel] clipping and filters, import and export
> for formats other than SVG?
> To: su_v <suv-sf@...58...>
> Cc: Inkscape Devel <inkscape-devel(a)lists.sourceforge.net>
> Message-ID:
> <CAFLw2WRCgm0w90+gqRAjx-oc3bnw6Z-KAmatfa2Z9==BWq940Q@...401...>
> Content-Type: text/plain; charset=UTF-8
> 2013/10/29 su_v <suv-sf@...58...>:
>> This SVG file has width=height=100% and no viewBox attribute:
>>
>> <svg width='100%' height='100%' xmlns='http://www.w3.org/2000/svg'
>> xmlns:xlink='http://www.w3.org/1999/xlink'>
>>
>> which results in a miniscule (1x1 px) document page size with current
>> trunk (rev >= 12554). Other than that, the drawing content and the
>> clipped objects displays correctly AFAICT.
> Does anyone know what are we supposed to do in this case? I don't
> think it's even valid SVG.
> Regards, Krzysztof
10 years, 1 month
[icons.svg]How to add/use a new icon
by Maggio Mago
Hello everyone,
How to add and use a new icon in Inkscape in C/C++ according to
{$prefix}/share/inkscape/icons/icons.svg ?
Maybe someone has already written an article on this issue.
In advance thank you
10 years, 1 month
Spurious warnings
by Johan Engelen
Hi all,
I've been going through a (really small) number of compile warnings
and stumbled upon this one:
src/2geom/generic-interval.h: In member function 'Geom::Rect
Inkscape::Filters::FilterPrimitive::filter_primitive_area(const
Inkscape::Filters::FilterUnits&)':
src/2geom/generic-interval.h:65:9: warning: 'y' may be used
uninitialized in this function [-Wuninitialized]
src/display/nr-filter-primitive.cpp:146:12: note: 'y' was declared here
src/2geom/generic-interval.h:65:9: warning: 'x' may be used
uninitialized in this function [-Wuninitialized]
src/display/nr-filter-primitive.cpp:145:12: note: 'x' was declared here
(GCC 4.6.1 (tdm-1) on Windows)
The warning seems bogus to me, the value is certainly correctly
initialized, and I've added code to check that everything that is
assigned to it is also initialized. What fixes the warning is changing
the first lines of that function
Geom::OptRect const fa_opt = units.get_filter_area();
if (!bb_opt || !fa_opt) {
return Geom::Rect (Geom::Point(0.,0.), Geom::Point(0.,0.));
}
Geom::Rect const &bb = *bb_opt;
Geom::Rect const &fa = *fa_opt;
to
Geom::OptRect const fa_opt = units.get_filter_area();
if (!bb_opt || !fa_opt) {
return Geom::Rect (Geom::Point(0.,0.), Geom::Point(0.,0.));
}
Geom::Rect const &bb = *bb_opt;
Geom::Rect const &fa = *units.get_filter_area();
No joke...
So, in conclusion: it will be impossible to compile with -Werror for now
:'(, due to spurious compiler warnings that can't be avoided without
hurting the code. (another one is templated functions with a signed
comparison logic, that are then instantiated with unsigned template
arguments...)
Disappointing :-(
Johan
(PS. thanks for the help in fixing this)
10 years, 1 month
Windows: btool update
by Johan Engelen
Hi all,
I just modified buildtool to output less uninteresting stuff, and
output warnings instead, so it is easier to spot and fix warnings for
your code. So next time you bzr up: "g++ -O3 buildtool.cpp -o btool.exe
-fopenmp".
Hope you like it.
Cheers,
Johan
10 years, 1 month
