- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Extensions (inx) files
by Bob Jamison 18 Apr '08

18 Apr '08

>Now perhaps would be a good time to hook some validation into the build >process (and into the code?) but that would probably need a small C app (all >validators I have at hand now are either in Java or .NET). > xmllint will be available wherever libxml2 is installed. Every Linux box, basically. And since Inkscape links with it, it's required anyway. xmllint -relaxng file.rng something.xml bob

1 0

Problems with font selection toolbox.
by Marcin Floryan 18 Apr '08

18 Apr '08

Hi! There seem to be an awful increase, recently, in the number of bugs reported around the behaviour of the font family and font size selection toolbox in 0.46 (and it equally affects SVN as for now). There are also some outstanding Critical bugs - just some examples are: https://bugs.launchpad.net/inkscape/+bug/168161 https://bugs.launchpad.net/inkscape/+bug/168320 https://bugs.launchpad.net/inkscape/+bug/168719 https://bugs.launchpad.net/inkscape/+bug/183179 https://bugs.launchpad.net/inkscape/+bug/218502 https://bugs.launchpad.net/inkscape/+bug/218502 I know often this is associated with Win32 platform but I have seen those on Linux as well. What seems to cause the problem often is when the default font (or font applied to the text) does not exist. Would it not be nice, if one could enter any arbitrary font family name for a font and have Inkscape handle it gracefully. I would like to help with this issue (OK, I can even abandon my Linux for a bit to help on the Win32 platform) but I still know too little of the Inkscape codebase. But what seems to me like a plausible solution would be to reproduce the functionality of the Text and Font dialog in the font tool bar. I presume that many issues could be solved when SVG Fonts are finally implemented. Just wanted to grab some of your attention though no doubt it is already on the issue :-) Cheers, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

2 1

restack extension
by Alexandre Prokoudine 17 Apr '08

17 Apr '08

Hi, We got a neat new extension by Rob Antonishen during 0.46 development cycle that for some reason didn't go into 0.46 after all. It's called "Restack" and it does exactly what you might guess: "restack the selected objects' z-order, from left to right, top to bottom (or vice versa), specifying the base point for comparison (top, left, middle, etc.)" https://bugs.launchpad.net/inkscape/+bug/182002 Do we want this as part of 0.47? Alexandre

2 4

Behavior of X,Y,W,H settings in the GUI
by qazxswedcvfrtgbnhyujmkiolp2000 qazxswedcvfrtgbnhyujmkiolp2000 17 Apr '08

17 Apr '08

Hello Inkscape Devel, Great software, big fan here. I notice that the X,Y,W,H settings in the GUI include the stroke width. i.e. if you have a 2,2 sized object located at 0,0 with stroke width of 0.05, the X,Y position reads -0.025,-0.025 and the W,H value reads 2.05,2.05. Using the grid can help, but technical drawing with this system is very difficult. Would it be possible to add an option so that X,Y,W,H settings refer to true object coordinates (like they are output in the SVG file), independent of the stroke width? Thank you qazx (qazxswedcvfrtgbnhyujmkiolp)

2 3

SoC Updates
by Gail Carmichael 17 Apr '08

17 Apr '08

Hi everyone, I mentioned in my app that I had applied to work with a colleague for Summer of Code (with Python Software Foundation) in addition to the text application I made to Inkscape. I also stated my intentions to try and work on Inkscape one day a week or so starting in the fall, meaning I would attempt to tackle the stuff of my app even without SoC. Still, I would like to participate in the official program if possible, since I can't justify working more than that one day a week otherwise (it's thesis time), no matter the project. I had promised in my app to keep would-be mentors updated on the progress of the other app. At this point, PSF has 50 projects with mentors, but only 30 slots, so it's hard to know what my chances are there, but duplicate acceptances have to be sorted out still. I think that happens by the 18th, which is the deadline that Aaron mentioned for ranking the apps. Also, I don't think I necessarily need a mentor with a lot of experience in text (i.e. Richard) but just with Inkscape architecture in general. That would ensure Richard would be available for Felipe's application without precluding me being able to do mine. I think all would-be SoC'ers would appreciate any feedback in terms of our applications, if anyone can give any :) Gail

6 12

Re: [Inkscape-devel] Extensions (inx) files
by Bob Jamison 16 Apr '08

16 Apr '08

Or RelaxNG. Much simpler than Schema, easier to read. Supported by libxml2. bob -----Original Message----- >From: bulia byak <buliabyak@...400...> >Sent: Apr 16, 2008 12:41 PM >To: Ted Gould <ted@...11...> >Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> >Subject: Re: [Inkscape-devel] Extensions (inx) files > >On Wed, Apr 16, 2008 at 2:09 PM, Ted Gould <ted@...11...> wrote: >> Yes, I'm not quite how to do this in XSD, but it seems that it has to be >> doable. I'd really hate to have to change the XML format just to be >> able to represent it in XSD. I'm not sure that's a good trade off. >> >> Can some XML expert step up here? :) > >Just don't use XSD. It's wrong to assume that of all schema >languages, this one is in any way special or "official". It's just one >of the many, and a quite poor one at that. As for me, I prefer >Schematron, where such check would be trivial. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > >------------------------------------------------------------------------- >This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >Don't miss this year's exciting event. There's still time to save $100. >Use priority code J8TL2D2. >http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java… >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

3d box crash - patch for 0.46
by John Faith 16 Apr '08

16 Apr '08

Hello, This bug https://bugs.launchpad.net/inkscape/+bug/205659 has a patch attached which solves crashing as soon as the 3d box tool is used on OS X 10.3.9 and OpenBSD. Would it be possible to review this patch and apply to the 0.46 branch? Thanks! , John

3 4

Re: [Inkscape-devel] Extensions (inx) files
by Bob Jamison 16 Apr '08

16 Apr '08

I've seen several things (SOAP for example) that, for data types, just use Schema's own namespaced data types. In fact, the data types are the only part of XSD that I like. :-) bob -----Original Message----- >From: Marcin Floryan <mfloryan@...1877...> >Sent: Apr 16, 2008 9:17 AM >To: Ted Gould <ted@...11...> >Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> >Subject: Re: [Inkscape-devel] Extensions (inx) files > >Ted, > >Things are funny at times. I have just reached a point where I am slightly confused how the XSD should be written (to define parameters) and so I've looked into your XSD and you seem to have been stuck at the same point :-) >There is no neat way to define ><param type="int" ..>int</param> ><param type="float">float</param> >since XSD does not support element typing based on attribute values (fair enough). >So either we have some less strict XSD rules (and relay on further validation in code) or we change that element's name to reflect the type as well (I opt for the latter, but wonder what people here think). > >PS. I suppose this is why you can have <input type="submit" maxlength="12" ...> in XHTML though logically it does not make sense :-) >-- >Marcin Floryan >http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

1 0

XML editor interface
by James Crook 16 Apr '08

16 Apr '08

Hi, I'm one of the developers with the Audacity audio editor project. Our code keeps being pulled towards a kitchen-sink architecture where everything people might ever need gets integrated in (FTP for podcasting, play lists, MIDI-Editor, de-noising tools etc). We're trying to fight back against this trend by more and more moving to 'bridging', where we find ways to bridge to other applications that already do the job. One direction is with XML editing. Our project file that holds the descriptions of the audio clips is an XML format. I'm thinking we should bridge to: http://xml-copy-editor.sourceforge.net/ for display/update. I like the XCE editor, it uses the very powerful Scite component. What I'm wondering is, how tightly integrated is the built in XML editor in Inkscape? Are there a raft of services that XCE/Scite would need to support to have (the option) of bridging to an external editor? Does it even make sense to be looking in this direction, or should I be looking for smaller 'footbridges' rather than bridges with 'motorway traffic'? Any comments and feedback welcome. At the moment Audacity does not integrate any XML editor at all, but I am thinking we will need to as our project structure gets more complex, for the same reasons that Inkscape already does. This is at a very early stage, I'm just looking around and getting impressions. --James.

3 2

Multipage plan
by bulia byak 16 Apr '08

16 Apr '08

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>  <pageSet> <masterPage rendering-order="under"/>  <masterPage rendering-order="over"/>  <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

9 19