Inkscape SVG Animation Interface
by Jiaxiang
This is just a quick mock-up of an idea for an
Inkscape SVG animation interface.
DISCLAIMER: I'm merely an Inkscape user. I don't know
anything about programming or GUI design - and I also
don't pretend to know.
This is just submitted to give some general idea of
what, from the perspective of a this user, may or may
not be the bare basics to add such a neat and powerful
tool into the Inkscape tool box.
Note: This would ideally be an additional window
within Inkscape.
The genius of its construction/destruction is left to
you in the wonderful world of Inkscape development.
With a handshake...
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
18 years
"icon preview" comments
by bulia byak
1. It shows only the last selected object, not the entire selection.
So to preview a whole icon made of several objects, i have to group
them and select the view. Very inconvenient.
2. There must be some way to set the background color of the dialog.
The perception of an icon changes a lot with different backgrounds,
and it would be nice to be able to preview different backgrounds in
the dialog, without changing the document.
3. Please provide at least the size labels for the buttons.
4. Please make it auto updating on selection changes and
modifications, without having to press Update.
18 years
Postscript Gradient Export
by Michael Forbes
Hello Inkscape Developer!
I attached a patch for Inkscape to allow it to export both linear and radial
gradients subject to all transformations I could think of. I had some problems
with GhostView rendering some radial gradients when the focus of the gradient is
outside the actual object it fills. But I think it is a bug in GhostScript and
not my understanding of PostScript. The only thing I am unsure is whether it is
a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript
gradients are a Level 3 feature (perhaps some programs can't handle postscript
level 3.
first time Inkscape hacker,
-Michael Forbes
------------------------------------------------------------
Student System Operator binx.mbhs.edu
BEN Manager http://ben.mbhs.edu
BNC Internet Division http://bnc.mbhs.edu
MBHS Webmaster http://www.mbhs.edu
BlazerNet President http://blazernet.mbhs.edu
Computer Team Co-President http://computerteam.mbhs.edu
MBLUG President http://mblug.mbhs.edu
------------------------------------------------------------
18 years
Re: Snap to objects?
by bulia byak
On Fri, 18 Mar 2005 07:51:49 -0500, Lou Quillio <public@...758...> wrote:
> 1. Grid/guide display and snap distance settings are document-level
> prefs, which is expected. Snap toggling is also a document pref.
> That's unusual. It takes five clicks to toggle snapping and
> return to work.
It would not be logical to have these settings separate. Besides the #
and | keys toggle BOTH snapping and visibility.
> 2. Initial snap distance is so fine (0.4000px) that the snapping
> action is imperceptible, which gives the impression it's not
> working.
That's indeed a problem, and I've been planning to fix it by making
the snap distance specifiable in screen pixels, i.e. the same in
_visible_ length but different _absolute_ length depending on zoom. I
think it would make much more sense.
However this would only be possible to do in combination with snapping
only to the visible grid lines (some of them become invisible as you
zoom out), as I proposed here long ago. I still think it's the best
approach, though some people objected (frankly I don't remember their
arguments, though I remember not being convinced by them :) and so I
shelved this idea. What's the current opinion of people?
18 years
reminder for bug reporters
by bulia byak
Hi all,
when reporting bugs in the tracker, please ALWAYS:
- indicate the Inkscape version
- indicate the platform
- ATTACH THE FILE. Even if you think the file is "nothing special"
and the bug is obvious. A file's worth a thousand words. It's often
difficult to understand the bug explanations; attaching a file helps a
lot. More often than not, reported bugs are already fixed in CVS; if
you attach your file, a developer can quickly test it and close the
report. WIthout the file and with unclear report text, a developer has
to waste his time asking questions in the bug (which are not always
answered, btw, especially in anonymous reports).
So please do us (developers) a favor and always attach the file with
your problem. It's much better to attach an unneeded file than to fail
to attach a needed one. There are other things you might do to help
(such as a backtrace), but a test file is absolutely essential.
If Sourceforge won't let you attach a file (happens sometimes), post
it on the web somewhere and attach a link in comments to the bug.
Thanks!
18 years
Re: [Inkscape-devel] Re: [cairo] Pango + cairo
by Owen Taylor
[ Adding gtk-i18n-list to the CC, as more on-topic ]
[ ... Various comments about SVG text requirements snipped ... ]
On Thu, 2005-03-17 at 13:32 +1100, Peter Moulder wrote:
> > I believe that there is a place for a library supporting advanced text
> > applications, but that Pango Layout is not it. The overhead is really
> > quite large and seems unnecessary for an API whose primary goal is
> > laying out text in widgets.
>
> Owen, can you comment on what you see as pango's scope? Are you
> interested in non-rectangular text regions? Are you interested in
> non-greedy line breaking? (I'd guess that non-greedy line breaking
> would be desirable even for dialog boxes, at least from a functional
> point of view; the only question is whether it justifies the cost in
> terms of maintainability of pango code and perhaps code size.)
Pango's goal is to support anything anybody wants to do with text.
The scope is implicit in the fact that text is hard, and
internationalized text is harder. If you start from scratch and don't
use Pango, you either have to say "full international coverage is never
going to be interesting to me", or you have a year or two of work to
do to catch up to Pango.
So, the question isn't to me "what is Pango's scope" but rather what
parts of Pango should be universal, and what parts do you replace.
In particular, what about PangoLayout? It's really only a small part
of Pango's code - maybe 10-15% of the total 65,000 lines of code,
so maybe it's just ignorable? If you want non-rectangular line breaking,
just use the low level parts of Pango
My opinion is that while there may be some cases where ignoring
PangoLayout and starting from scratch is right ... we really want
PangoLayout to be extensible to handle almost any case where we
are taking a block of text and laying it out into lines. Because
of the 8000 lines of code inside PangoLayout, the part that actually
lays out the text is only a small fraction ... 1000-2000 lines of
code. The rest is bookkeeping, rendering, iteration over the layout
and so forth.
There's a big patch from Damon Chaplin outstanding to redo the
line layout part of Pango to add justification. I haven't had the
time to fully review it yet. It's pretty darn complex. If it turns
out that we can't just replace the current code wholesale, that patch
may be a good point to look at making line-layout pluggable.
Non-greedy linebreaking is very challenging to do with good
internationalized shaping. (I think Damon spent some time trying
to figure out and then gave up.) But if someone had a spare month,
I think it's definitely possible. And I wouldn't mind shipping
it with Pango, as long as it was optional. As well as performance
considerations, it is just the wrong behavior for most interactive
applications.
Non-rectangular layout, on the other hand, is pretty easy. It's
not totally trivial when you have mixed fonts within a line and
thus uneven line spacing, but I think the main challenge there is
simply coming up with a good interface for representing the shape
to Pango.
Regards,
Owe
18 years
Re: select arrowheads?
by bulia byak
On Thu, 17 Mar 2005 09:59:15 -0800 (PST), John Cliff
<simarilius@...36...> wrote:
> What I'd hoped to do was make the default markers styleless, then to
> xlink:href them from defs with a style applied (ala gradients and the
> vectors), as they should be able to inherit then (or can they? that was
> how i read it anyhow)
> Problem is we dont support xlinked markers atm. and I didnt know where
> to start adding support for it.
Markers cannot href each other. So you'll have to simply duplicate a
marker when applying style to its user path (only if the hrefcount of
the marker is > 1, otherwise it's not needed). However the copied
marker should carry some extrension attr indicating that it's a styled
copy of another marker, for purposes of showing in the list only the
markers which differ by contents, not style.
> btw, other complication is that some markers are solid filled paths,
> while others are just stroked, so you have to work out where to apply
> the style. What you do if the marker refs a gradient I dont know :)
I think it's possible to redraw all the basic markers (arrows,
squares, etc) so that they look the same but only use stroke, no fill.
This will simplify things a lot, as you'll just copy the new path
style to marker and that will paint it the needed color. More
elaborate markers will use fill too, in which case their fill color
will be determined by that of the user path. Note that per SVG spec,
unset stroke is invisible (unlike unset fill which is black), so in
the original markers you will need to provide stroke:black on
<marker>, and replace it with whatever is the user path's new style.
18 years
Re:
by ����
Привет.
Я твой адрес потерял, тут покопался - вроде твой.
Можешь посмотреть, хохотал полчаса http://www.fanka.ru/fp/funpic/03/prikfotk008.jpg
Помнишь я рассказывал что купил себе сотовый в 3 раза дешевле.
Вот их адресок www.cardstaff.biz Если тебя не пугает что без руссификации и без гарантии, то можешь заказать.
Собираюсь в апреле в отпуск, ты когда?
Ты не теряйся - пиши.
18 years
Re: [Inkscape-devel] Inkscape website with WordPress
by Jonathan Leighton
John Taber wrote:
>My two cents - if the CMS or any other scripting thing does not really buy you
>a must have or great to have that you can't do otherwise without a lot of
>pain, then it's not worth it down the road. Warren Buffett swears by KISS so
>I tend to think it is a good thing to strive for. If the CMS does buy a lot,
>and if it's well done, then do it.
>
Yes, exactly. But there are different interpretations of this rule. I'd
say that having an RSS feed is a fairly essential feature. I'd also say
that maintaining a news section is a fairly essential feature. Now, the
code for that needs to come from somewhere, and either someone on the
Inkscape project has to write it, or we have to use publishing software
from someone else. I think that by letting the WordPress developers deal
with publishing and WordPress, it allows the Inkscape developers to get
on with the task at hand: Inkscape.
This is a simplistic view ('scuse the repetition), I know, and there are
issues to consider, which Bryce explained extremely well, but when it
comes down to it, I say let the publishing people deal with the
publishing, and the Inkscape people deal with the Inkscaping.
Just as an example: the only time you'd have to write (X)HTML with
WordPress is when you want "advanced" things like blockquotes, lists,
etc. All the paragraphing, validating (to an extent) and entity encoding
is done for you, so you don't have to worry about it. The Inkscape
website currently fails on validation due to non-validating news
entries. Dates are also added automatically, so there's no chance of
forgetting that.
>I'll format my blogs simply using css (although even css doesn't work very well in IE for
>customers stuck with that so maybe I'll just keep my blogs in simple html).
>
>
I know quite a few people who would shoot you for saying that, although
I'd rather they shot Microsoft ; ).
Jon
--
Jonathan Leighton aka. Turnip
http://turnipspatch.com/ | http://digital-proof.org/
18 years
