new scaling/stretching behaviour with Preserved Transforms
by alvinpenner
This is an attempt to summarize the types of scaling behaviour that can
occur, and to highlight a few remaining unresolved issues. Only the
behaviour of the visual bbox will be discussed. In Inkscape 0.48.4 there
were two types of stretching behaviour, depending on the choice of the
preference for Scale Stroke Width. The choice of the preference for
Optimized/Preserved Transforms did not affect the visual appearance in
Inkscape, although it did in other renderers. With the implementation of the
new Cairo renderer both of these preferences now affect the visual
appearance, as they should. So there are now 4 possible results.
The attached file 4boxes.svg has four identical boxes in a horizontal
row. After stretching vertically with the Select tool (F1) we get file
4boxes_12851.svg. The four types of stretch used here were, from left to
right: scale/optimized, no scale/optimized, scale/preserved, no
scale/preserved. The first three cases scale more or less as expected, the
fourth case is a bit unexpected. Since the idea of a constant (apparent)
stroke width is meaningless in the case of a preserved transform, what has
happened here is that the geometric mean of the apparent horizontal stroke
and the apparent vertical stroke has been kept constant during the stretch,
which is why the stroke along the horizontal axis is so narrow.
Upon looking closer, case 3, scaled/preserved, has a few minor
inconsistencies: it is too narrow and there is a vertical offset. These have
been addressed in rev 12852. The result is shown in the file
4boxes_12852.svg.
There are two remaining issues which may be more difficult to solve. In
case 4, no scale/preserved, there is a remaining vertical offset. The offset
is actually more serious than it appears to be, because it is persistent, it
does not go away even after performing a round trip by contracting the shape
again. It appears to be related to the fact that the stretching was
asymmetric. If you drag at a 45 degree angle, then there is no offset. This
will be reported elsewhere as a bug. The second unresolved issue is that the
appearance during the drag is not the same as the appearance after releasing
the object (Bug 1258271).
Hoping to raise the visibility of this behaviour because this has
provoked some discussion in the past, Bug 805392, Bug 805793; and since I
have no idea how to fix the remaining issues.
4boxes.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes.svg>
4boxes_12851.svg
<http://inkscape.13.x6.nabble.com/file/n4969050/4boxes_12851.svg>
4boxes_12852.svg
<http://inkscape.13.x6.nabble.com/file/n4969050/4boxes_12852.svg>
Cheers,
Alvin
--
View this message in context: http://inkscape.13.x6.nabble.com/new-scaling-stretching-behaviour-with-Pr...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9 years, 9 months
possible bug?
by TimeWaster
i have the attached document:
<svg
[...]
width="602.36218"
height="336.04724"
[...]
viewBox="0 0 170 94.840002">
<sodipodi:namedview
[...]
inkscape:document-units="mm"
[...]
>
in inkscape "custom size" is set to px, "default units" is set to mm.
width and heigth are the size of the document in pixel, all other
numbers are in mm. (they all have no unit specified, but i know it
because of the dimensions of the drawing)
shouldn't the width and height parameter be width="602.36218px" instead
of width="602.36218" since the document wide unit is mm (even the
viewBox is in mm)?
i am using r12832 right now.
i think this is related to
https://bugs.launchpad.net/inkscape/+bug/605089 but it says it is fixed
there, which i cannot confirm.
and even if you say that width should always be in px, having no
explicit unit given makes it harder (more obfuscated) for people to
understand and parse the documents.
regards,
TimeWaster
--
Save a printer manufacturer. Print this e-mail unless it's really
necessary not to do so.
9 years, 9 months
Re: [Inkscape-devel] Dealing with OS reported bugs
by Bryce Harrington
On Tue, Dec 17, 2013 at 08:30:28AM +0000, Nicolas Dufour wrote:
> On Sun, Dec 15, 2013 at 07:42:49PM +0100, Kris De Gussem wrote:
> >> I was wondering how to deal with bug reports automatically submitted by the
> >> operating system. It is often hard to verify for these bugs how exactly one
> >> could to provoke the issue but on the other hand it may be clear from the
> >> backtrace that some null pointer check (or related thing) is missing).
>
> It's particularly difficult to deal with the Ubuntu automatic reports,
> mainly because they often don't include steps to reproduce. We can try
> to fix it thanks to the backtrace, but we have no certainty that it is
> actually fixed without the steps. So what should we do? Close as soon
> as we have committed a fix or wait until someone finds a way to
> reproduce and confirm the fix works.
I don't think there can be a hard and fast rule here; it's kind of a
judgment call.
For X.org bugs in Ubuntu, where there was a crash we didn't know how to
repro but the stacktrace pointed out the flaw (a null pointer deref or
whatever), I'd commit the patch and mark the bug fixed. We would only
need the steps to repro and confirmation of the fix if we needed to
backport the fix to a stable release.
When the stacktrace didn't point out the flaw definitively, then we
would indeed need to get steps to repro. If we had an idea for a patch,
I'd post it to the bug report (and put a test package with the patch
into a PPA), and wait on committing it to mainline until a user
confirmed it. We usually only did this for crashes and lockups that
were being hit by a lot of users, so even if one person was
unresponsive, we could wait until another person filed a new bug, or
commented on the original one. In a lot of cases the crash or hang
wasn't deterministic but tended to occur periodically over N hours, so
if they ran the package and used it for > 2*N hours we called it good.
It's worth noting that the automatic collecting tool avoids creating new
bug reports if it finds one with the same stack trace that still has an
open distro task. So, being a little aggressive at closing these bugs
when you suspect they're fixed is okay - the system will file a new one
if it's still crashing for someone.
My guess for Inkscape is that the former case is going to be more
applicable. Perhaps suv has better advice on Inkscape policy here?
Of course, if the codebase is frozen for a release, there'll be stricter
rules, since we do want to make sure a committed fix really does fix the
issue, but there'll be policy guidance given when we're at that point.
By the way, the automatically generated bug reports can be controlled on
the ubuntu side. We can arrange to collect some additional logs from
the system at the time of the crash. (Very useful for X.org bug
reports; maybe less so for Inkscape.)
Also, there is a site at errors.ubuntu.com where ALL reported crashes
appear, even if the user doesn't file a bug report. This site counts
how many of each crash were reported for each Ubuntu release, and links
to the bug report if there is one. You have to register to gain access
to the detailed data (let me know if you're applying and I'll put in a
good word with the ubuntu folks.)
So right now, for package 0.48.4-1ubuntu3, the top crashers hit by users
this past month are:
Bug 1047748 (71 crashes) sp_dtw_color_profile_event
Bug 1216167 (14 crashes) pathv_to_linear_and_cubic_beziers
(8 crashes) sp_guideline_destroy
(8 crashes) sp_ctrlpoint_set_color
The interface also allows creating bug reports for crashes that don't
yet have one. I created 1261918 as an example. Looks like there's a
bunch of crashes that don't have bug reports yet.
The detail crash report page shows a full stack trace, and a table
showing other instances of the crash, what package version and ubuntu
version were in use, and the date and time the crash occurred. You can
also look at other examples of the stack trace, which can sometimes be
handy to compare data or examine race conditions.
For X.org I found this tool very helpful for prioritizing what crashers
to work on, and identifying where backports of a fix to earlier stable
releases would bring good bang for the buck.
HTH,
Bryce
9 years, 9 months
Powerstroke questions
by Tom Lechner
Hi,
I really love the powerstroke path effect, but some questions.
1. How accessible is the stroke information? From the file, it appears
it is stored as a series of points, and stroke properties are
derived from proximity to the original path.
Perhaps there is an option to output more explicit information so that
anything building on top of powerstroke can use it?
If there is no possibility of outputing a kind of cache of powerstroke
info, are there easy to use functions in the actual code to get this
kind of information?
I have been working on a mesh along path interface (not quite directly
in inkscape yet), which could be adapted to apply gradients
perpendicular to paths, make paths change color in the path direction,
or perhaps be a base for inserting series of etching lines that conforms
to a base path.
Having access to powerstroke width profiles would be a great asset for
these kinds of extensions.
2. Does the powerstroke computer apply the width always centered on the
path? If the top and bottom were allowed to operate independently, it
would be a single interface for both line offsetting (with only one
powerstroke point) and for powerstroking itself.
Thinking ahead to animation, tweaks like this could be useful there.
-Tom
------
tomlechner.com
9 years, 9 months
Re: [Inkscape-devel] lib2geom development, make test fail?
by Andreas Lobinger
Hello colleagues,
1)
it's correct, the wiki points to a subversion repository
https://lib2geom.svn.sourceforge.net/svnroot/lib2geom/lib2geom/trunk
which i checked out as version r2059, the svn log | head tells me:
lobi1@...3065...:~/lib2geom/trunk$ svn log | head
------------------------------------------------------------------------
r2059 | tweenk | 2010-07-21 22:18:35 +0200 (Mi, 21 Jul 2010) | 2 lines
(and last check-in more than 3 years ago doesn't look like recent
development...).
This version runs cmake with everything found except:
-- blas Includes, Compile and Link Flags: NOT FOUND
-- pycairo Includes, Compile and Link Flags: NOT FOUND
generates a makefile, make breaks with:
lobi1@...3065...:~/lib2geom/trunk$ make
[ 1%] Building CXX object src/2geom/CMakeFiles/2geom.dir/affine.cpp.o
In file included from /home/lobi1/lib2geom/trunk/src/2geom/affine.cpp:15:0:
/home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:40: error: ‘size_t’ was not
declared in this scope
/home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:40: note: suggested
alternatives:
/usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:155:26: note:
‘std::size_t’
/usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:155:26: note:
‘std::size_t’
/home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:46: error: template
argument 1 is invalid
/home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:46: error: template
argument 2 is invalid
/home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:53: error: ‘size_t’ has not
been declared
make[2]: *** [src/2geom/CMakeFiles/2geom.dir/affine.cpp.o] Error 1
make[1]: *** [src/2geom/CMakeFiles/2geom.dir/all] Error 2
make: *** [all] Error 2
which looks strangely as C++ header trouble.
2)
I followed the link in
http://inkscape.org/en/develop/getting-started/#bazaar
and in section Inkscape development tells me:The geometry library lib2geom,
written in C++, is intended to eventually become a separate project. You
can get the latest version of lib2geom from its Launchpad
repository<https://launchpad.net/lib2geom>
.
So i bzr from the launchpad repository,
bzr log | head tells me:
lobi1@...3065...:~/lib2geom/lib2geom$ bzr log | head
------------------------------------------------------------
revno: 2161
committer: Johan B. C. Engelen <j.b.c.engelen@...3066...>
branch nick: lib2geom
timestamp: Mon 2013-12-09 22:00:17 +0100
message:
use proper std:: namespace for std::size_t, because of cstddef include.
fixes build for some ppl
------------------------------------------------------------
which i considered a lot more recent.
The cmake claims the same missing as above, make however runs through and
produces both the library and the toy programs.
make test fails as:
...
60% tests passed, 6 tests failed out of 15
Total Test time (real) = 1.00 sec
The following tests FAILED:
2 - bezier-test (Failed)
3 - chain-test (Failed)
4 - path-test (Failed)
6 - sbasis-test (Failed)
8 - convex-test (Failed)
11 - cg-test (Failed)
Errors while running CTest
make: *** [test] Error 8
3)
My system is a std 12.04 Ubuntu on
lobi1@...3065...:~/lib2geom/lib2geom$ uname -a
Linux mark 3.2.0-56-generic-pae #86-Ubuntu SMP Wed Oct 23 17:51:27 UTC 2013
i686 i686 i386 GNU/Linux
?
Wishing a happy day,
Andreas
9 years, 9 months
Fwd: possible bug?
by TimeWaster
*push*
if noone answers till tomorrow i will open a bug report for it.
regards,
TimeWaster
-------- Original Message --------
Subject: [Inkscape-devel] possible bug?
Date: 15.12.2013 16:15
From: TimeWaster <sebi@...2963...>
To: Inkscape Devel Mailingliste <inkscape-devel(a)lists.sourceforge.net>
Reply-To:
i have the attached document:
<svg
[...]
width="602.36218"
height="336.04724"
[...]
viewBox="0 0 170 94.840002">
<sodipodi:namedview
[...]
inkscape:document-units="mm"
[...]
>
in inkscape "custom size" is set to px, "default units" is set to mm.
width and heigth are the size of the document in pixel, all other
numbers are in mm. (they all have no unit specified, but i know it
because of the dimensions of the drawing)
shouldn't the width and height parameter be width="602.36218px" instead
of width="602.36218" since the document wide unit is mm (even the
viewBox is in mm)?
i am using r12832 right now.
i think this is related to
https://bugs.launchpad.net/inkscape/+bug/605089 but it says it is fixed
there, which i cannot confirm.
and even if you say that width should always be in px, having no
explicit unit given makes it harder (more obfuscated) for people to
understand and parse the documents.
regards,
TimeWaster
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
9 years, 9 months
lib2geom development, make test fail?
by Andreas Lobinger
Hello, i wanted to use lib2geom in an own project and have difficulties to
compile and run correctly; so my co from bzr_lp can cmake, make, but make
test fails (for 6 tests, starting with bezier). This is also visible in the
toys.
Can someone point me please, how to connect to the development and how and
where to ask questions. It also would be nice, to clarify the dependencies
(BLAS is not found, but it's not clear, what this means).
Wishing a happy day,
Andreas
9 years, 9 months
Fwd: Re: [scribus-dev] C++11
by Johan Engelen
Hi all,
I asked the Scribus guys what their plans are regarding C++11. They
had not thought about it much, but I got a very interesting reply, that
is relevant for us too. Please read below.
regards,
Johan
-------- Original Message --------
From: - Thu Nov 07 23:35:19 2013
Date: Thu, 07 Nov 2013 02:21:04 +0100
From: Jean Ghali <jghali@...373...>
To: Scribus Development Mailing List <scribus-dev@...3050...>,
jbc.engelen@...2592...
Subject: Re: [scribus-dev] C++11
Hi,
For making the switch to C++11, all C++ dependencies have to be compiled using C++11 too.
It is indeed dangerous to link C++11 objects and C++ objects compiled according to
previous standards:
- http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
- http://stackoverflow.com/questions/9408656/do-we-need-to-recompile-librar...
- http://stackoverflow.com/questions/10065055/why-is-stdlist-bigger-on-c11
So basically the main requirements for us to switch to C++11 would be that qt binaries
provided by distros are compiled according to C++11. I don't known if this is the case
currently but i doubt it.
Cheers,
Jean Ghali
Le 06/11/2013 20:05, Johan Engelen a écrit :
> Hi all,
> I'm rooting for requiring C++11 for lib2geom ASAP. How badly would this hurt Scribus
> development? ;)
> Are there any plans about when to make the switch to C++11 for Scribus?
>
> (I'm not subscribed to the list, so please also send replies directly to my address)
>
> Cheers,
> Johan
> (Inkscape and 2geom developer)
9 years, 9 months
Recognizing a circle from a 1 + 3N Bezier description?
by mathog
SVG has a radial gradient type but neither EMF nor EMF+ do. Instead
EMF+ has a gradient
type that can be generalized to a radial: set color1 at an interior
point and color2 on a closed path around it, and the intermediate
points' colors are determined by the position along the ray from the
center to the bounding curve. When PowerPoint saves a radial gradient
via "save picture as" to an EMF file it also creates an EMF+
description. In the cases tested those paths looks like this:
1213769.875000,856342.937500 <
1213769.875000,1358353.125000
806810.187500,1765312.875000
304800.000000,1765312.875000 <
-197210.218750,1765312.875000
-604169.937500,1358353.125000
-604169.937500,856342.937500 <
-604169.937500,354332.718750
-197210.218750,-52627.000000
304800.000000,-52627.000000 <
806810.187500,-52627.000000
1213769.875000,354332.718750
1213769.875000,856342.937500 <
The first point has type "start" and all the others have type "Bezier.
The "<" indicates the
points that are actually on the circle, and the points are grouped to
emphasize how they work. These correspond to this drawing, with the
point at 9:00 repeated once:
http://www.mathworks.com/matlabcentral/fx_files/6844/2/CircleApproxbyCubi...
If the goal is to import this gradient from the EMF+ this bezier must be
recognized
as a circle. That might also be worthwhile for other circles encoded as
a similar path.
Now if the circles were only ever encoded with 13 points in this manner
it would be pretty
easy to spot one and convert it to a circle. But there might be 25
points in another circle
representation, or something else. Does anyone know of a relatively
straightforward test to apply to a curve like this (1 + 3N Bezier
points) to see if it is a circle (within an error limit)?
For the gradients we also have the location of the center point, but
that won't be true for general curves.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 9 months
better targets for task/note-annotations on website
by Jared Meidal
I really like how the new website is functioning and it seems a slick way to bring in users and developers both into engaging with Inkscape!
I've seen a number of text notes appearing on page content which seem to be reminders for tasks or content-to-come. I'm really glad for the diversity of contributors on the site, but as notes/tasks/needs are published on the site (rather than actual useful content itself) I'd like to see an alternative destination established before these notes sit out there too long on our live site.
For example, http://inkscape.org/en/download/windows/ contains the line at the top "[[website TODO : pretty buttons showing main download link, + maybe screenshots of the installer.]]" This is a useful reminder to the website author-community, but not text that should reside on the live site.
Would a better action be to move these annotations into the launchpad templates/bugs area, or can the web CMS handle notes in the backend for the developers only?
Thanks,
--Jared
9 years, 9 months
