Loss of precision for grids in millimeters
by Pajarico
Hi,
I've a case of quirkiness:
I set a grid in mm and the X spacing is set to 0.3761mm.
On the canvas, there is a visible difference between 0.3761 and 0.376
but when i close and reopen the file the value is cut to 0.376mm.
I thought there was some conversion of mm->px and that the stored
value was in px, but opening the SVG in a text editor reveals
the value stored is 0.376 and the unit is mm.
So i wonder why it is possible to store a value in px with 4-decimal
precision but not so in mm. For some reason is not possible to store
4 decimals for millimeters...
I can set values with 4 decimals in px or " just right --i've another
grid set to 0.0625in (1/16 of an inch) without problem.
Is there a conversion somewhere -which I'm unaware of- cutting the
last decimal? Should I resort to doing the conversion from
mm to px to achieve more precision?
Best regards.
14 years, 8 months
Possible fix for color chooser bug, #257685
by Bob Jamison
I don't know if anyone has worked on #257685 yet. I gave it a quick look
and maybe the fix is very simple.
Apparently with Gtk2.13 and greater, Gtk is enforcing the page size and
steps,
which seems to be the root of the problem where the sliders can only max
out to
245 rather than 255. If [0..255] were a document, 245 would be the
bottom of the last page,
so the adjustment widget is operating correctly.
According to the Gtk notes, setting page sizes and steps to 0 for simple
adjusters
might be the best way to fix this.
In src/widgets/sp-color-slider.cpp, line 332, this little modification
seems to fix the problem:
if (!adjustment) {
adjustment = (GtkAdjustment *) gtk_adjustment_new (0.0, 0.0,
1.0, 0.01, 0.0, 0.0);
}
//in case of existing adjustment
gtk_adjustment_set_page_increment(adjustment, 0.0);
gtk_adjustment_set_page_size(adjustment, 0.0);
Maybe someone with knowledge of the older SP-vintage widgets can decide
if this is a valid fix or is merely fixing the symptom? I'd rather not
commit with insufficient knowledge of how this thing works.
bob (ishmal)
14 years, 8 months
FW: active_desktop removals
by unknown＠example.com
Hi all,
Max found something that is important to know.
Apparently, gcc accepts "false" as a value for a pointer. So it is
possible to write:
test_function(Test *t)
...
test_function(false);
without triggering a compiler warning/error.
This hid a problem after refactoring a function method, resulting in a
crash.
See the mail below for more details.
Cheers,
Johan
-----Original Message-----
From: Maximilian Albert [mailto:Anhalter42@...173...]
Sent: maandag 8 september 2008 15:13
To: Engelen, J.B.C. (Johan)
Subject: Re: active_desktop removals
J.B.C.Engelen@...1578... schrieb:
> We should check this, this is really bad compiler behaviour!
I just wrote a simple test program (attached below). It works fine as
is, but when I replace the line
test_function(t);
with
test_function(false)
there is a runtime crash. However, even when compiling with -Wall there
is no warning whatsoever. Interestingly, when I replace false with true
in the function call, the code doesn't compile any more. But I'd think
that false is just as well recognized as a boolean value as true is.
Hmm, I think I will report this upstream on the gcc mailing list.
Max
===================================
#include <iostream>
using namespace std;
class Test {
public:
Test() {}
void print() { cout << "Hello, world!" << endl; } };
void
test_function(Test *t) {
t->print();
}
int main() {
Test *t = new Test();
test_function(t); // replace t with false to trigger a runtime crash
delete t;
}
14 years, 8 months
Inkscape Releases
by Josh Andler
Hey All!
Since I was a release warden for 0.46 and will be the one moving forward
for 0.47 as well I'd like to touch base.
First, it seems like patches intended for 0.46.1 have died down
submission-wise. I plan on beginning to get caught up on Launchpad with
regard to those in an effort to move things forward with it. Does anyone
have any requests or things to comment on with this?
Second, is it wrong to assume that we won't be shooting for 0.47 this
year? I'm definitely not pushing for it. I'd rather see everything get
nicely polished... besides I almost never use release versions except
for bug testing. ;)
Cheers,
Josh
14 years, 8 months
New devlibs stuff
by Bob Jamison
People using the win32 devlibs will probably want to svn up, to get the new Gtk libs. I believe that this is the version that was needed for the printing fix.
I started a new build on the server to see if we get lucky and the autobuild works ok. It compiled and runs fine on my laptop here.
bob
14 years, 8 months
win32/Inkscape19808-0809060128.7z crashes when importing jpg or gif images
by worms invasion
Hello,
The latest win32 build from modevia:
http://inkscape.modevia.com/win32/Inkscape19808-0809060128.7z
crashes when you try to import either a jpg or a gif file. A png is imported fine.
OS: Windows 2000 SP4
Steps to reproduce:
- Launch Inkscape (create a new empty document)
- Select Import from the menu
- The standard Windows dialog opens
- Click on a jpg or gif file name
Result:
Message. Runtime error, Inkscape encountered an error and will now close (or something)
Crash.
If you already have an open document opened with stuff in it, the import dialog doesn't make Inkscape crash, but it does nothing.
14 years, 8 months
Max value for colors < 255
by Oliver Etchebarne Bejarano
Hi,
I have GTK+ 2.13.6, and had problems compiling Inkscape 0.46, until I
found this patch http://launchpadlibrarian.net/15113774/gtk-clist.patch.
Inkscape compiled pretty well, but now the color values are gone wild
:-P I can't raise any of the color components more than 245. Even the
default colors (in the color bar) are semi transparents (the alpha
channel is at 245).
I can write the HTML color "FF0000FF", and then the drawing turns solid
red. But in the "fill and border" pannel, the values are at 245 (for red
and alpha). If I try to change one of those values, they return to
theier "correct" values (254), the image turns transparent again, and
the HTML color shows "F50000F5".
Here is a screenshot: http://drmad.org/inkscape-245-problem.png
I've work with Inkscape 0.46 with a older GTK version without any
problem. Help :(
--
Oliver Etchebarne Bejarano
drmad/paperclip
http://www.paperclip.com.pe/
14 years, 9 months
Re: [Inkscape-devel] "Live Pen" Feature
by Tony Vigil
Microsoft Expression uses a profile shape method that is just like what Bulia suggested. The width equals the path length and the nodes along the profile shape equal the distance away from the centerline for the brush object's width.
The LPE could be given three pieces of information... bottom most item is the stroke path, then brush object and then the profile path. If no profile path is selected, then the brush object is drawn along the stroke path without any change in brush width.
----- Original Message ----
Message: 2
Date: Wed, 03 Sep 2008 20:15:14 +0200
From: Maximilian Albert <Anhalter42@...173...>
Subject: Re: [Inkscape-devel] "Live Pen" Feature Bounty
To: bulia byak <buliabyak@...400...>
Cc: inkscape-devel(a)lists.sourceforge.net, J.B.C.Engelen@...1578...
Message-ID: <48BED432.6080504@...173...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
bulia byak schrieb:
> I think we will need to store widths not per node, but as a list of
> length along path/width pairs, with length measured in percentages
> of the total length of subpath
That's an excellent idea. Since I had something like Pajarico's other
suggestion in mind (see different email), I was thinking about how to
store per-node information. But separating the width info from nodes and
storing it in the described way will make the LPE very powerful and
flexible.
>> And finally, for the actual profile shape I think we should use a
>> Spiro path for extra smoothness and natural flow. However, if we want
>> to eventually support sharp width changes, we will need to store for
>> each point its type - whether it is a smooth Spiro point or a cusp
>> point.
> I'm not sure if I understand you correctly here (in particular: what do
> you mean by "profile shape"?), but why not apply the LPE to any path
> whatsoever? The 2geom routines are flexible enough to make this
> possible. If you want it to be on top of a spiro path, just use LPE
> stacking.
> Max
14 years, 9 months
