- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Guillermo Espertino 24 Oct '09

24 Oct '09

> From: Thorsten Wilms <t_w_@...123...> > As this issue affects all kinds of graphic and sound applications, I > have been thinking about a solution on another level. This would require > linking to objects via IDs, so you can move stuff around without > breaking links. Dependency tracking and automatic bundling once your > stuff leaves your system. I strongly agree. Dependency tracking would be the perfect solution for novice and advanced users. I think that it should be the ultimate goal in image link management, but meanwhile we should implement some minor improvements (like some of the proposed in my blueprint) for making it nicer to work with images in Inkscape. The good thing is that these improvements are compatible with that ideal solution, so it wouldn't be wasted time to fix some annoyances of the image properties dialog now :-) > From: Krzysztof Kosi?ski <tweenk.pl@...400...> > I don't want just to flip the default, I want to change the behavior > of the existing commands (import and paste) so that it follows > intuition, and add new commands that explicitly expose the link > behavior (see below). > Note that the current behavior is wrong on many levels: > - For pasting, we create a PNG file in the same directory as the > edited file with a crazy name like > inkscape_pasted_image_20091023_144102.png ?and link it. > - For importing via drag-and-drop, we embed. > - For importing via the dialog, we make a link. > The defaults are inconsistent, and the paste case is completely bogus > because 1. It attempts to write to the directory where the doc is > located, which may not be permitted (the directory and the doc might > be read-only); 2. It creates a crazy filename; 3. It breaks when the > user relocates the document. More importantly we cannot create links > to things that might not even be in a file (like pasting pixels from > GIMP). > Therefore we should default to embedding on paste and DnD, and have 2 > import commands: Import, which embeds, and Link Image, which creates a > link. Note that this will make Import behavior consistent across all > formats. When importing SVG or other vector formats, we never create a > link. > Serious artist know they want an image link, and most importantly know > the difference between an embedded image and a link, so they will > choose the correct option (insert image link). Newbie users do not > know about this distinction. They just want to put images in the > document, and expect them to stay there when they move the document to > another folder or remove the original images. > Krzysztof: Actually, every image is LINKED. There are no inconsistencies at all. You say importing via drag and drop embeds, and that's wrong. The naming and location of pasted files can be discussed, of course, but you seem to be proposing to change the behavior of something that is common in every program that works with external data (vectorial illustration, page layout, even audio and video editors) because it isn't "intuitive" for new users who didn't read the documentation? It wouldn't be a problem if it is harmless, but changing it brings a lot of problems, as JonCruz pointed out. In my honest oppinion, a switch in the import dialog, a good method for dependency tracking and solving and a better image properties dialog would be the best solution. Dumbing down the program because a part of its users are new to it and didn't read the documentation is shooting to your own foot. An SVG file, as it names stands for, stores VECTOR graphics. If it allows to embed bitmap images, it is an option for cases when it's needed. Links are the proper way to include images, and the most convenient most of the times. Also you're assuming that an SVG file is something that a regular user will send to his friend via email, like a jpeg. Inkscape is a vector illustration program. Its files are comparable to CDR or AI files, that also work with links and embedded images. So I guess it's safe to say that the target public for an application like inkscape isn't a complete newbie that only used MS Paint. By the way, GIMP started to change its focus since a clear target user was defined, and this kind of discussions (if the program is or isn't friendly for the unexperienced users) kinda stopped. Does inkscape have a clear target user group defined? > I don't understand. How do you imagine making an image external > without saving it? :) Re-linking it to the original bitmap file. If you imported it once, you may still have the original file in your disk. If you simply save it again, you'll end up with the original and the "externalized" image in your disk. That's confusing and breaks apart you project's organization. Gez.

7 7

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Krzysztof Kosiński 23 Oct '09

23 Oct '09

(unintended private email, again... -_-) W dniu 23 października 2009 21:37 użytkownik Steren <steren.giannini@...400...> napisał: > 2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...> >> >> When you paste an image into a Word / ODT >> file, it is not a link to that file on your hard disk. > > Actually, OpenOffice.org is sometimes using Links, I'm not an expert but I > used it in the past. > Try out with OpenOffice.org : > - Create a document > - Insert > Picture > From File > - in the dialog, select an image and tick "Link", then Open > A dialogpops-up asking you If you are sure you want to link it. See capture > attached to this email. You can choose to ask again when you will be linking > your next image or you can say "I know what I am doing" by ticking > something. That's the point - when you are making a link, you are explicitly saying this. The default is to embed, and to get links you have to explicitly want them. I don't want to remove the possibility of creating links. I just want to make embedding the default, so there is less confusion by broken documents, and provide different explicit commands for linking. > Then you can edit these Links with Edit > Links. This opens a window that > inspired me for the "Image Links Manager" proposal. > > So this leads us to say that we are not the only one having issues for an > understandable-by-everyone linking strategy. The OpenOffice strategy is reasonable. You only end up with broken documents if you explicitly want it. The default is to embed, but you can create a link if you want. We need to recognise that the concept of creating a link is different from the concept of pasting or inserting, and should be given different commands. Regards, Krzysztof.

1 0

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Krzysztof Kosiński 23 Oct '09

23 Oct '09

(Sorry, resending this to list - the Gmail interface defaults to a private reply and I keep making the mistake) 2009/10/23 Jon A. Cruz <jon@...18...>: > A simplistic approach of a solution is to merely switch the default. > However what generally happens in these cases (and specifically in > this one) is that you are seeing bug reports from those who don't like > the current behavior, but you see no feedback at all from those who > are happy with the current behavior. I don't want just to flip the default, I want to change the behavior of the existing commands (import and paste) so that it follows intuition, and add new commands that explicitly expose the link behavior (see below). > BTW, we have looked at this issue for some time, and there are severe > consequences to making embed the default. We definitely need to > remember to keep those in mind as we make changes. What are those issues? Note that the current behavior is wrong on many levels: - For pasting, we create a PNG file in the same directory as the edited file with a crazy name like inkscape_pasted_image_20091023_144102.png and link it. - For importing via drag-and-drop, we embed. - For importing via the dialog, we make a link. The defaults are inconsistent, and the paste case is completely bogus because 1. It attempts to write to the directory where the doc is located, which may not be permitted (the directory and the doc might be read-only); 2. It creates a crazy filename; 3. It breaks when the user relocates the document. More importantly we cannot create links to things that might not even be in a file (like pasting pixels from GIMP). Therefore we should default to embedding on paste and DnD, and have 2 import commands: Import, which embeds, and Link Image, which creates a link. Note that this will make Import behavior consistent across all formats. When importing SVG or other vector formats, we never create a link. Regards, Krzysztof

3 3

Specification: Improved image properties dialog (0.48)
by Guillermo Espertino 23 Oct '09

23 Oct '09

Hi: I created a blueprint based on some ideas discussed in https://bugs.launchpad.net/inkscape/+bug/172162 It's a specification of an improved image properties dialog that (hopefully) would tackle some annoying aspects of image links management in inkscape. I've received valuable ideas from ~suv and Steren Giannini and the specification is starting to look very good, so I'd like to propose it as a feature for the next version of Inkscape. The blueprint: https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enh… I'd really love to know your oppinions about it, and get as many suggestions, critics, ideas or questions you might come up with to make it better. Gez.

8 10

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Guillermo Espertino 23 Oct '09

23 Oct '09

About image links being confusing for users... Most of the vectorial illustration programas I know use links. Designers at least are pretty used to the images being linked. Anyway, those other programas also include an option on import to link or embed images, so I agree about adding that feature. Where I do not agree is about making embed default. Embedding is handy in a lot of cases and would help newbies, but a serious artists or designers would want to have those images linked, because usually they have to be edited. Keep in mind that a couple of images embedded won't be a problem, but dozens in high resolution can take the svg size too high. There's also a problem: As far as I know, it's impossible atm to convert an embedded image to a linked image without saving it. So if you imported it and it was embedded, when you extract it you'll have two files in your disk. Of course we can (and should) modify the specification to allow re-linking to an existing file as an option along with extract the embedded image. But I think that we should avoid making embedded images default until we can provide that option. And even in that case, I think we should place a preference for changing that default. Gez

2 1

vertical toolbars
by Albert Cardona 23 Oct '09

23 Oct '09

Hi all, I've found bug/wishlist https://bugs.launchpad.net/inkscape/+bug/171663 ... which suggests that work is in progress to allow vertical toolbars. In a MacBookPro, which has very low screen height, one has to disable several toolbars to enlarge the area dedicated to the drawing enoug that it can be used nicely. Any reports on whether this feature is progressing? Thanks for any info. Albert -- Albert Cardona http://albert.rierol.net

3 2

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Guillermo Espertino 23 Oct '09

23 Oct '09

I added Rok's suggestion to the specification. About its implementation, I agree with Steren's idea: let's use a button for matching original aspect ratio keeping the larger dimension and modifying the smaller. That would be the very useful to solve a very common situation: You imported an image, then you want to crop it (for instance, you have a sponsor logo with a lot of transparent space around and you want to get rid of that empty space and leave the logo only). Thanks for the feedback. Gez. p.s.: Steren, It'd be great if you could mentor a team of students to work on this feature. It can be made in different stages and it doesn't look too complicated to be finished in a short term.

3 4

Test suite
by unknown＠example.com 22 Oct '09

22 Oct '09

Hi all, Could someone have a look at the testsuite and reprogram it such that (at least when perceptualdiff is used) the results that are marked 'new' are marked 'fail' instead? This is much clearer, and cleans up the daily checks at http://auriga.mine.nu/inkscape/. Thank you very very much! I love the testsuite, but I don't want to delve in to the code and change things myself. Thanks a bunch, Johan

3 6

Patch for Embed Image extension
by Nicolas Dufour 21 Oct '09

21 Oct '09

Hi, I've posted a patch for the following bug: [Bug #386069] Embed extension fails https://bugs.launchpad.net/inkscape/+bug/386069 It fixes a win32 issue when the path or filename has an accent, or any non us ascii character (two bytes encoded in utf-8) . Patch tested on Ubuntu 9.04, OS X, Windows XP and Vista. Please check and commit, or just tell me if you think it's too late for 0.47. Regards. -- Nicolas

1 0

0.47 status
by Joshua A. Andler 21 Oct '09

21 Oct '09

So, We have one blocker left. Apparently some preferences need to be migrated over from 0.46. JonCruz was working on this, but, he just started a new job and doesn't really have the time necessary to finish it. At this point, we need to figure out a list of preferences to see if this really is a blocker issue or what. It makes no sense to hold up the release if no one is going to fix the last problem (we have tons of other issues that we're willing to release with after all). I know of the "recent documents" being one thing that doesn't carry over. What else people? Cheers, Josh

4 3