I have the latest debian package, but dunno what that is... can't you
put something in the about dialog, so that I know... I never remember
this terminal stuff.
Anyways, I get a crash when I try to copy a text with a gradient fill.
That is strange on the one hand and annoying on the other. I hope it's
an easy to fix or fixed already.
just wondering if I should file a bug, or if it's so simple that I don't
Especially in the guides and the positioning dialog it would be helpful
to be able to put mathimatical stuff in there. Imagine you have a guide
at 45.6 and want one 7 mm further to the right, you'd just type 45.6+7
and there you go... even more important is something like dividing by 2
or 3, I need that quite often.
Btw: Since my laptop was for repair, I used CorelDraw, and I think for
basic vector editing and layouting inkscape is by now better than Corel.
That is something!
Which also brings me to one other thing I'm missing: Baseline Grid. Even
for simple flyers and brochures it's nice (or rather necessary) to have.
CorelDraw just pissed me of for not having it!
I got my laptop back, with working ethernet card, Yeah!! Take care!
Can anyone please compile the latest CVS for Windows so the latest additions could be tested there? I have Windows but no Windows development tools.
Sign-up for your own personalized E-mail at Mail.comhttp://www.mail.com/?sr=signup
Search Smarter - get the new eXact Search Bar for free!
Now that the files have been checked
into the tree, it has become very easy
to build on Win32. I have put a couple
of recent builds here:
...along with instructions on how to do it.
Please try them out. The main thing I am looking
for, is a missing DLL dependency or something
like that. Even though I have tried these on
other machines, I would still appreciate a 3rd
party testing it.
Maybe a warning dialog or a status bar update would be positive to
notify the user if a comment is orphaned in someway. I know though this
would require some intelligent coding.
On Wed, 2003-12-31 at 15:17, MenTaLguY wrote:
> I guess one thing to think about is how to deal with Sodipodi's
> "advertising" comments if comment preservation were added.
> Obviously we wouldn't want to add an advertisment comment to the
> document if one already existed, or they'd start piling up every time
> one was saved.
Jonathan Phillips <jon@...15...>
>I didn't think about the gen-nrconfig change very closely when it was
>first made, but in retrospect, since NRShort is a general-purpose type
>with a precision implied by its name, changing its precision is probably
>a bug in itself.
>The correct fix is to replace uses of NRShort that require more
>precision with a type that provides it -- e.g. NRLong, or better gint32.
Why "better"? What if one day, we need 64 bit precision - do a global search
and replace again? The NR* stuff was there exactly for this: a layer of
abstraction that allows to change the actual precision quickly - and it was
not "a bug" because the typedefs are there for exactly this purpose (and
they were not "general purpose" becaue the NR prefix limited their scope
pretty narrowly to the NR subsystem). Frankly I don't understand why it was
necessary to kill it and replace with hard-coded 32-bit types (I can
understand getting rid of nr-config.c, but not this). Anyway, it's not my
domain, so please fix it one way or the other, so long as it's fixed :)
The new MSN 8: smart spam protection and 2 months FREE*
Now there are two pairs of inset/outset commands: one creates the SPOffset
object and the other simply offsets a path, leaving it as a path. Which pair
is linked to the menu commands can currently be changed by
commenting/uncommenting within sp_selected_path_offset() and
sp_selected_path_inset() in splivarot.cpp.
I propose the following UI:
- "Inset path" and "Outset path" commands act depending on the type of the
selected object(s). For SPOffset objects, they increment/decrement radius by
options.insetdistance (to be added to the preferences, no more relying on
stroke width please!). For all other objects, they do one-time offset
leaving objects as paths (or converting them to paths if necessary) also by
options.insetdistance. If there are several objects selected, each one is
treated according to its type.
- The third command, "Dynamic inset/outset", creates an SPOffset with zero
radius. It also flashes to the statusbar, "Use node editor to inset/outset
the path interactively."
If there are no objections, Fred, could you please implement these three
commands and I will put them into the menu and in shortcuts. See this page
on how to create/access a preferences value:
- The splotches bug is fixed, but now interactive offsetting has become much
slower. With a text string, I need to wait at least a second after dragging
the control before it regenerates the path. Is this inevitable, or can it be
- The quality of offset in SPOffset object is very good, however the
sp_selected_path_do_offset() function creates ugly artefacts (e.g. try it on
a text string) even when applied _only once_. Why the difference?
- Please use statusbar API to report errors, instead of g_warning:
Whenever a command cannot perform its action, it must provide a reason for
it in the statusbar. Also please don't forget to enclose all text strings
shown to the user into _("...") so they can be translated.
Protect your PC - get McAfee.com VirusScan Online
I've tried the new offset object - really impressive! For those who haven't
tried it yet, you can now interactively adjust the inset/outset value by
dragging a control point (similar to e.g. rounding a rect) and it will be
redrawn in real time. You can also vary the radius attribute of the object
in XML editor to achieve the same result. The quality and precision of the
outline is very good (at least compared to the previous attempts to do
A few comments:
- The new attributes that you add must be in the inkscape: namespace, not
- The inset/outset commads still require that a path has a stroke. Please
change them so that they decrement/increment the radius attribute, by say 1
pt with each command, regardless of stroke (converting a path into offset if
necesary). Ideally we'll need to have two pairs of commands, say one
incrementing radius by 1 pt and the other (with alt) by the distance
corresponding to 1 visible pixel at the current zoom (similar to
- The statusline description of the object can be more useful if instead of
simply "Offset" it would say e.g. "Path inset by 1.5pt" or "Path outset by
- Even though the path quality is now very good, I still noticed occasional
"splotches" that would be nice to fix. I'm now uploading one example to the
bug tracker so you can see what I'm talking about.
MSN 8 with e-mail virus protection service: 2 months FREE*