November 2004 - Inkscape Devel

pre4 requested
by bulia byak 23 Nov '04

23 Nov '04

The absolutely last feature, the "new layer" dialog, has been just checked in. Drawing on locked or invisible layers is disabled. So we are good to go into freeze as soon as pre4 is made (source and static binary). There are two layer bugs which I hope are easy to fix: - when renaming layer, the widget at the bottom is not updated until you move mouse over it - when creating new layer, if you press Enter in the dialog, the layer is created twice (clicking on "create" does it once as expected)

1 0

Freeze question & updated spanish po
by Lucas Vieites 23 Nov '04

23 Nov '04

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

5 9

OPB: Linux Brings Oregon International Attention
by Bryce Harrington 23 Nov '04

23 Nov '04

This is terribly off topic but I thought it was cool - our local PBS station is running a piece about Open Source here in Oregon... http://www.publicbroadcasting.net/opb/news.newsmain?action=article&ARTICLE_… Bryce

1 0

SVG Linking
by NAGY Endre 23 Nov '04

23 Nov '04

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.

2 1

caption for Layer - not readable
by Taraben, Adib 22 Nov '04

22 Nov '04

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.

4 4

Spam again
by Gazal, Geraud (GE Healthcare) 22 Nov '04

22 Nov '04

Hi The wiki has been spammed once more. The spammer is registered as Durik... ( see revisions of spammed pages for more info) Regards, Matiphas

2 1

Feature Freeze for Inkscape 0.40 Release
by Bryce Harrington 22 Nov '04

22 Nov '04

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

3 4

Re: [Inkscape-devel] slower than sodipodi (fwd)
by MenTaLguY 22 Nov '04

22 Nov '04

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

3 4

fake small caps
by David Christian Berg 21 Nov '04

21 Nov '04

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

2 3

NEW: changes keyboard selection commands
by bulia byak 20 Nov '04

20 Nov '04

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.

2 2