- Inkscape Devel - Inkscape Mailman

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

16 Oct '05

> From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel- > admin(a)lists.sourceforge.net] On Behalf Of Ted Gould > Sent: 16 October 2005 05:46 .. > ... but I think the single biggest > thing Inkscape could do to help integration is notice changes in bitmap > files. So, I link in a JPEG, and if I change that file in any other > application Inkscape notices and updates instantaneously. I think this > should be possible with further GNOME-VFS integration. Then, the > command is to just to open GIMP on the file. Yes, great. Something really simple like that. I'd support that (in Xara or Inkscape). But we'd like to go further (and part of the reason we do it the way we do with a private API) so that we pass raw (or PNG) bitmaps to and fro, to avoid the JPEG lossy cycle. We also keep the photo edit list associated with the bitmap, so you can edit it in future and alter (or undo) the previous edits you did to the bitmap. That requires a bitmap editor to remember the lists of edits, and keep a master around. But for a basic simple, still very useful feature, just watching for file changes would seem to do the trick.

1 0

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

16 Oct '05

> Perhaps it would be a good idea to come to the Libre Graphics Meeting > 2006 in Lyon, to define your position in the OpenSource Community. > http://wiki.gimp.org/gimp/LibreGraphicsMeeting > > Tobias All ready to put in my diary, only to discover I've already booked a vacation at that time, which is a real pain. I'll see if we can send some other representative. We should be there I agree. Charles

1 0

Proposed changes to Keyboard shortcuts
by Alan Horkan 16 Oct '05

16 Oct '05

=== Patch first === The Patch https://sourceforge.net/tracker/download.php?group_id=93438&atid=604308&fil… The Patch assigns F1 to Help, Keys and moves some other keys around mapping them to ones used by Xara. The tracker request https://sourceforge.net/tracker/index.php?func=detail&aid=1326159&group_id=… === Ask questions later === (And these are just for starters) Inkscape has keybindings for almost everything which makes it very hard to change anything without having consequences, it is worse than a Rubiks cube. I tried to make changes as non invasive as possible but it was difficult. I may not use Inkscape every day but it is precisely for that reason I find it so important to try and get inkscape to use Keybindings which resemble those used by other applications. F1 for Help was one of the first and most important keybindings I learnt (and hitting Esc like a madman anytime something went wrong was probably the second). It is not just about F1 but it seems like a place to start. Beginners and new users face a much steeper learning curve if Inkscape uses different conventions from other applications. I realise an changes will be uncomfortable for existing users but no one ever claimed Inkscape was ready for stable 1.0 and not going to change things around. Experienced users should know inkscape will be subject to changes and they are exactly the people best able to adapt to changes and if we are lucky they might even like the changes because they make inkscape a little more like Xara. The long term solution is of course to have fully switchable keyboard profiles. That doesn't change the need for good defaults and I hope by trying out these ideas (even if they need to be reverted before the next release) it will encourage people who do not like it to come up with better suggestions rather than blocking changes. Using F1 for help is a convention used by Windows, Mac OS X, Gnome, KDE. The changes make Inkscape more like Xara [1] in particular. Precedent is significant but if we at least try out the change we can get a better idea of the impact. If people really hate the change and it has to be reverted it will at least help show the need for different keyboard shortcut profiles sooner rather than later. There are many more things which could be said about this but please lets try it and come up with ways to do it better rather than not doing it at all. (bulia mentioned his displeasure at the choice of Zoom key which I expect could be addressed parallel to this by providing other Zoom functionality but I think that may need seperate discussion.) Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ [1] Keyboard Shortcuts for Xara http://www.xaraxone.com/html/tip_of_the_week_4.html http://www.xaraxone.com/assets/images/tip_30.gif (I have a text reference of the Xara shortcuts too somwhere, if anyone has a reference for Corel I'd appreciate it too.)

6 17

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