- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] layers
by bulia byak 12 Jun '04

12 Jun '04

>When I'm doing comic projects in inkscape, the way I typically have it >organized is each panel is a set of: I'm not quite sure what is a "panel" but I think all this is covered by the "named selections" (or better cal them "sets") idea. Here are a few more UI tweaks for it: - When you happen to manually select exactly the objects that make up one of the sets, that set's name is displayed in the combo box - the same end result as if you selected the name from the list and thus caused it to be selected. - When one of the names is shown in that combo box, you can erase it, which results in removing this set from the list of defined sets. (Objects remain, they're just not in the set anymore.) Maybe a small button near the box can also be added for this purpose. - When you select something and then type the name of a set in the combo box (rather than select that name from the list), the current selection is added to that set, rather than replace it. - In the Object Properties dialog, add a Sets field next to Id, which would list (and allow you to edit) a comma-separated list of sets that the currently selected object belongs to. For multiple selections, list only those sets to which all selected objects belong. - In the same dialog, enable the visible/active checkboxes to be applicable to any number of selected objects. That will let you select one of the sets and hide/unhide it with a couple of clicks. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: pango again
by bulia byak 12 Jun '04

12 Jun '04

>what should fuzzy font matching do? (i admit i haven't >really looked into what it was doing) It has almost nothing to do with actual fonts, it only does a lot of string parsing - breaking CSS family specification into tokens, comparing them to the names of all available fonts, and selecting the best match based on various priorities and weights. I'll look at how Pango does its matching but I think we'll need to keep most of, if not all, of this fuzzy matching code (which even does some cashing to speed up matching - this turned out necessary for documents such as keys.svg). Likely we'll ask for a list of font names (families and styles) from Pango, do our fuzzy matching, and request the font with the best name we found. > > 5. Symbol fonts still don't work. When I select > > Symbol font in the list, I > > get > >argh. some error checking is needed. tho it's strange >that the symbol font doesn't have a charmap. how is >the unicode<->glyph conversion done? PfaEdit (a highly recommended font editor btw) reports that symbol.ttf (from a Windows installation) uses "Symbol" encoding, and it correctly shows all its characters. So perhaps it's just a special encoding that we need to support. >pango layout should do the trick, with one caveat: >since you can only specify one font for the layout, >for the dominant direction, all the text in the >opposite direction gets a default font from pango. if >you have idea on how to tell pango to choose one >specific font... Well, in this case one can put the opposite-direction fragments to be in <tspan>s in SVG, and set a font for them. Anyway, this is much better than not having RTL before. Unfortunately I can't compile the Windows build today - errors during linking: libinkscape.a(inkscape.o)(.text+0x1a6):inkscape.cpp: undefined reference to `sp_marshal_VOID__POINTER_UINT' libinkscape.a(document.o)(.text+0x194):document.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE' libinkscape.a(view.o)(.text+0x136):view.cpp: undefined reference to `sp_marshal_BOOLEAN__VOID' libinkscape.a(view.o)(.text+0x1e7):view.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE' etc. I used to get such errors before from time to time and I don't really know how to fix them. Any help is appreciated. _________________________________________________________________ Free yourself from those irritating pop-up ads with MSn Premium. Get 2months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 2

win build error
by bulia byak 11 Jun '04

11 Jun '04

Ted, here's the error I get when trying to crosscompile for windows: extension/implementation/script.cpp: In member function `gchar* Inkscape::Extension::Implementation::Script::solve_reldir(SPRepr*)': extension/implementation/script.cpp:90: error: `INKSCAPE_EXTENSIONDIR' undeclared (first use this function) Is this something you can fix? _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

window focus confusions
by Johan Forsberg 11 Jun '04

11 Jun '04

Hello, I've been using Inkscape fairly often lately and there's one thing in particular that has been annoying me a bit. If I keep more than one image-window open, and want to use e.g. the fill/stroke-dialog, there's always a chance that my wm changes focus to the wrong image-window while my pointer travels between the windows. This happens naturally if the windows overlap so that the wrong window is between the right window and the dialog. If this happens, whatever I do in the dialog will affect the wrong window/object. I realise that maybe I'm in the minority who swear by the "sun mouse" behaviour, but I'm not prepared to part with it on the account of one program :) So, I wonder if there could be an intuitive way to either 1. make it visually obvious (perhaps the selection could change colour) which window my dialog actions will affect, or 2. to lock the "active" window (maybe the last one actually edited?) to consequent dialog actions. Or maybe there's another, more obvious way to solve it. But I think as it works now, it's potentially confusing to new users. I can get around it by organizing my windows, but it's still easy to slip. Thanks! -- Johan Forsberg

1 0

RE: pango again
by bulia byak 11 Jun '04

11 Jun '04

Hi Fred, your patch is fantastic! Most everything works out of the box and the text looks really smooth with subpixel positioning. (No more autohinting, yay!) Even letterspacing works as before. I posted your patch to the tracker, please attach updated versions there. Here are the issues (all of the below is on Linux; I'll try to build it on Windows later today and report results in a separate message): 1. Convert to path distorts lettershapes. I attached a sample to the patch tracker. Compare the red "a" (path) with underlying black "a" (glyph). Looks like all bezier control points became closer to the nodes. 2. Some fonts are badly distorted. I attach (also in the tracker) one such font that is used in the same lettershape-distortions.svg. When converted to path, however, these distortions disappear, although the resulting path is still wrong as described in 1. above. 3. I see you disabled all the fuzzy font matching and name parsing code in nr-type-fontdirectory. Do you think it will be difficult to reenable it with your code? I have written a good deal of that file so I could now try to reenable it. Any hints you might give are welcome. 4. Kerning pairs in fonts still don't work. I thought Pango would provide that automatically - or is some additional support needed? 5. Symbol fonts still don't work. When I select Symbol font in the list, I get ** (inkscape:25358): WARNING **: Unable to load unicode charmap from font file /home/d/.fonts/SYMBOL.TTF ** (inkscape:25358): WARNING **: Unable to open font file /home/d/.fonts/SYMBOL.TTF for font Symbol 512, falling back to /usr/share/fonts/console8x8.pcf.gz ** (inkscape:25358): WARNING **: Error in FT_Set_Char_Size: 23 Haven't yet checked Hebrew or Arabic. Is right-to-left supposed to work now? If not what is needed to make it work? _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] layers
by bulia byak 11 Jun '04

11 Jun '04

> > * an object can be in zero or more layers > >Such concepts are better called groups or sets. >Can what you aim at be described as saved selections? Yes! I think it's exactly what it is - named selections. And from this viewpoint, the idea is useful, but it should NOT be coupled with visibility any more than it's coupled with z-order. It should be only concerned with saving and restoring selections (that possibly span layers or groups). And after you call it "named selection" and remove any attempts to tie it in with layer-like behavior, the idea of an object belonging to more than one named selection is perfectly legitimate. The UI might be simple: a "Name selection" command and an extra drop-down list in Find that lists all named selections in document. Or, even simpler, a single combo box on the selector top panel where you can type in the new name of your current selection, or select one of the defined names from a drop-down to reselect them. And the more I think about it, the more I like this idea. Saved selections can indeed be very useful. Mental, what do you think? _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: [Inkscape-devel] layers
by bulia byak 11 Jun '04

11 Jun '04

The idea is attractively simple, but I see some problems: > * layer visibility is an Inkscape-specific thing, separate from CSS >visibility of individual objects That's problem #1. Remember that our SVG must render the same anywhere. If I hide a layer and save, I must not see that layer in Batik either. I don't see how you can achieve this, other than by manually adding SVG invisibility to all objects that are in an invisible layer (messy). Also: - I disagree that layers should not be related to z-order. A very useful operation (in a traditional vector editor) is re-z-ordering layers, which is not possible with your scheme - except if you select all objects in a layer and group them and move them up or down... which brings us back to the original scheme. - The notion of current layer is possible (just add the name of the current layer to all newly created objects), but again this disregards z-order which may be very inconvenient. For example if I work in a layer which is on top of "background" layer but under the "shades" layer, I expect all new objects to be created in between these layers as well. In your scheme, they're still added on top of all objects, which makes the entire layer thing less than useful. - The idea of an object belonging to more than one layer is cool, but the more I think of it the less I like it. I think it's just unclean and will give users lots of headaches (such as "Why hasn't this object disappeared when I hide its layer? Why do some objects in X disappear when I delete everything in Y?" etc) without significant advantages (or at least I don't see such advantages). When I want object X to be visible both with layer Y and with layer Z, I just put it in a third layer and name it accordingly and manipulate it as needed. I think it's saner that way. Or am I missing something? _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 3

Re: [Inkscape-devel] layers
by Bob Jamison 10 Jun '04

10 Jun '04

Thorsten Wilms wrote: >Such concepts are better called groups or sets. >Can what you aim at be described as saved selections? > > > That might be a good model. The reason people keep saying "groups" is merely because the <g> tag is the mechanism that the SVG format gives us for things like this. Actually, z-layered groups was what I thought people were asking for when this idea was first mentioned. Just like Illustrator, Corel, even OpenOffice. Check out OO Draw, and see how they do it. A bit clumsy, but it works. It is definitely necessary at times in a drawing program to affix an image or other drawing in the background, sometimes ghosted, to provide a guide for drawing or tracing. This is something I could use myself, actually. Ok, back to my 4-day weekend. Bob

1 0

RE: [Inkscape-devel] layers
by bulia byak 10 Jun '04

10 Jun '04

>You're describing groups; this is something different. OK. But then I need our groups to be significantly expanded in functionality: I need a "current group" to which I can by default add newly created objects, and I need a dialog that would show me only these top-level groups so that I can get an idea of what I have in the document, and to set visibility/editability of such groups easily. See? You may call them "groups," but then we'll simply end up adding a lot of the standard layer functionality to these groups, because your "slices" do not support it. >I guess using the term "layers" sets up wrong expectations of behavior >for people coming from Illustrator/graphic design backgrounds (because >Illustrator calls its top-level groups "layers" and limits the >functionality of child groups), so we will need to find a better term. OK, let's call your idea "slices". Or "aspects". >What I'm describing is fundamentally different (we will still have >groups, so top-level groups will necessarily act like "Illustrator >layers") -- think of my "layers" being like search keywords, where one >can say "hide all objects not matching this set of keywords". We already have Find which is pretty close to what you describe. And we can make it behave almost exactly as you describe, by adding some sort of a combo box to Object properties that would allow you to set inkscape:keywords attribute by editing it or by selecting from a pool of other keywords in the document, and adding one more field to Find for searching by these keywords. It's not difficult, I just don't see much use in it if, as you say, we still need "traditional" groups as well. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com >From MAILER-DAEMON Thu Jun 10 01:59:18 2004 Date: Thu, 10 Jun 2004 10:58:33 +0200 From: Thorsten Wilms <t_w_@...123...> To: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] layers Message-ID: <20040610085833.GA5599@...124...> Reply-To: tw@...125... References: <1086842330.709.7207.camel@...4...> Mime-Version: 1.0 In-Reply-To: <1086842330.709.7207.camel@...4...> Priority: normal X-Mailer: Mutt User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Sender: inkscape-devel-admin(a)lists.sourceforge.net Errors-To: inkscape-devel-admin(a)lists.sourceforge.net X-BeenThere: inkscape-devel(a)lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, <mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Id: <inkscape-devel.lists.sourceforge.net> List-Post: <mailto:inkscape-devel@lists.sourceforge.net> List-Help: <mailto:inkscape-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, <mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline On Thu, Jun 10, 2004 at 12:38:51AM -0400, MenTaLguY wrote: > > In many tools, layers are entirely are decoupled from grouping and > z-ordering. They basically just let you take slices through "aspects" > of the document and work on them in isolation. > > For 2d apps, think of GIS databases or KiSS dolls. For 3d apps, Blender > or Unigraphics. > > I think that's the direction we should go with layers, too. It gives us > some really useful functionality we'd otherwise not have. But most the well known vector and bitmap apps all couple layers to z-order. And the whole metaphor doesn't make sense if you take that aspect away. So whatever you go for: don't call any concept that doesn't create z-order compartments layers And a z-order management facility just like illustrator/freehand layers is needed anyway. > * an object can be in zero or more layers Such concepts are better called groups or sets. Can what you aim at be described as saved selections? Going with the set name: Objects could be explicitly added to sets, or sets could be like live queries (allthough I wonder if that wouldn't be overkill). Just an idea: How about inheritance of properties from sets/groups to members? > * objects are visible in the editor iff: > > 1. their CSS visibility is "visible" > > 2. at least one layer they're in is visible, or they aren't in any > layers > > 3. their parents are visible by these criteria > > * there should be a {select,unselect}-by-layer feature > > * there should also be an {add,remove}-selected-objects-to-layer > feature Oh, saved selections wouldn't have visibility of their own, but allow to change all members state at once. --- Thorsten Wilms

1 0

layers
by MenTaLguY 10 Jun '04

10 Jun '04

Been thinking a bit about layers today, especially in light of the RFE that Jonathan put in, and Thorsten's comments earlier. I realized that I'm still wayy too stuck in the Illustrator mindset. They've got the right idea. Illustrator layers really are just glorified groups. We can do better, and different. It's helpful to look at other tools, and what layers look like in their generalized form. In many tools, layers are entirely are decoupled from grouping and z-ordering. They basically just let you take slices through "aspects" of the document and work on them in isolation. For 2d apps, think of GIS databases or KiSS dolls. For 3d apps, Blender or Unigraphics. I think that's the direction we should go with layers, too. It gives us some really useful functionality we'd otherwise not have. So, here's the deal, I think: * we keep the document tree dialog we had been planning, but we don't call it "layers" anymore, and don't try to shoehorn Illustrator-style pseudo-layers on top of it (we'll still have some easy facility for drawing/editing "inside" groups though) * inkscape:groupmode goes away (bulia has already rendered it obsolete anyway) * the "layers" dialog is just a list of layers with visibility toggles and buttons to add/remove layers * an object can be in zero or more layers * this is determined by the inkscape:layers attribute, which holds a whitespace-separated list of layer IDs (NMTOKENS) * we'll probably have <inkscape:layer> elements too, somewhere, to hang per-layer attributes (like descriptive names) on, but layers will fundamentally exist just by virtue of being referenced * in absence of this attribute, an object is considered to be in the same layer(s), if any, as its parent (this is the default for new objects) * layer visibility is an Inkscape-specific thing, separate from CSS visibility of individual objects * objects are visible in the editor iff: 1. their CSS visibility is "visible" 2. at least one layer they're in is visible, or they aren't in any layers 3. their parents are visible by these criteria * there should be a {select,unselect}-by-layer feature * there should also be an {add,remove}-selected-objects-to-layer feature I think that should cover all the bases, and shouldn't require much work to implement. Personal life allowing, I'll take a stab at getting this hammered out by next week. (no, I've not forgotten about pangoification ... my contribution to that this week will be getting the C++ification stuff documented, time permitting) -mental -----Forwarded Message----- From: SourceForge.net <noreply@...34...> To: noreply@...34... Subject: [ inkscape-Feature Requests-857357 ] LAYERS: Various ideas combined Date: Mon, 07 Jun 2004 22:17:17 -0700 Feature Requests item #857357, was opened at 2003-12-10 05:47 Message generated for change (Settings changed) made by bryce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=857357&group_i… Category: None Group: None Status: Open Priority: 9 Submitted By: Jonathan Phillips (kidproto) >Assigned to: MenTaLguY (mental) Summary: LAYERS: Various ideas combined Initial Comment: Something which I really missed in SVG is the ability to work with layers. Layers should allow to show and hide all objects in them and it should be possible to change some attribute in all objects of a layer (for example, the line color). Alternatively, it should be possible to select objects by layer - then this can be done manually. Note that layers are not groups: Objects from different groups can be in the same layer so they move with the other objects in the same group but whether they are visible or not depends on the setting of the layer. Layers can be used to depth-arrange objects (so when I move a layer in front of some other layer, the objects in the different groups must be reordered accordingly). When a group is in a layer, then all objects in that group are in the same layer. I'm not sure if it would be a good idea to allow one object to be in different groups (it's visible when at least one of them is visible). For the implementation: When I did this, I added a x:layer attribute to the elements plus a x:layer-style element to the SVG. Then my XSLT script would select drop all elements of invisible layers and sort the layers according to the depth attribute of the x:layer-style elements. ( NOTE: originally in sodipodi bug tracker as bug(s) # 616232 ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=857357&group_i…

1 0

Help needed setting up good Nightly Snapshot system
by Bryce Harrington 09 Jun '04

09 Jun '04

Hi all, As Bob mentioned, the visit from Slashdot cratered our nightly Win32 snapshot server, and we need some help coming up with a better solution. No Inkscape experience needed, just need to be familiar with SourceForge, scripting, and compiling apps. The snapshots have proven useful in letting users test out and report on recently implemented features without having to compile it themselves. So this is a pretty highly valued service for the community. What we need going forward is a script or set of scripts that: * Checks out from CVS once a day and compiles for Win/Lin/Mac both debug and optimized. (e.g. via SF compile farm?) * If compilation is successful, post the packages to mirrors (e.g. SourceForge). * Allows users a place on the web to go to to get the latest version * Creates and provides autopackage versions (the AP folks are doing this for us currently, so this may not be necessary but is worth considering if it's not hard to do.) * Doesn't place the administrative responsibility on a single specific person * Code is checked into a subdir of inkscape_project/ * Has a README and/or wiki page explaining install & usage If you'd like to work on this or a piece of it, let me know and we can work out the details. Bryce

10 20

Re: your patch
by bulia byak 09 Jun '04

09 Jun '04

>and be more concious of this sort of thing. (comes >from being self taught too, no one ever corrects you >:) ) One more comment: try to modularize more, instead of copy&paste. You may want to check out how I reworked your "copy gradients to gradients clipboard" code in selection-chemistry some time ago. >this was the plan, as i put pattern support in >get_stock when i wrote it. Again could do with a >"table of previews" type widget tho, should look into >if the GIMP or similar has something we can lift. Yes, and I think that widget will resolve the speed problem as well. Namely, it will need to generate previews on the fly when you open it, and show incrementally those that are already generated (the way images are shown as the are downloaded in a browser). This will remove the delay from fill&stroke. 2 remaining problems with patterns in fill&stroke: - it does not apply a pattern to multiple selected objects - I will need to create a function that, for any pattern, returns its visible ancestor, i.e. the first pattern up the chain of hrefs that has any children. Then we need to use this function everywhere you access a pattern, so that (1) auto-generated adjustment (childless) patterns linked to some other patterns are never shown in the menu and cannot be applied (you can only apply "root" patterns) and (2) for any selected object, you see its "root" pattern highlighted in the menu, instead of the real adjustment pattern it is assigned in SVG. This way it'll make much more sense. I will tackle the second problem later today. If you know how to easily fix the first one, that would be great. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Different idea for 'running' a file
by Bob Jamison 09 Jun '04

09 Jun '04

Hi all, I had this idea last night at the pub, and I think that it might be a cleaner and easier way to enable scripting interactivity than a "runmode". I'd like to toss this idea to the group and see what you all think. How about this: we consider "running" a file to be something like a "Preview" window. Instead of modifiying the behaviour of the Inkscape editor, we clone the repr tree, make an instance of an Inkview viewer, and display that. If we can just regard Inkscape as being "edit mode", and Inkview as "run mode", it might make for a cleaner separation, and obviate the need for things like if (runmode) { } in Inkscape source. Then, any of us working with interactivity need only hack on the player code, and can leave the editor stuff untouched. How does that sound? Anyone have an opinion? Bob

3 2

your patch
by bulia byak 09 Jun '04

09 Jun '04

I have applied and committed your patch after some cleanup. Comments: - Please get yourself an editor that can do auto indent. Now you seem to indent manually which is a pain both for you and for those who read your code :) - Always generate diffs ignoring whitespace differences (diff -b). That would make your patch much smaller and easier to read. - It's "Pattern fill", not just "Bitmap fill" - No need to set "sodipodi:fill-pattern". You seem to have copied it from "sodipodi:fill-cmyk" but that is entirely different story (and we plan to eliminate it btw). - Be more defensive in coding. You write e.g. pat = SP_PATTERN(g_object_get_data (G_OBJECT(gtk_menu_get_active (GTK_MENU(gtk_option_menu_get_menu (GTK_OPTION_MENU(patmnu))))), "pattern")); Not only is this ugly, but it's very easy to break. Instead, separate it into sequential assignments and do proper checks between them ("Did I get what I think I get?" "Is there an active item?" "Is this really a pattern?" etc). For example now your code will break if I add a separator to the menu (which is an item but has no pattern data). - Eventually it would be the best to treat patterns the same as markers. That is, add previews to the menu, and add a patterns.svg document that would contain some nice predefined patterns for users. That should be easy because we already have all the code in place. However this has to wait until we sort out the speed problem with marker previews first. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

WG: [Inkscape-devel] ecma -- my last spam for the day
by Taraben, Adib 09 Jun '04

09 Jun '04

Scipting is great, but this needs some kind of modeswitching in between runmode and editmode. Is it? Adib. ________________________________ Von: inkscape-devel-admin(a)lists.sourceforge.net im Auftrag von Bob Jamison Gesendet: Mo 07.06.2004 21:00 An: inkscape-devel(a)lists.sourceforge.net Betreff: [Inkscape-devel] ecma -- my last spam for the day Ok. I promise that this is my last post to the list today. I am finally caught up from last week, and now I can start adding the real code and not bother this list. I added one file: /src/ecma/script01.svg ...which is the example scripted svg file from the spec: http://www.w3.org/TR/SVG11/script.html#ScriptElement I would like to consider the current goal for scripting to be to make this file work correctly in Inkscape and/or Inkview. Does that sound reasonable? Bob ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 3

question regarding use of inkscape for my own project
by Julien Keable 09 Jun '04

09 Jun '04

hello happy community, I'm new-to/mixed-up-with SVG, and I'm starting my own SVG-friendly application. I need to load SVG files, modify/generate objects and their properties via API calls and render it in a buffer. While looking at cairo and librsvg to render SVG graphics, I realized (correct me if I'm wrong) their API didn't provide calls to access individual objects or their properties. Then I figured out using some existant app would be much smarter, as open source is starting to kick some serious mellons. Then I saw inkscape and got very excited, because as a bonus, we get SVG extensions and automatic rendering technology updates and so on.. So my plan is to strip inkscape from its GUI part, or simply link the relevant CVS dirs to my own CVS, but this seems a bit harcodre to me and I'd like to hear your wisdom speak about this. (ex : which dirs/classes ? ) another thing I'd like is a table that looks like this : loads SVG renders SVG has API to modify objects ksvg cairo libart librsvg Just to make things as clear as possible, I need to : - load svg files - access/transform individual objects through API (not GUI, I don't have one) ex : rotate(MyCube, 123) - render it in some 32 bit pixel buffer (RGBA) BTW, why is everyone is moving away from libart (inkscape, sodipodi)? thanks, Julien Keable

5 8

ecma -- my last spam for the day
by Bob Jamison 09 Jun '04

09 Jun '04

Ok. I promise that this is my last post to the list today. I am finally caught up from last week, and now I can start adding the real code and not bother this list. I added one file: /src/ecma/script01.svg ...which is the example scripted svg file from the spec: http://www.w3.org/TR/SVG11/script.html#ScriptElement I would like to consider the current goal for scripting to be to make this file work correctly in Inkscape and/or Inkview. Does that sound reasonable? Bob

4 4

Pango
by Bryce Harrington 09 Jun '04

09 Jun '04

Hi all, Last weekend I read through the libnrtype code and put some comments to document what each of the routines do. Probably didn't get 100% correct though, and I wrote in a lot of questions. Could someone scan through the code for the 'Q:'s and see if they can fill in what I couldn't? Also, I reviewed the Pango API's last night and tried to sort out which groups of API calls would need to be implemented in each of the libnrtype files. I put these as steps in the Roadmap in Wiki. Again, I don't know how accurate I was so would appreciate it if someone could check it over and clarify what I missed. My goal was to drill down far into the details of each step. I feel like I came close, but not close enough, so any help specifying that more precisely would be appreciated. >From what I understand, most of libnrtype consists of functions to look up typeface names, font family names, metrics, attributes, etc. In effect, it implements a big 'dictionary' of this info, with various functions to get/set the data, initialize structs containing typeface info on the fly as needed (with reference counting), and so forth. For all this stuff, Pango has routines which do exactly the same thing. So these can be switched over pretty directly, I'd guess. It also has functions for getting outlines of fonts, which I don't totally grok yet, but it looks like there are similar routines in Pango. I can't tell if these would be as straightforward to switch over, since different kinds of structs are involved, so this may be the hard portion of the project. Beyond the above two things, the vast bulk of the rest of the code seems to be there to implement a class hierarchy. I.e., constructors, init, destructors, virtual functions, yada yada. Pretty straightforward and won't need to be fiddled with this go-around. I don't think C++-ifying it would buy us anything, since we'll probably want to majorly restructure all of this code anyway once we're fully converted over to Pango. By the way, Pango looks *very* cool - it handles a much wider degree of font styles, types, etc. than we do. Stuff like lower caps, strike-out, etc. I don't think we support these kinds of fonts at all, so we'll be gaining it all. Also, in Fred's pango_test we were able to get an arabic font to display, that didn't work for me at all in Inkscape. So potentially we may be picking up support for a much wider range of fonts, which would be quite cool. Bryce

2 2

pattern news
by bulia byak 09 Jun '04

09 Jun '04

- Now there's a Tile command (Alt+T) that creates a rect with pattern fill out of the selection. Lots of fun. - The Fill&Stroke dialog lets you select any of the patterns defined in the document for any object (done by Sim). - I changed the default back to import bitmaps as <image>s. Those who prefer it to be bitmaps however can change the setting in Preferences (Misc tab). Also you can select any <image> and Tile it for the same result. - Preferences>Transforms tab: there's now a setting to transform or not transform the pattern fill with the object. When it's off, you transform objects but their pattern stays unmoved; when on, they're transformed as a whole. Works the same in both Optimize and Preserve modes. Still todo: - The "transform pattern" switch will be moved to the selector top panel, alongside the "scale stroke" and "scale rounded corners in rects" switches. Also the same switch needs to be created for gradients. - An Untile command to convert a pattern fill to the original container object plus the object(s) that were in the pattern. - The pattern fills will get knots on the canvas that will let you arbitrarily transform patterns inside objects by dragging the knots (Sim is working on that). _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

change to Make for ecma
by Bob Jamison 08 Jun '04

08 Jun '04

I worked libjs.a and /ecma into the Mingw build files. It all builds/links with the new stuff. I will look into adding them to the Unix files later, when I am back from the office. I will try to get on jabber://inkscape@...132... later. Bob

1 0

RE: [Inkscape-devel] L10n questions
by bulia byak 08 Jun '04

08 Jun '04

>>#: src/verbs.cpp:962 >>"Ru_lers" >> >>#: src/verbs.cpp:962 >>"Show or hide rulers" >> >>#: src/verbs.cpp:963 >>"Show or hide scrollbars" > >Not used now, replaced by texts in interface.cpp. But it would be better to >rework sp_ui_menu_append_check_item_from_verb so that when verb is >non-null, it takes the label and tooltip from it as well (now it only takes >shortcut). And I just did this. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

5 5

Revisiting ECMA. Seriously, folks. :)
by Bob Jamison 07 Jun '04

07 Jun '04

By the way, I am finally starting again to work on the ECMAScript/SVG binding (not Inkscape scripting). I checked in a cleaned-up directory of Mozilla's Javascript C engine. It is in /src/extension/script/js so that it can be convenient to both the SVG binding and IS scripting guys. I also started checking in a few files in /src/ecma for testing. Hopefully in a few days we can start seeing some progress. Bryce shamed me out of my lethargy with his article. ;-) Off topic: You might be interested in this mail list thread from another OS project (probably -the- OS project), gcc: http://gcc.gnu.org/ml/gcc/2004-06/msg00014.html This shows the kind of interaction among the members of a very large project. Some of the threads in that list can be fascinating. Bob

3 5

Re: [Inkscape-devel] Re: Inkscape Layers
by Bob Jamison 07 Jun '04

07 Jun '04

Yes, the intent -is- to provide layers just like in other applications. When we talk about using <g> nodes to group them, what we are talking about is merely how to store layer information in the SVG format. Thorsten Wilms wrote: >I didn't catch the whole discussion about layers, I just hope I'm not >totaly off here. >However, layers can be seen as serialized selections and are in this aspect >just like groups. But in vector graphics apps layers usualy establish >z-order 'compartments'. There is z order inside each layer, but the general >z-order of each member of a layer is higher than those of members of layers >below and lower than those of members of layers above. > >Grouping is used to lock relative position of items and for scaling them >all together. Layers are about organizing z-order, toggling visibility >and locking. Visibilty and locking can of course work the same way for >groups, it's just they are usualy not listed in vector apps. > >It would be interesting to implement/express layers as special case of >groups, but I have no idea how to go about toggable z-order compartment >behaviour. > > >--- >Thorsten Wilms > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the one >installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > >

1 0

Article followup
by Bryce Harrington 07 Jun '04

07 Jun '04

Hi all, I wanted to follow up with a few comments on the reception of the article. I was mortified when I saw that the Slashdot blurb said Inkscape was my "brainchild" and that I was _the_ founder of Inkscape rather than _a_ founder. I hope no-one took offense at that. I suppose its unusual for open source projects to be true team efforts, but that is really one of Inkscape's strengths and one of the things that makes it so fun. I also want to apologize to Bob for cratering his server! Hope that didn't cause problems beyond just the loss of the machine. Hopefully with Artemio's help, that problem will be stimulating us to gain a better solution in general for the future. Despite the problems, I think it went quite well. The main goal had been to raise awareness of Inkscape and what we got exceeded what I'd been hoping for. Also, I noticed that a number of the points I wanted to make were conveyed and received by the audience. A couple of the points sparked some interesting discussions; I think our "patch first, ask questions later" policy got people thinking. Big thank-you to mental or whomever suggested emphasizing we don't _blindly_ accept patches, but do check licenses, etc. I again want to thank everyone that helped with editing the article and rejon for giving me a deadline to get it done by; as much as I grumble about deadlines, it was useful motivation. Nathan - it turned out we missed one of the erroneous "it's", as several readers pointed out to me. :-) I'd also like to return the favor. I think with this general "What's Inkscape" piece out of the way, there is an audience for more focused articles, and if anyone is interested in writing one I would be more than happy to lend a hand. For example, I'd bet an article giving advice about usability would be well received. An article about Inkscape internals as they relate to SVG rendering would as well. I also think a usage-oriented "secrets of Inkscape" article would be appropriate. So if anyone is interested in authoring an article on any of those subjects, I would be happy to help in any capacity. Bryce

4 4

orphan collection
by MenTaLguY 07 Jun '04

07 Jun '04

Just a quick heads-up: I've comitted my orphan collection code to CVS. Among other things, this means that leftover gradients/markers/patterns will get automatically cleaned up when the objects that use them are deleted. Caveats: * this only applies to such objects created with a build of Inkscape which post-dates this commit * not all automatically-created objects will necessarily be collected; the code that creates them needs to be updated to set the correct collection policy * paint objects won't get collected until another editing operation takes place, since NRArenaShape currently holds onto an SPStyle for too long Technical details: Assuming its collection policy permits it, an object will be collected if neither it nor its descendants have any outstanding inter-document URI references (nonzero SPObject::hrefcount). There are two "policies" for collecting orphans: * "with-parent" - the object will only be collected if one of its ancestors is collected * "always" - the object is always collected if unused (a third policy might be "never", which would necessarily also prevent that object's ancestors from ever being collected; I do not plan on implementing it) The policy in effect is determined by the inkscape:collect attribute. Be careful with the "always" policy; it really only makes sense for "private" objects that are indirectly created behind the scenes (e.g. by selecting a fill or marker option in the GUI). -mental

1 0