Bug status for Inkscape 0.42 release
by Bryce Harrington
There's still a few more days before we officially kick off the bug
fixing phase of the 0.42 release, however I'm going to start posting bug
stats.
For the 0.40 release we set a target of 150 points worth of bugs, but
hit 360 points by the time we stopped counting. Pretty damn cool. :-)
For this release, I'd like to up the challenge by setting our target to
300 points. We did it before without breaking much of a sweat, and we
have over 200 bugs open currently, so I think this will challenge us to
really beef up Inkscape's quality for this coming release.
Once we've achieved the 300 point total, we'll doublecheck the list of
critical bugs and identify ones that must be fixed. Hopefully we can
close enough of these early that this will be a very short list.
Bryce
Bug ID Pts Title
------------------------------------------------------------------------
None yet!
========================================================================
Total: 0 Goal: 300pts
17 years, 8 months
Do we really need g77?
by Wolfram Quester
Hi,
every time I run configure I wonder if we really need g77. Should this
check be removed?
checking for powerpc-linux-gnu-g77... powerpc-linux-gnu-g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether powerpc-linux-gnu-g77 accepts -g... yes
checking the maximum length of command line arguments... 32768
BTW, a debian package of 0.42pre0 will be uploaded soon.
With best wishes,
Wolfi
17 years, 8 months
object-edit.cpp:842: error: `isfinite' undeclared in namespace `std'
by Jeremy C. Reed
Building inkscape-0.41 on NetBSD 1.6.2_STABLE with GCC 3.3.3.
I receive this error:
if c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/pkg/include/freetype2
-I/usr/pkg/include -I/usr/pkg/include -I/usr/X11R6/include
-I/usr/X11R6/include/freetype2
-DPOTRACE=\"potrace\"
-I/usr/pkg/include/gtk-2.0
-I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include -I/usr/X11R6/include
-I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/pango-1.0
-I/usr/X11R6/include/freetype2 -I/usr/pkg/include/glib/glib-2.0
-I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/libxml2
-I/usr/pkg/include/sigc++-2.0 -I/usr/pkg/lib/sigc++-2.0/include
-I/usr/pkg/include/gtkmm-2.4 -I/usr/pkg/lib/gtkmm-2.4/include
-I/usr/pkg/include/glibmm-2.4 -I/usr/pkg/lib/glibmm-2.4/include
-I/usr/pkg/include/gdkmm-2.4 -I/usr/pkg/lib/gdkmm-2.4/include
-I/usr/pkg/include/pangomm-1.4 -I/usr/pkg/include/atkmm-1.6
-I/usr/pkg/include/gtkspell-2.0 -I/usr/pkg/include -I/usr/include
-I/usr/pkg/include/freetype2 -Wall -W -Wpointer-arith -Wcast-align
-Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O2 -s
-I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -MT
object-edit.o -MD -MP -MF ".deps/object-edit.Tpo" -c -o object-edit.o
object-edit.cpp; \
then mv -f ".deps/object-edit.Tpo" ".deps/object-edit.Po"; else rm -f
".deps/object-edit.Tpo"; exit 1; fi
object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const
NR::Point&, const NR::Point&, unsigned int)':
object-edit.cpp:842: error: `isfinite' undeclared in namespace `std'
gmake[2]: *** [object-edit.o] Error 1
Any ideas?
(Please carbon-copy me on replies.)
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
17 years, 8 months
current cvs - problems compiling win32
by Adib Taraben
Hello,
I checked out a fresh copy from the cvs. This does not compile with
mingw because a used define is commented out in the makefile. See below.
I also compiled a win32 installer for the 0.42pre0. This is 18meg, where
should I put this? My webspace on geocities is only 10meg.
Ciao,
Adib.
---
cvs diff -u3 -- Makefile.mingw.common (in directory D:\projekte\inkscape\)
Index: Makefile.mingw.common
===================================================================
RCS file: /cvsroot/inkscape/inkscape/Makefile.mingw.common,v
retrieving revision 1.52
diff -u -3 -r1.52 Makefile.mingw.common
--- Makefile.mingw.common 29 Jun 2005 07:07:29 -0000 1.52
+++ Makefile.mingw.common 30 Jun 2005 16:31:54 -0000
@@ -111,7 +111,7 @@
MSGFMT = $(GTKDOS)$(S)bin$(S)msgfmt
####### change me!!
-DTG := 20050626
+DTG := 20050630
endif
##########################################################################
@@ -120,10 +120,10 @@
###### VERSION NUMBER
-VERSION_NR = 0.41+devel
+VERSION_NR = 0.42pre0
# VERSION_NR = 0.42+cvs
-# VERSION = \"$(VERSION_NR)-${DTG}\"
+VERSION = \"$(VERSION_NR)-${DTG}\"
####### the XP_WIN def is necessary for libjs.a
CFLAGS = -O3 -Wall -mms-bitfields -DVERSION=$(VERSION) \
***** CVS exited normally with code 1 *****
17 years, 8 months
terminology proposal
by Jakub Steiner
Hi folks,
Until yesterday I haven't had a chance to play with what you call
effects. Because I believe this is a misleading terminology I want to
propose an alternative:
Scripts
-------
Scripts are little programs, written in interpreted language, that
supply extended Inkscape functionality. They can work on objects, or
even drav new objects on the canvas.
Both Blender and GIMP projects eventually came to a conclusion that it
makes no sense to separate scripts form the core functionality in terms
of interface. A script should be free to register anywhere in the menus,
based on its functionality. Grouping them, creating yet another menu
structure, just because they are written in a particular language is not
helpful to the user.
Yes, it is pretty much what you call effects now.
Filters
-------
Filters are operations on selected objects, on their bitmap renderings
even. The result of the filter replaces the original object and cannot
be easily changed in future. The resulting image is stored in the file
upon save.
Effects
-------
Effects are similar to filters, yet they are "dynamically" applied on a
bitmap copy of the object at the target resolution. Only effect settings
are stored in the file on save, and the effect needs to be recalculated
(possibly some caching/preview voodoo needs to be applied to speed up
preview).
cheers
--
Jakub Steiner <jimmac@...659...>
Novell, Inc.
17 years, 8 months
guide lines: desktop vs document coordinate system
by Peter Moulder
Someone has bug #1222819: “guides have different orgin than objects”:
horizontal guideline positions are currently stored as distance up from
the bottom of the document (i.e. desktop coordinate system), whereas
shape positions’ y coordinates are represented as distance from the top
of the document.
The result is that if you snap a shape’s position to a horizontal
guideline and then resize the document (File>Document preferences,
Custom page size, then change the page height), then the shape and the
guideline will no longer appear to be at the same position.
In my local copy I've mostly fixed this so that the guideline's position
from the top of the document is preserved (as for shapes) rather than
from the bottom.
However, this does raise a user interface issue of how to report to the
user what the guide line's position is:
/*
* For dialog boxes and status bar, should we report positions in the
* document coordinate system or in the desktop coordinate system?
*
* The argument for reporting document coordinate system is that this is
* the one that we honour when the document is resized, so in some sense
* it is the true (or at least robust) position of the guide. OTOH,
* resizing a document is rare.
*
* The argument for reporting desktop coordinate system is that this is
* what's used by the rulers and "current position" indication. This is
* the coordinate system that we usually report to users, so is less
* confusing to users.
*
* ...
*
* (Hopefully, future versions of inkscape will get rid of the separate
* desktop coordinate system, to remove this problem.)
*/
Comments?
pjrm.
--
bbyak: swatches, rich text, gradient on canvas...
JonCruz: The answer to the ultimate question of life, the universe, and everything...
JonCruz: Inkscape 0.42!!!!!!!
17 years, 8 months
Fwd: [cairo] redesigning the arguments for svg2png
by unknown＠example.com
Just FYI in case you had anything to add..
----- Forwarded message from Jason Dorje Short <jdorje@...859...>
-----
Date: Wed, 29 Jun 2005 21:37:27 -0400
From: Jason Dorje Short <jdorje@...859...>
Reply-To: Jason Dorje Short <jdorje@...859...>
Subject: [cairo] redesigning the arguments for svg2png
To: "Cairo Mail List (E-mail)" <cairo@...278...>
Current arguments for svg2png:
-w $WIDTH
-h $HEIGHT
-s $SCALE
-x, --flipx
-y, --flipy
input.svg and output.png are taken directly as parameters
This is all explained in `man svg2png`. The problem is it's
incomplete.
----------
For instance if you give -w and -h svg2png makes an image with the
given
$WIDTH and $HEIGHT and puts the SVG file inside it with preserved
aspect
ratio. Thus there is no distortion and there is padding.
One thing I need to do is to change the aspect ratio. I want to
give a
width and height and have the SVG "stretch" to take up this whole
area.
Thus the xscale and yscale are different. Thus there is distortion
and
there's no padding. This is what rsvg, sodipodi, and inkscape
command-line renderers do.
A third thing one would want to do is preserve the aspect ratio but
without any padding. Thus the $WIDTH and $HEIGHT provide the max
dimensions, just like svg2png does now, but without any padding.
Thus
there is no distortion and there is no padding. IIRC this is what
the
librsvg rsvg_pixbuf_from_file_at_max_size function does (which I've
found very useful in the past).
Yet another thing you might want to do is specify the xscale and
yscale
independently. I can't recall ever needing to do this, but rsvg
allows it.
Finally, one might wish to specify things in DPI. If the SVG image
is
given in real-world dimensions (e.g., inches) giving a DPI to render
at
will allow you to make the PNG image show up at the right size when
rendered at that DPI (to a monitor or a printer). Aspect ratio is
preserved; this is just a (possibly) convenient way of setting the
--scale. Inkscape provides a -d $DPI parameter allowing this. Note
that this will not work with all SVG files.
----------
Of course svg2png should be able to do all of the above tasks. It
would
also be nice to keep command-line compatibility with rsvg, inkscape,
sodipodi. The trick is to do all this without having confusingly
many
options or giving unexpected default behavior.
Thus I suggest:
--width=$WIDTH (-w)
--height=$HEIGHT (-h)
--xscale=$X_SCALE (-x)
--yscale=$Y_SCALE (-y)
--flipx (-X maybe?)
--flipy (-Y maybe?)
--scale=$SCALE (-s)
--dpi=$DPI (-d)
--pad [1]
--stretch
You may pad or stretch or neither but not both. The default should
be
to do neither (same as rsvg, inkscape, and sodipodi), this changes
the
current behavior which is to pad. (--pad and --stretch were
suggested
by Carl.)
Supporting -d will require new functions to libsvg and libsvg-cairo
to
set the DPI.
-x and -y are changed from flipx and flipy to xscale and yscale.
This
matches the rsvg args (they call it --x-zoom, --y-zoom).
In case of conflicting options (--width and --xscale both given) the
one
higher up in the list is given priority (this is obviously arbitrary
and
can be tweaked a bit). Care should be taken to give a sensible
output
no matter what combination of args are given (rsvg is pretty bad at
this).
----------
For full compatibility with inkscape and rsvg it would be necessary
to
add more "long argument" aliases. This would be convenient but
would
also add clutter to the interface.
Inkscape also has some additional parameters that might be useful,
either for new features or compatibility. See -a, -f, -e, -i, -j,
-t,
-b, -y from `man inkscape`. I don't understand all of these but
some of
them are probably desirable.
In a related note xsvg should probably support a similar set of
options.
Seems there could be a lot of overlap here.
-jason
_______________________________________________
cairo mailing list
cairo@...278...
http://lists.freedesktop.org/mailman/listinfo/cairo
----- End forwarded message -----
17 years, 8 months
GString or standard C++ library strings?
by David Yip
To mitigate overflow issues with fixed-size buffers in the Inkboard code for
message transmission, I'm going to convert the Inkboard messaging code to use
strings. However, I'm not really sure what string implementation would be
preferred by the Inkscape team. As a lot of Inkboard and Inkscape code use
glib facilities, the GString has that advantage, but since we're using C++...
I don't see this explicitly touched on in the Developer's Manual or the
InkscapeJanitor wiki pages, so I'm guessing it hasn't been brought up before,
but if it's listed somewhere, I apologize for the duplicate message.
-- David
17 years, 8 months
