- Inkscape Devel - Inkscape Mailman

Writing News
by unknown＠example.com 15 Oct '05

15 Oct '05

Could someone in the know update the wiki with the current new writing procedure? http://wiki.inkscape.org/cgi-bin/wiki.pl?WritingNews Aaron Spike

2 1

zooming bug
by jiho 15 Oct '05

15 Oct '05

Hi list, this file http://jo.irisson.free.fr/dropbox/schema_bilan.svg was completely made in inkscape with version 42-2-2 on mac os X. Then it was edited with latest CVS on linux and after that: - zooming to fit content in window zooms out to 1% - selecting all and zooming to selection produces the same result both on stable or latest cvs inkscape on os x or linux. (NB: the same problem was also remarked in other files, converted from eps to svg with pstoedit such as this one: http://jo.irisson.free.fr/dropbox/sampling.svg it might be that the eps was corrupted in the first place or that pstoedit job wasn't perfect because there are other problems with this file: any new path/tex created is huge, no dashes can be applied to some imported path or to any new path created etc. But I mentioned it in case the zooming problem is the same. Nevertheless, the point is that previous file (schema_bilan.svg) was entirely made in inkscape so there is no incriminating pstoedit or the software which produced the eps in previous case.) in addition, the first file (schema_bilan.svg) does not display properly on os x (stable or cvs) anymore: all shapes are there (selectable), their fill and stroke attributes are still correct but they are not displayed. I know that the zoom has been changed a bit lately. might it be related to this? I submitted a bug to the tracker: [ 1326574 ] maximum zoom out when zooming to fit in window I hope this will be easy to fix. I am naturally ready to test anything you'll need. JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

3 8

zooming bug
by jiho 15 Oct '05

15 Oct '05

sorry I replied only to bulia. Begin forwarded message: > The real problem is the insane bbox. I think this may happen to >> other elements too, for any number of reasons. So perhaps the best >> way >> to address this is to ignore anything which is larger than, say, a >> million px in any dimension. For example scaling by keyboard already >> has the 1 million upper limit. However I'm reluctant to do that, as >> you never know what weird files people would want to edit. This >> arbitrary limit may bite us sometime. >> >> > > what about scaling down or up the objects with "insane" bbox after > issuing a warning/question when the file is opened? if it is a > isolated case in the file (as the one attached in the bug I > submitted) it will suppress the problem and focus the attention of > the user on this (and if he knows about the xml editor he could > delete the incriminated object). if the whole file has insane > transform matrices (like the one to which I provided a link in the > bug report) it will make its modification in inkscape easier. > currently, in the second file, when I add anything it is insanely > scaled (like strokes with 720 px of width) I think because all > objects have transform matrices like this one: > transform="matrix > (2.007003e-3,0.000000,0.000000,-2.007003e-3,-6.079619e-2,1.461081) > > I don't know if anything of this is meaningful but my impression > was that, dealing with vector images, scaling won't be a problem. JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

1 0

gtkmmification update
by unknown＠example.com 15 Oct '05

15 Oct '05

I'm asking purely as a user who, possibly incorectly, thinks that the changes made in gtkmmification will make future progress of Inkscape quicker and easier... I could't help but notice the hubub centered around rwst's recent refactoring. But I confess I don't understand much of what is going on or what significance it has. What is the current status of the gtkmmification? Is there a list of gtkmmification goals notated with those that have been completed? What does it mean that there is a canvas in --new-gui? What does it mean that we need to use Actions? Clue Seeking, Aaron Spike

2 1

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 15 Oct '05

15 Oct '05

> > > > Also the guys are under intense pressure to ship a brand new commercial > > Windows release right now and so have very limited time. Indeed right > > now we have very limited number of developers purely on the open-source > > version. > > Can you tell us a little about the backgrounds/interests of the folks > working on the open source version? I'm looking forward to chatting > with them in the future. :-) Well the guys you may come across are Phil and Gerry both been with Xara since well before our Windows exploits back to Acorn RISC days. Phil was even involved in some Atari ST products we did in historic times. But they've worked on just about everything including Artworks the ARM based (pure assembly language) predecessor to Xara X and Impression our Quark-like DTP package. Both have huge experience across the board. Phil probably has more ownership of the technical architecture than any. Gerry has very broad experience of whole computer and Windows gamut. However neither have that much experience (perhaps none) of Linux as far as I'm aware). Neil our CTO has Unix experience going back - more project manager, but a very good understanding of architectural and OOP things. Er, who else. Luke might post from time to time - he's the main guy working on the Linux port right now (and has more Linux experience than any of us). Others you may come across but probably wont be posting here much. Oh and although I'm CEO I used to program (mostly assembly language, authored the products that the company was built on 25 year ago, e.g. Wordwise a word processor that was very popular in the 80s in the UK) and so understand, in some detail, all the concepts of what we're doing. So we are a very techy orientated organisation. (Maybe that's why we're not bigger than we are because I should be more marketing oriented). Having come from a background where every byte mattered and processors were pathetic, that's perhaps where and why we get this speed / space efficiency thing from. It also means, that as CEO, I don't get or accept any technical BS from my people about what is and is not possible. If they come to me and say "can't be done" I'm always pushing back to ask why, there must be other angles we can take, and usually we find a way. I am also a fanatic about detail, trying to find better more slick ways to do UI and cutting anything that is not necessary. I'm an total believer in the KISS principle, Occam's razor and such approaches. And although over the decades there is not a class of software we've not been involved in, from games to databases, spreadsheets, interpreters and compilers, even hardware design, I'd say that we've been involved in publishing software more than anything - be it word processors, Postscript interpreters (this is where our rendering engine started life 15 years ago), DTP packages and graphics software of all types. So a pretty broad background.

7 6

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 15 Oct '05

15 Oct '05

> From: MenTaLguY [mailto:mental@...3...] > Sent: 14 October 2005 21:49 > > So why doesn't someone do a sort of Ultra-draw wrapper super-API library > > thing that we can both use. i.e. it provide one super-set rendering API > > that itself calls down to XaraDraw, Cairo, Quartz depending on user or > > program preferences. And then we'd both use this ultra-draw and both > > gain the desired benefits. Quartz, Cairo and XaraDraw are similar enough > > to make this not too huge a job I would guess. > > I would be reluctant to introduce yet another new API. I've been > peripherally involved in the Cairo effort, and have learned that good > API design is VERY hard in this area. Well yes, you're right the last thing anyone needs I more APIs, but on the other hand Cairo has a pretty limited feature set (but on the positive side, seems super-clean, very simple and that's worth a great deal.) > However, I suspect XaraDraw doesn't owe its speed so much to the > specific rasterization backend as to a "retained-mode" layer which can > do caching and optimization of drawing calls? Almost a great deal of the speed of Xara X1 and predecessors is the rasterizer backend (but the main object tree is designed around calling this efficiently). In Xtreme we added a bitmap caching layer which can make substantial further speed-up for groups, layers, shadows, feathered stuff, blends, etc, which otherwise an be relatively slow to render. > Cairo pretty much only does rasterization; it provides no retained-mode > layer of its own. There seems a very close correspondence between it and XaraDraw, and Quartz (and GDI+ even). These all are all non-retained rastersization engines. > My own feeling is that it would be most beneficial to take Xara's > retained-mode layer, target it to Cairo, and then write a new Cairo > backend using XaraDraw's lower-level layers (in the long-term, we would > also want to investigate merging what we could of the "XaraDraw" Cairo > backend into Cairo's normal software backend, assuming you folks were > comfortable with relicensing those bits accordingly). Yes I think there's a lot of sense in that approach. Trouble is we might not have a clear, retained-mode layer as you put it. You can see once the source code is provided. The 'viewer' that forms the core of the download we now have is probably close to this. > In case Cairo's generic API proved insufficiently rich for everything > required by Xara, note that Cairo does allow for backend-specific API > extensions. We could simply employ those in the short-term, and it is > likely that many could be incorporated into the generic API over time. Ah, OK, that is useful. Cairo certainly is not rich enough and appears to implement a relatively small percentage of the capabilities of the XaraDraw engine, and is rather less capable than the Quartz PDF engine even. But if it's an extendable API that may be the best way to go. There might be licensing issues, would need to be looked at. > Both Inkscape and Xara could then use Xara's retained-mode layer, and > both could use Cairo underneath while still taking advantage of Xara's > optimized rasterization routines. In the long run all Cairo-based > applications (e.g. all GTK and wxGTK applications) would potentially > benefit, and Xara could benefit from future third-party improvements to > Cairo directly. > > That approach would let us stick with two already well-refined APIs, and > take advantage of the principle that a rising tide lifts all boats. Yep, a lot of merit to that approach. Charles

1 0

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 15 Oct '05

15 Oct '05

> -----Original Message----- > From: bulia byak [mailto:buliabyak@...400...] > Sent: 14 October 2005 21:32 ... > Working on shared libs is a good thing. However, for me personally the > most important thing is the UI. I added a lot of small and > not-so-small UI tweaks to Inkscape, and even though a few years ago I > was a diehard Xara fan, now I perceive Xara as somewhat clumsy > compared to Inkscape. It feels a bit awkward when I use it, I miss > lots of small conveniences of Inkscape. I would love to have an offline conversation with you about what you dislike or find awkward - I feel the same when using Inkscape, in certain areas more than others. But UI is an area I take a great deal of interest in. Of course a huge amount is that you like what you know and know what you like. I know diehard Illustrator users who defend what, to most others, appears a tortuously convoluted way of doing things. They've been through the pain learning it all once and 'sure as hell aint going to learn something else'. > Also Xara misses a few > critical features of Inkscape, most importantly clones. Yep, I agree. Been on the wish list for about 10 years. Always had higher priorities. A great example of a feature that I'd imagine little if any Inkscape code would be relevant or help us. So if we want the feature we'd have to do it from scratch. > It's up to you, but I'm not sure resisting to improvements, even > temporarily, is the best tactic. Everyone can try the complete Xara on > Windows right now, and everyone can get a good idea of what's in most > urgent need for improvement, based on that. Well you're possibly right, and we're never going to turn down improvements if they're dead safe and can be done with delaying things. But the dangers are that a) we de-stabilize the product b) we get distracted implementing new features and thus delay a 1.0 release. I think having a very clear target that is easy to describe and understand is worth a great deal. We've been burned so many times by making a 'relative small change' that turns into a huge job. For example Live Effects, was originally estimated at about 3 months works, no great architectural changes required. 14 months later we had it done to our satisfaction. Charles

1 0

docker.h et al
by Jon A. Cruz 15 Oct '05

15 Oct '05

Oops I saw that docker.h and friends were just removed. :-( They're documented with this page and UML http://wiki.inkscape.org/cgi-bin/wiki.pl?DialogReplacement The main thing is that those are what will allow us to have swatches and such show up in a pane at the bottom of the window with just a minimal amount of coding. Since their use was pruned out just before this, I guess it can wait for 0.43 to go out before putting them back. Once we release, though, we want to get to use those ASAP so we can get the dynamic UI tunable to the kind of thing Bulia wanted.

3 7

Re: [Inkscape-user] imported files
by Jon A. Cruz 15 Oct '05

15 Oct '05

On Oct 14, 2005, at 11:36 AM, bulia byak wrote: > (Jon Cruz: you might be interested, as it was probably your bug; see > http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/src/ > file.cpp?r1=1.140&r2=1.141&sortby=date) Yes. Quite interesting. I'll have to see what we can do to minimize problems for 0.43. If nothing else, the next rev will get things reworked much better, and have more "flatten", "cleanup" and "warn" in regards to linked assets.

1 0

RE:Xara Announcement
by Charles Moir 14 Oct '05

14 Oct '05

Hi everyone, I got a second, so here's some thoughts. Sorry it's so long, but I picked up on a few of the points made in this thread. I apologise for not saying from whom I'm quoting. > I think Cairo is the better horse for the long term. > As the Cairo developers start moving towards hardware acceleration, > comparing them with a piece of software is simply unfair. GPUs today > are impressive, and if Cairo can tap into even a small percentage of > that it'll be crazy. I agree - we'd also like to move towards Cairo, for the simple reason it's clearly becoming a Linux standard in the way Quartz is on the Mac and it will be hardware accelerated. No matter how much faster our rendering is now, we'll not compete against hardware. But we also want to support Quartz on the Mac, Avalon (or whatever is called this week) on Windows because they are the native vector rendering engines that are also hardware accelerated. So our medium term plan for Xara was to have user switchable rendering engines. XaraDraw, Quartz, Cairo, or whatever. This would also limit the feature set to that supported by the corresponding engine. So, for example, I think only XaraDraw and Quartz can support grad transparencies and so selecting Cairo would disable that feature. But you'll be free to take our rendering engine once we make it open-source and retro-fit it into Inkscape if you wish. Should make Inkscape go a lot faster. > I've invited Charles to encourage one of his > engineers, testers, or sysadmins to join the list; if they're on, I hope > they'll jump in and say hi I think we have one or two devs lurking here, maybe others. Neil Howe, our CTO, Phil Martin our chief techy on Xara and responsible for most of the architectural stuff. Gerry and Like may also be lurking, and appear from time to time. But as Bruce says changing a company culture to be open in way you guys are is difficult. We all have to be careful because we represent a commercial company that can get sued, and because we have paying customers. Also the guys are under intense pressure to ship a brand new commercial Windows release right now and so have very limited time. Indeed right now we have very limited number of developers purely on the open-source version. Hopefully in a week or two that will improve. But they have very limited time to respond to all the posting that they might be inclined to. > As a graphics software only company they are > directly in competition with Inkscape - thus, all this code merging talk > sounds strange (I don't see Trolltech trying to merge their code with > Gtk or vice-versa - interops yes, merging no). Most successful > commercial companies in the open source community have made it thru > services: part add-ons, part support, part operations, part packaging, > part data warehousing, etc - I think to be viewed as an open source > friendly company Xara needs to operate in terms of being a graphic > design services company utilizing community software as a base - but > they haven't exactly said what they are thinking along these lines... Well that is what we hope. We hope to continue selling commercial versions, especially into our existing Windows market because there will also be a part of the market that wants customer support, those licensed elements that can't be part of an open-source product, such as Pantone, our PDF exporter includes licensed libraries, the Live Effect plug-ins, even mundane things like boxed versions, CDs and printed manuals. If there's demand we'll sell those extras into the Linux community as well. Having commercial versions of the product is not a bad thing, I believe it helps an open-source project. There's some info about this on our FAQ http://www.xaraxtreme.org/faqs.html > Well, after reading the e-mail you've forwarded, I'm not optimistic. > The reason being that they still seem focused on being in control. Now > I don't think they should release a totally random project, but if they > are going to never give an outside developer access to their version > control, the barrier for contribution is too high. We will give outsider developers access to svn, but we're not going to let any old hacker one off the street have write access without at least some checks. I think it was Bryce who mentioned you guys also have a quality control standards, as do all successful open-source projects. In the end it just comes down to trust and if a developer shows he can be trusted we'll provide greater access all the way to complete un-vetted write access. I don't think we'll be any different to other OSS projects. But we are in control of our official Xara branded tree - doesn't stop anyone building their own version with their own additions - just as, presumably, anyone can take Inkscape and do the same (you did it to Sodipodi didn't you?). It's GPL - people have the freedom to do what they want with our code. > Well, I'd say that we could steal code from them, but it is unlikely > that they'd want ours -- for the simple reason that it seems they need > copyright assignment. No we do not want copyright assignment. We think that's unfair as it take rights away from the author. More details on our FAQ under the licensing section, which has been updated recently. http://www.xaraxtreme.org/faqs.html But our best idea is that is that if people want a patch incorporated into the main Xara release that they dual license it GPL and BSD, they keep all their rights, and we, or anyone else, can use it in a commercial version. Open to suggestions as to how else we make this possible, but in order for any OSS project to really succeed in the wider commercial world I think having a commercially supported version is a good thing. If people choose to say want Pantone they should be able to pay for it. > I don't think even most current developers > could claim copyright to large sections on Inkscape. I wouldn't even > want to try and figure out all the copyright issues in Inkscape. Ah well that could be a more serious issue. We can't, any more than anyone can really, accept contributions if the copyright is not clear. Too dangerous. > In the long term, it's a bit less rosy. Only a few bits of code are > easy to borrow from program to program; most are difficult to > impossible. Merging the two programs is not too realistic. Living side > by side is more probable, but that means competition. Competition is > tough. There's only so many Linux people interested in vector > graphics, and they will need to decide which project to contribute to. > Few if any people will be able to learn both codebases to contribute > to both. This will hurt us (developers drain) and this will hurt Xara > ("hey, we went open source, why so few contributors?"). I think this is the core point, and very well put. It's hugely difficult to see how this can be done. The best I can suggest (and I'm not the first to suggest this) is that we find ways to create shared libraries, tools, palettes, add-ons, whatever. Here's an idea, just off the top of my head. Inkscape wants to move to Cairo, so do we. We also want to continue using XaraDraw for its speed and greater range of rendering types, especially in the case there is no hardware assisted rendering, so it seems do some of you guys. On the Mac we (and you) should be using Quartz because this is about to become hardware accelerated as well. They all have varying capabilities, but are based on a similar PDF 1.4 style rendering model. So why doesn't someone do a sort of Ultra-draw wrapper super-API library thing that we can both use. i.e. it provide one super-set rendering API that itself calls down to XaraDraw, Cairo, Quartz depending on user or program preferences. And then we'd both use this ultra-draw and both gain the desired benefits. Quartz, Cairo and XaraDraw are similar enough to make this not too huge a job I would guess. And perhaps that's the type of approach that could be used going forward. Eric's Uber-converter is a similar thing. We both get to benefit from that. Why do we want to do this? Well the easiest route is that we just live side by side competing, more or less. You steal our code, we steal yours. A lot of time is spent re-implementing features one way or another. Both sides will probably benefit to some extent, but is it the way to really move forward? The bigger picture is that Adobe just bought Macromedia because they are concerned, rightly, that Microsoft are going after them. So they combine number 1 and 2 to stand a better chance against Microsoft. Meanwhile if we're not careful Xara / Inkscape are like two little ants spending their tiny resources competing against each other - irrelevant and insignificant to Adobe / Microsoft *and* the majority of potential users out there. I sort of would hope combining that benefits and efficiencies of "the open-source way", with the best of what you've got and the best of what we've got and then we might be a credible realistic alternative to the big-guys. And that's not just the Linux market but the much wider market. Oh and while vector drawing might have been regarded as relatively niche in the past I don't think it should be. The whole world is moving to be vector based (all three operating systems are on the verge of using vector based UIs). Personally I don't believe there should be such a separate, and artificial separation between bitmap and vector graphics programs. Vector graphics should be the prime, first class citizen, of computer graphics. It should be the first graphics program that people buy and want to use. Rich vector graphics is inherently more powerful and flexible. Just think about the scriptable opportunities in this space. (Our Webstyle template based product takes this approach. It takes professionally designed vector template graphics and allows dummy-users (i.e. those with little design skill - and that includes me and most that I know) to customize the graphics, colors, wording, scale and in a vector way. It's perfect for creating vector UI components, such as buttons, icons etc. A hugely powerful concepts that opens Vector graphics benefits for the rest of us. We're only touching the surface on that side. Anyway having said all that, in the short term, possibly medium term even, we are going to be living side-by-side because our gaol is to get the whole of Xara Xtreme ported and working as is, and we're trying to resist making improvements, taking anyone's features. That's partly because we think it's in everyone's interest to have a compete product working ASAP, but also because only once we've got the whole lot working, can outsiders sit back and take a view on what's right and what's wrong. Then we can all sit back and see how bets to combine forces. I suppose I'd sum it up that the result should / could be greater than the sum of the parts. That way we could all benefit, the open-source way benefits, Linux benefits because it can more readily offer mass-market and professional graphics solutions to Windows users. We all benefit because there are simply more developer bodies working for the same gaols of creating better graphics software. Charles

6 11