Hi, I'm attaching an updated spanish po.
Is the "feature freeze" is also a "string freeze"?
If no new strings are added, I would like to do a full revision of the
correctness of the strings in their context. For this I must agree with
bulia in insisting on the creation of static builds.
I'm having continuous failures trying to compile gtkmm on my system,
which I can't afford to have unstable.
Cheers,
--
Lucas Vieites Fariña
Dept. Desarrollo <lucas@...212...>
Asix Informática <http://www.asixinformatica.com/>
Tel/Fax: +34 986 54 26 98
Greeetings
I attempted to invoke the example in S17.1 of the SVG 1.1 specification in inkscape. This deals with "Linking out" of SVG content.The relevent part of this is
<a xlink:href="http://www.w3.org">
<ellipse cx="2.5" cy="1.5" rx="2" ry="1"
fill="red" />
</a>
When invoking the example in InternetExplorer, the affect of clicking on the ellipse is to bring up W3's web page.
I have not found a way of achieving this in inkscape.
The relevent parts of the spec are
1. "SVG 1.0 only requires that user agents support XLink's notion of simple links."
2. "By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may visit these resources."
3. "If the above SVG file is viewed by a user agent that supports both SVG and HTML, then clicking on the ellipse will cause the current window or frame to be replaced by the W3C home page."
WRT 1, does inkscape meet this requirement
WRT 2, MouseClicking events in inkscape are trapped for the puposes of the selector tool (I dont know how to turn of all tools). How can I activate the link
WRT 3, My purposes are not the rendering of HTML but rather the invocation of a program. Does inkscape support this and how.
Regards
Endre
IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.
Hi,
I extracted the last win32 snapshoot on my win2000 box.
My problem I cann not read the caption on the layer-combo-box on the statusbar. The Font is to small or hiroglyphic ??
attached screenshot.
HTH,
Adib.
It's time to start making the final push towards getting the release out
the door. Here's the plan:
Feature Freeze Phase:
* Starts at End of the Day, Sunday, 11/21
* All feature development work ceases
* Last pass through bug tracker for show stopper bugs
* Last chance to submit tutorials and translations
Hard Freeze Day:
* All codebase activity stops for one day
* Conduct final QA testing
* Unless a show stopper is found, establish Release Branch
* If show stoppers are found by end of day, go back to Feature Freeze
Release Branch:
* Verify AUTHORS, version number, release notes, etc.
* Only intended for last minute cleanup
* Remember to merge bug fixes back to main branch too
* Announce Inkscape-0.40 final tarball to packagers
* Create packages and post to SourceForge
Release PR:
* Update Freshmeat page
* Post announcement of release to news sites, blogs, etc.
http://inkscape.org/cgi-bin/wiki.pl?AnnouncingReleases
* Notify distro vendors of new release availability
How's that sound?
Bryce
On Wed, 2004-11-17 at 13:15, Carl Worth wrote:
> > For a simple renderer, something like the SPObject/SPRepr split is likely
> > to be severe overkill.
>
> A simple renderer, we have already in libsvg-cairo.
>
> Beyond that, people are interested in a standalone, cairo-based SVG
> viewer with support for dynamic HTML. Libsvg-cairo is not up to that
> task. What I don't know is if it makes sense to start trying to build it
> up, or if we should instead extract the SVG guts from something else,
> (such as sodipodi).
Some of it is going to have to be built independently.
Sodipodi has a lot of deep architectural issues that need fixing; I
don't think you would find it a good choice.
Inkscape, in turn, inherited the same deficiencies and we're far from
getting them all fixed yet. It also uses C++ and has some additional
dependencies that might be undesirable for a more general library.
I think the biggest thing Inkscape can bring to the table up front is
architectural "lessons learned".
If you want dynamic HTML (by which I assume you mean DOM), my feeling is
you'll need to do something similar to what Sodipodi and Inkscape do:
we have a pre-chewed "semantic" layer a bit like librsvg's, and then a
raw XML/CSS abstract syntax tree underneath it, with protocols for
synchronizing changes between the two.
I hate reinventing wheels, though. What I hope is that we can take
designs prototyped and tested in Inkscape, contribute them to
cairo/f.d.o as components of more portable C libraries, and adopt those
libraries ourselves to the extent practical.
Sort of peeling layers off the bottom as we go, I guess.
> I'd like to see a good "standard" retained-mode API built on top of
> cairo. It should be the kind of thing that might make it almost trivial
> to write a dynamic SVG viewer as mentioned above. It could also make a
> good replacement for libgnome-canvas, (something that Gnome seems to be
> grappling about for right now).
My impression from lurking on Rosegarden lists and those of other KDE
projects is that the state of the generic QT canvas isn't much better.
You know, actually, it's almost like there's a curse on general-purpose
canvas libraries... It might be helpful to examine why such projects
seem to keep failing. I have a feeling mistakes in that area are easy
to repeat.
> As for making this portable, (ie. for Gnome and KDE), I don't know if
> it should talk to one of the existing event-loop integration projects,
> or if it should export its own hooks for plugging in an event loop,
> (ie. perhaps libevent compatible or something). Someone who better
> knows the toolkits and integration projects should be consulted there.
Based on my experiences with Inkscape and Sodipodi, trying to treat
every node in the display graph as a "mini-widget" with event
dispatching is a mistake for broad and deep graphs like those that would
correspond to many complex SVG documents.
The important primitives to have in a retained-mode graphics API for
graphical interactivity seem to be:
* find the first descendant of a specified node matching a predicate
(given as a closure), maybe with a choice of traversal strategies
* primitives for determining whether a node overlaps with
a given shape, maybe with optimized versions for testing against
a point+tolerance radius, and against a bounding rectangle
And then you can readily build "mini-widgets" on top of that if need be
(potentially as a higher-level library), but you aren't forced to deal
with the whole display graph that way.
> In the meantime, has anyone played with cairo-based rendering for
> inkscape? It shouldn't be too hard to get going, (for example, the
> Scribus guys said they got something working in just one weekend last
> week).
Me, kind of. I've been experimenting with it a bit offline, and plan to
work on it more earnestly during the 0.41 development cycle.
One of the big hurdles is that it would need to work on Win32. As far
as I know there is no Win32 GDI surface type, and it's not obvious how
to get at the in-memory buffer of a Cairo image surface.
Maybe some of the Win32 Inkscape developers could help with that, though
(anyone interested?).
-mental
When a font doesn't have real small caps, they are the normal capitals
scaled to 70% of the original hight or the such. Now this way they are
too thin and don't look all that good.
I wonder what the result would be like, if you trace a letter with an
outline that varies it's thickness with the slope of the outline.
Ranging from 0 thicknes for horizontal to 100% thickness (how many pts
that are is adjustable) for vertical lines. I have no clue, it that
works, but I think it might look quite OK.
It's properbly not svg complient at all :(
I'll propose this to the scribus list as well.
David
I don't really know how the keyboard selection commands should best
behave with respect to layers/lockedness/hiddenness, so I decided to
make this configurable.
Now there's a "Selecting" tab in Preferences which has three
checkboxes that affect "Select all" (Ctrl+Shift+A) as well as
selecting by Tab/Shift+Tab:
- select only in current layer
- ignore hidden objects
- ignore locked objects
By default all three are on, which is the most natural setting, but
it's different from the behavior in the past and may not be the most
convenient. Experiement and report which works best for you.
Now only the Find dialog remains to be made layer/lock/hide-aware.
Mental,
I've got most of the layer rename dialog thingee set up. Could you put
the code needed to rename a layer into the apply() routine in
layer-properties.cpp?
Bryce
