Smooth transitions in Bézier paths
by Diederik van Lierop
Hi,
I hope you don't mind if I increase the traffic on inkscape-devel even
more ;-)
At some point an idea popped up to only snap to nodes at discontinuities
in paths, and not to nodes at smooth transitions from one Bézier segment
to another. This is more intuitive (less "Hey, what it is Inkscape
snapping to now?") and might increase performance.
Problem is that in the object-snapper I only have access to SPCurve,
which is a wrapper for "old-style" NArtBpath. It's easy to find out
whether a point is inbetween two Bézier segments, but how do I find out
if a transition is smooth? I guess that should be done by comparing the
control points, or is there an easier way? With the transition to
lib2geom, will the NArtBpath be deprecated in favor of the Path class?
(that would make this rather exercise useless in the long run).
Any pointers would be appreciated here,
Diederik
14 years, 10 months
question regarding wishblade robocraft support...
by stuart
Sorry for posting here if the user list if better. And sorry about the
subject if it has been talked about before. I couldn't get sourceforge
to add me to the inkscape user mail list and sourceforge was timing out
on all my archive searches with no results.
---
I remember reading that there was a patch or something to inkscape to
support wishblade and robocraft users. Has that been integrated into
the inkscape application? Is that what the DXF is all about?
Wishblade users can not use DXF directly (needing the robocraft software
to import DXF and change it to some sort of native (and maybe
proprietary) GSD). Is there a way to get inkscape to save images in GSD
in order to simplify the process?
Ideally, I would prefer to skip bringing up the wishblade application.
In my set up, I do all my work in linux (GIMP/INKSCAPE) and only the
plotting in Windows. If I could do everything in linux it would
simplify the flow of work greatly. Has anyone figured out how the
craftrobo is communicated to in order to use it with common open source
linux plotting software?
Better yet, has anyone figured out how the wishblade has been crippled
in order to use it with common open source linux plotting software?
...thanks
15 years
sorting out PS/EPS/PDF export mess
by bulia byak
It's always bad when the UI offers two ways to do the same thing
without really explaining what's the difference. It's equally bad when
UI uses some meaningless techno jargon such as "cairo" :)
Unfortunately 0.46 was released still in the middle of a transition
period which made both these evils inevitable. Now that we're in 0.47,
however, I would like to address this issue by switching all of PS,
EPS, and PDF output to cairo, removing the builtin Inkscape exporter,
and purging the mentions of "cairo" from the UI.
As a matter of fact, this has already partially happened (not sure who
did this). Right now both PS export options work via cairo and produce
identical output. The Inkscape-native PDF export is nowhere to be
seen. The only exporter which still uses native code is EPS. However,
since 1.5.2 cairo can produce EPS files too, so this can all be done
in one place now (closng several EPS export bugs along the way). The
only downside is that it will require cairo >= 1.5.2, is everyone OK
with that?
By the way, the latest cairo 1.5.12 finally fixes the bug where
zooming in too closely in Outline mode produced messy broken lines.
Now everything is neat and clean. Upgrade is recommended.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
15 years
inkscape git mirror?
by MenTaLguY
I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this.
-mental
15 years, 3 months
Fwd: Programming for Inkscape.
by bulia byak
...forwarding this to the devel list...
---------- Forwarded message ----------
From: Pam B. <pamely@...329...>
Date: Thu, Feb 14, 2008 at 2:26 PM
Subject: Programming for Inkscape.
To: buliabyak@...400...
Hi,
I have been told to contact you by Bibi Morris. I understand that in the
past some wonderful people have made changes in Inkscape that made it an
incredibly useful program for owners of Wishblade and CraftRobo personal
media cutters.
I have now been provided a tip that would allow users of Linux to drive
their machines directly from Inkscape. The "tip" suggested that Windows
users might be able to do the same if someone was able to do something
with the windows binary for Inkscape. As is probably already obvious, I
know nothing about Operating Systems, nor do I know anything about
coding and software programming.
Actually, I no longer even own a Wishblade, (I have moved on to a bigger
machine.) but I do run a support group for over 1,000 personal cutter
owners. This has the potential of being a very powerful tool to owners
of these types of cutters and could save them hundreds of dollars in
software upgrades. Would you please check into this and see if it is
something that can be done for us?
Thank you,
Pam Beard and the 1,000+ in the yahoo group: EasyWishbladers
The "tip" is pasted below:
If the words Linux, RedHat, Debian, Inkscape and / or Python mean
anything to you read on (warning, getting technical here...).
How would you like to cut from inkscape? all in Linux?
I have been lurking in Linux Printer Driver land and was very happy
to find an early copy of a Python script designed to provide the
necessary "linkage" between Inkscape and a craftrobo cutter. With a
little change to the code, we verified it works with a wishblade as
well. But you might have to wait until there is support in the down
loadable python script.
Basically, you print from Inkscape "using PostScript operators" (not
as a bitmap). And, instead of sending the output to a printer, you
"pipe" it to the python application. This operation is actually
described in the Inkscape print popup menu. When you click on print,
the python GUI pops up giving you more options. This GUI interface
is *much* simpler than the actual graphtec software. Most anything
to do with the image needs to be done in Inkscape. The only real
control on the GUI are the paper size, the cutting speed and the
cutting pressure.
I suppose this can also be done in windows. My *assumptions* are
that there is a windows binary for inkscape as well as python and
python related software. If that's the case, then you may be able to
skip setting up a Linux box.
I know I am hitting only about 1% of you, but if you want to try the
script you can get it here: http://vidar.gimp.org/graphtecprint/
....I am sure feed back at this stage of development would influence
what features are fixed, enhanced and / or added.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
15 years, 3 months
Animation (was: Re: Inkscape / GSoC '08 proposal)
by Christophe Dehais
Hi Martin and everyone!
On Tue, Feb 26, 2008 at 9:56 AM, Martin Owens <doctormo@...400...> wrote:
>
> If anyone is looking for a small simple project that would make great
> impact they should think about working with me on the simple animation
> plan; although I've not had a lot of time to work on it other than
> reading inkscape codebase, I do believe the plan to be a solid
> starting point.
>
I might actually be interested in this. I don't know what you have in
mind precisely about "the simple animation plan", but here are the
main possible goals I see:
* implement the svg animation elements : animate, set,
animate{Motion|Color|Transform}
* figure out a decent UI for editing animations:
- a time-based (SMIL oriented) timeline editor to represent / move
around keytimes (=keyframes except it's not frame-based but
time-based)
- an interpolation curves editor
* design some animation-related on-canvas items, like:
- trajectories (motion-paths)
- temporarily overlayed (t-epsilon) / (t+epsilon) state of an
object (to mimic onion skinning)
Is that close to what you thought about ?
There are a lot of open questions, like:
- should there be an "animation mode" where the animated attributes
values are edited, as opposed to a "normal mode" where it's the object
attributes that are modified ?
- SMIL semantic is quite rich: at first some things might be discarded
like repetition or the possibility to define the start of an animation
based of some events (e.g. user click or the end of another
animation). Those things don't map well in a timeline UI which I guess
is the way animators are used to think.
- will the canvas scale well to preview large animations sufficiently smoothly ?
Comments welcomed !
regards,
Christophe
15 years, 4 months
GSoC tag-team for lib2geom integration
by unknown＠example.com
Hi all,
Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08. We spoke about working together on it. He knows 2geom very well, I know Inkscape well and have worked with 2geom a lot for LPE. Because complete conversion to 2geom is a big task, where 2geom issues can become apparant, I think it is nice to have a 2geom developer working on it aswell (although I did commit some small things to 2geom, I do not count myself as a real 2geom developer). This way, we can both work and discuss things where we are uncertain. I hope to have a somewhat longer discussion with mgsloan within the next couple of days.
How do people feel about this?
Apart from having a 2-man team on lib2geom integration: I know I have been very brief in my gsoc proposal as blueprint. I am thinking about
1. writing test code (cxxtest)
2. integrating lib2geom in steps, for example per tool or per feature
3. switching to 2geom path representation in inkscape core is advanced task and should be tried later in the project
4. I'd rather *not* work in a branch, because then people that code new things will use 2geom instead of me/us having to recode new things to 2geom. (conflicts etc abound)
5. Release lib2geom after integration is complete. Not before integration is complete because of things that might be missing or bugged in 2geom.
Thanks for your opinion,
Johan
15 years, 4 months
Multipage plan
by bulia byak
This topic has been discussed a lot... but now I need this feature for
a project, so I decided to look in detail into what we can do to
enable multiple pages in Inkscape.
There is an SVG Print specification from W3C which deals, among other
things, with multipage SVGs:
http://www.w3.org/TR/SVGPrint/
However, it is still a draft. I don't know when it will become a final
spec. We have already been bitten once by jumping the gun and
implementing a thing which was later dropped from the standard and
replaced by a quite different one (flowtext). Besides, even when it is
final, it may take years for SVG software to catch up to it. And I'm
sure a lot of software will choose to ignore SVG Print because
printing is simply not on their agenda.
All of this makes me very reluctant to go on with implementing the
current SVG Print multipage model. If we do, we may end up with our
multipage documents unreadable by most SVG software out there, even
though we will follow an official spec.
Yet, let's look and what SVG Print proposes. A multipage document
looks like this:
<svg>
<!-- some content displayed as a background master page -->
<pageSet>
<masterPage rendering-order="under"/> <!-- optional -->
<masterPage rendering-order="over"/> <!-- optional -->
<page> content </page>
<page> content </page>
...
</pageSet>
</svg>
In a lot of respects, page and pageSet containers are similar to
groups or layers. Hence my proposal:
- Implement the same document structure, but instead of pageSet,
masterPage and page, use regular g elements with extension attributes
indicating their role.
- Reuse the Layers dialog for displaying and switching these page
containers as well, making them part of the overall layers tree
displayed in that dialog. In this way, each page may have its own
subtree of layers, but there may be shared layers that show up on all
pages, stored in master pages or in the content before the pageSet
(which is also treated as a background master page). Of course the
Layers dialog will have to treat such page-layers in a special way,
namely:
-- display them differently (font, color, autonumbering)
-- enforce that only one of the sibling pages is visible at a time: as
soon as the user switches to a page and makes it visible (perhaps for
pages, we can implement "clicking on name makes visible"), all other
pages are hidden, using the standard CSS visibility property as is
done for layers
-- when a page gets visible, its nearest preceding masterpage also
gets visible, all previous masterpages get hidden (as per the SVG
Print spec)
- In addition to Layers dialog, we'll also need a small page flipper
in the statusbar, next to the quick layer selector, hidden for
non-multipage documents; the quick layer selector should perhaps be
limited to the layers of the current page and the currently active
masterpage only.
- Add commands like New page, Duplicate page, Delete page, etc.
I think this plan has several important advantages:
1) it gives the required functionality without too much disrupting the
existing workflow; in particular it makes obvious the relationship
between layers and pages, which otherwise may be confusing;
2) it is relatively easy to implement with the existing infrastructure;
3) it lets any SVG 1.1 software to view Inkscape multipage files, if
only the page which was last viewed in Inkscape before saving;
4) it maps _almost_[1] one-to-one to SVG Print and will be easy to
switch to using the dedicated SVG Print elements at any time.
Please let me know what you think.
[1] Why "almost"? There's one small detail in SVG Print which cannot
be emulated in SVG 1.1: a masterPage with rendering-order="over"
(foreground master page) must be rendered on top of the current page,
but it comes _before_ it in document order. I find this very
unfortunate and I actually think it might be a good idea to suggest
changing this before the spec is finalized. Namely, replace
The Background Master Page and Foreground Master Page MUST be the ones
most closely preceding the page in document order.
by
The Background Master Page MUST be the one most closely preceding the
page in document order; the Foreground Master Page MUST be the one
most closely following the page in document order.
With that change, a 100% emulation of this with SVG 1.1 groups will be
possible (unless I'm missing something, of course). Unfortunately,
this change will likely be rejected because, from what I see, one of
the motivations in SVG Print is to make a document "streaming" so that
a page can be fully rendered without looking forward in the document.
If that is the case, then I guess we'll just need to drop support for
foreground master pages in our implementation.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
15 years, 5 months
Re: [Inkscape-devel] Inkscape Font Sizes
by Guillermo Espertino
Quick and dirty workaround: multiply the desired size by 1.25
For instance: 10 pt type = 12.5 px
The explaination of this is that svg uses a resolution of 90 dpi for its
pixel size as default. Postscript type units are 72 dpi.
90/72=1.25
Anyway, as I expressed before, inkscape is being used by designers who
work for print as well as for screen. Typographic point size of 1/72"
is sort of "industry standard" for print, and most of the applications
using type for that output use that unit.
So Inkscape needs, at least, a unit selector in the type dialog asap.
Gez.
15 years, 5 months
SVG Fonts
by Felipe Sanches
I will apply for SoC on SVG Fonts implementation. My task will be basic SVG
Fonts support (i.e. reading of xml attributes, proper rendering and
editing). I imagine that there are some extra stuff that could be done but
would not necesarily be part of my task on SoC. I could work on those after
completing the basic SVG Fonts support.
I am starting this thread to discuss SVG Fonts related wished features. I
will choose among these, which ones I think make sense to add to my SoC
application and which I consider extra work to be done after SoC.
one idea (probably to be implemented after SoC):
Since SVG Fonts actually work as an alternative kind of font file (a font
can be saved as .svg and then used by other SVG drawings) inkscape could
have a font editing UI. It could have import scripts to load TrueType fonts
and export them as SVG Fonts and vice-versa. I could also do it for other
font types. One issue is in the exporters because obviously not everything
SVG is capable of doing is supported by TrueType, or other font formats. So,
we would commonly have to deal with glyph degradation when exporting fonts.
Felipe Sanches ("JucaBlues" on irc)
15 years, 5 months
