October 2005 - Inkscape Devel

Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

On Tue, Oct 11, 2005 at 08:22:39PM -0300, bulia byak wrote: > > Another focus of Xara is on bitmap manipulation. They have a built-in > > Picture Editor, something like a primitive Photoshop. I think it's > > safe to bet Inkscape will never have such a thing - why do it if we > > can just call Gimp instead. > Well, depends what you mean by "have such a thing": calling gimp code > would count as having such a thing; though currently we don't do that > at all to my knowledge, and we certainly don't currently make it easy > to edit embedded bitmaps, or have gimp layers implemented as separate > <image/>s, or allow other vector objects to be visible when editing a > bitmap. > > pjrm. This point reminds of another area we could cooperate. We do have an integrated bitmap / photo editor, because in principle I don't believe you can or should separate the two worlds. Real users want to mix photos and vector artwork, and so it's simply more convenient to be able to do this directly from within your vector editor. (And Microsoft Expression will be majoring on this point - integrated bitmap and vector editing, indeed the only significant change MS have made to Expression they bought, is adding a fully integrated bitmap editor) So in Xara X we added an API to call an external photo editor, so that you could double click a photo, (or a bitmap fill) edit your picture, close the window and the edited result is passed back. The theory was that we could use any external editor and were not going to make it specifically the Xara Picture Editor. So in principle this is exactly like you guys calling out to GIMP. But our Xara <-> Picture Editor API sucks, partly because it's very COM based and partly because it's become very specific to our implementation of the photo editor. Worse, our Picture Editor component is going to be an absolute dog to port to Linux because unlike Xara X, it was never designed to be the slightest bit platform portable. GDI+ code everywhere, transparent fading, rounded dialogs, the lot. This remains a major potential stumbling block for the port down the road (it will be the last component we do). So we should also be changing our API to be more general purpose. So the user can configure their favourite photo editor to be called when they want to edit a photo. So, if this is a feature that you guys are thinking of adding to Inkscape, lets have a common API to call external photo editors. Then we can be compatible - we can both use and call Photo editors in a compatible way. What's more this provides an added incentive for the various photo editors out there to support this API and so greatly increase the interop and choice for all users. I might be talking b**ls here, because for all I know Linux already has an open, common API to pass photos to and from the various picture editors. But it seems another area where we could both possibly develop a feature in parallel, but both benefit equally from it. Or is this rubbish?

4 3

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 15 Oct '05

15 Oct '05

> > I might be talking b**ls here, because for all I know Linux already has > > an open, common API to pass photos to and from the various picture > > editors.... > > I don't know of anything *specifically* for that. > > However, there is an API that might be relevant here, with added benefits. > It's a network protocol, primarily for 3D graphics collaboration, called > "Verse": > > http://www.blender.org/modules/verse/ > > Performance could be an issue for large bitmaps, since it's a network > protocol, but perhaps an optimised version could be used locally. This is interesting and possibly suitable. Might be more suitable as an API to interface to 3D apps (which is another area altogether - Illustrator and Corel have had good 3D capabilities for a while). Charles

2 1

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