Tablet stopped work in Dev builds
by microUgly
I just downloaded the Oct 24 Windows build and found that my tablet isn't
working properly with it.
I can move the cursor with tablet pen, but when I press on the tablet
nothing draws. I tried toggling the "Use pressure" button.
My tablet still works fine in 0.46 and was working in an earlier build I was
using last night (I don't think it was more than a week or two old). Let me
know if you require a bug logged for this.
--
View this message in context: http://www.nabble.com/Tablet-stopped-work-in-Dev-builds-tp20171213p201712...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
14 years, 5 months
LPE dropdown box (was : NEW: LPE Interpolate)
by Steren
>> The LPE choose dropdown box is getting really huge now. Who wants to
>> make mockups of what is a better system for applying effects?
>
> What about just a hierarchical menu with submenus, similar to the Effects menu?
I think this is an issue that needs more to be discussed before coding
anything (search for filters ?)
Here is a first draft for LPE submenus, please comment and modify :
=Artistic= // Everything that changes the path style (on a visual
point of view)
Freehand Shape
Interpolate Sub-Paths
Pattern Along Path
Sketch
Stitch Sub-Paths
=Create= // create a very different path
Gears
Spiro spline
? VonKoch
=Path Tweak= //small modifications
Knot
=Distort= // change the path shape
Bend
Envelope Deformation
Lattice Deformation
Perspective path
=Technical= // tools for tech and serious drawings
Angle bisector
Boolops
Circle (center+radius)
Circle through 3 points
Construct grid
Mirror symmetry
Offset
Parallel
Perpendicular bisector
Ruler
Rotate copies
Tangent to curve
14 years, 8 months
using inkscape -> plotters in windows...
by stuart
Hi...
First, how do you people do this? Window drivers are a nightmare! For
instance, where do they start and where do applications end? People are
talking about HPGL, SVG ... I just when round and round w/the Graphtec
drivers for their C200-20 and C100-20 plotters. I am convinced they not
only control the plotters but also translate depending on the
application. That is, I have been told, that printing from Word using
the graphics found in the Word's WordArt feature can actually cut on a
Graphtec Craftrobo. How would this be possible unless the driver were
also translating the output of the Word application.
Guess I'm really asking, in windows, using inkscape, is the accepted
"go-between" format between application and drivers PostScript? So, if
anyone dares to write a windows driver, they can at least count on that
much?
Also, I understand that the "pipe the output feature" of inkscape was
recently broken (during a revamping). Is that true? Has it been fixed?
...thanks
14 years, 8 months
NEW: Converting text to path produces a group
by bulia byak
Converting a text or flowed text to path (Ctrl+Shift+C) now produces a
group of paths, one path for each glyph of text, instead of a single
monolithic path as before. Apart from easier manipulation, an
additional advantage is that if your text contained styled spans (i.e.
fragments with different color, opacity, or other properties), these
styles will be preserved by the corresponding glyph paths after
converting to paths.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
14 years, 9 months
Gradients disappearing
by Jasper van de Gronde
Running the rendering tests again this week I encountered a regression
in the rendering of filters-comptran-01-b (from W3C SVG test suite).
This test contains four rectangles with the same gradient, one without
any filter and three with three different component transfer filters.
Last week the four rectangles in the filters-comptran-01 test were still
rendered with the wrong colours, but they were rendered. This week two
of them are not rendered anymore... As far as I can tell the component
transfer code wasn't touched during that time though, so I have
absolutely no idea why this suddenly happens.
Now the question is, should a bug be reported? And if so, what is this
the actual bug? As far as I can tell feComponentTransfer isn't supposed
to work anyway, so filing a bug seems a bit pointless at this point.
However, as it doesn't appear to be related to a change to the component
transfer filter it might actually be an unrelated bug in disguise.
So, any ideas on what could be causing this?
14 years, 9 months
CharTypes.h et al
by Michal Svoboda
Hello,
for the second day I'm trying to compile inkscape and growing more and
more desperate. Compilation fails with:
In file included from extension/internal/pdfinput/svg-builder.cpp:19:
extension/internal/pdfinput/svg-builder.h:32:23: error: CharTypes.h: No such file or directory
In file included from extension/internal/pdfinput/svg-builder.cpp:20:
extension/internal/pdfinput/pdf-parser.h:29:24: error: goo/gtypes.h: No such file or directory
extension/internal/pdfinput/pdf-parser.h:30:20: error: Object.h: No such file or directory
(and ~3 more pages of induced errors).
I've tried to google and stuff, but to no avail. What do I need to have
installed to get those header files? (I've seen that they come with
xpdf, but that's not quite it - and they don't get installed to
/usr/include anyway.) So either some horrible hack is required on my
part or these include files come with something very basic that is
auto-assumed, and nobody bothers to check for it in ./configure. Can
someone shed some light into this?
Thanks,
Michal
14 years, 9 months
intltool
by Diederik van Lierop
Hey people,
Just a quick note: to run ./autogen.sh succesfully with latest revision,
I had to update intltool to v0.40.5. This was the error I got before
updating:
Running intltoolize --copy --force --automake ...
cp: cannot create regular file `po/Makefile.in.in': No such file or
directory
intltoolize: cannot copy '/usr/share/intltool/Makefile.in.in' to
'po/Makefile.in.in'
Please fix the error conditions and try again.
Fedora 9 is still only at v0.37.1, so I had to manually copy some files
from the Fedora 10 preview release.
Diederik
14 years, 9 months
New snapping features
by Diederik van Lierop
Hi all,
In the latest revisions you will notice that Inkscape now has a snapping
tab in the preferences dialog. It contains some non-document specific
settings, such as for example the snap indicator toggle. There are some
new parameters too though:
1) You can now specify the snapping delay (as promised a few weeks ago)
2) I've added a slider which controls which type of snapping Inkscape
will prefer. When multiple snap solutions are found, then Inkscape can
either prefer the closest transformation (when the weight-slider is set
to 0; this is the old mode), or prefer the node that was initially the
closest to the pointer (when the slider is set to 1). The way Inkscape
calculates the preferred snap has been improved too, which should lead
to more predictable snapping
3) There's a toggle to force Inkscape to only try snapping the (source)
node that is closest to the mouse pointer, à la Coreldraw. When this
mode is enabled a snap indicator will shortly be shown at that node.
This will give you maximum control of the snapping which is useful for
more complex drawings with many nodes.
Have a try and let me know what you think of it....
Diederik
14 years, 9 months
Bug in SVN with certain HID devices
by Omar Chanouha
Hello Everyone,
I did an SVN yesterday and after compiling I got this error:
ERROR:preferences.cpp:488:Inkscape::XML::Node*
Inkscape::Preferences::_getNode(const Glib::ustring&, bool): assertion
failed: (pref_key.find('.') == Glib::ustring::npos)
After further investigation, I realized that the pref_key my program was
crashing on was that of my keyboard/mouse:
Liteon Microsoft Wireless Reciever 700 v2*.*0
When I removed the assert from the code the program started properly. I
believe the assert is checking to make sure that the first instance of a
period is coming at the end of the pref_key, or that one does not exist?
Either way, why are you checking for this? Why does it matter?
Regards,
Omar
14 years, 9 months
handling of bugfixes for particular cases
by Thomas Holder
Hi,
I just fixed bug #190424 and #168777. These are about incorrect font
size when creating text in a document, that has a viewBox attribute. My
patch does not fix the lack of viewBox handling in general, but only for
text tool. Actually Inkscape needs a proper generic implementation of
viewBox handling I think, but this is probably a larger piece of work.
I'd like to know how our policy is for such cases. Go for the easy fix
now, and revert it once the proper general fix is done? Or postpone the
whole issue until it is properly fixed?
Thomas
14 years, 9 months
