[NEW] Very simple fix for the image embedding problem
Hello
I wondered for some time how to add an "embed" checkbox to the import dialog, but it wasn't necessary - I used the extension parameters feature.
I fixed the embedding of images in the following way: 1. If a bitmap file is imported, a dialog appears that asks the user whether to link. (Same when opening a bitmap image.) 2. When a bitmap file URI is dragged over Inkscape's window, a dialog appears as in 1. 3. When pixel data is dragged over Inkscape's window, it is embedded an no dialog is shown. 4. When a bitmap file URI is pasted, nothing happens (for now) - that's because the clipboard doesn't support URI lists yet. 5. When pixel data is pasted, it is embedded as in 3.
As a bonus, all bitmap import should now use the same code path.
Regards, Krzysztof
On Mar 4, 2010, at 3:35 PM, Krzysztof Kosiński wrote:
Hello
I wondered for some time how to add an "embed" checkbox to the import dialog, but it wasn't necessary - I used the extension parameters feature.
I fixed the embedding of images in the following way:
Thanks for working on this. Did you coordinate you effort with the team of students working on this for Uni?
Hi, Thanks for the work Krzysztof.
As Jon mentionned, this is the kind of thing the students from Centrale Lyon have to explore during their work on image management (specifications are here: https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enha... ). But don't worry everything is fine. Your work is very welcomed :)
I asked them today to better communicate with me and the list+wiki concerning what they intend to do and what they have done. I met them a month ago chen they just started to explore the code.
Cheers, Steren
2010/3/5 Krzysztof Kosiński <tweenk.pl@...400...>
Hello
I wondered for some time how to add an "embed" checkbox to the import dialog, but it wasn't necessary - I used the extension parameters feature.
I fixed the embedding of images in the following way:
- If a bitmap file is imported, a dialog appears that asks the user
whether to link. (Same when opening a bitmap image.) 2. When a bitmap file URI is dragged over Inkscape's window, a dialog appears as in 1. 3. When pixel data is dragged over Inkscape's window, it is embedded an no dialog is shown. 4. When a bitmap file URI is pasted, nothing happens (for now) - that's because the clipboard doesn't support URI lists yet. 5. When pixel data is pasted, it is embedded as in 3.
As a bonus, all bitmap import should now use the same code path.
Regards, Krzysztof
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mar 5, 2010, at 7:56 AM, Steren wrote:
Hi, Thanks for the work Krzysztof.
As Jon mentionned, this is the kind of thing the students from Centrale Lyon have to explore during their work on image management (specifications are here: https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enha... ). But don't worry everything is fine. Your work is very welcomed :)
I asked them today to better communicate with me and the list+wiki concerning what they intend to do and what they have done. I met them a month ago chen they just started to explore the code.
Thanks.
Probably the main thing is to make sure we keep good communication. I'd asked a few people to give feedback so we can organize things to be more helpful. Krzysztof did a good pass of adding info to our wiki on this. Since we've had nothing else major show up, I'll need to do the reconciliation pass on things.
Oh, and although there has not been much new information directly from the Inkscape side, other open source projects under the CREATE banner have started work on coordinating resources and assets. That will have some direct impact on this feature.
W dniu 5 marca 2010 16:56 użytkownik Steren <steren.giannini@...400...> napisał:
Hi, Thanks for the work Krzysztof. As Jon mentionned, this is the kind of thing the students from Centrale Lyon have to explore during their work on image management (specifications are here: https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enha...). But don't worry everything is fine. Your work is very welcomed :) I asked them today to better communicate with me and the list+wiki concerning what they intend to do and what they have done. I met them a month ago chen they just started to explore the code. Cheers, Steren
There's still a lot to do w.r.t. image links, as well as other linked resources. For example linked SVG images are now rendered as bitmaps. They should be rendered as vectors.
I added some comments to the image properties blueprint. The main disagreement I have is with the Embedded / Linked radio buttons. This cannot be a radio button, because clicking on "Linked" has to bring up a file browser, and doing so in response to a radio button change is very bad. A radio button would be better for the choice between an absolute and relative link.
Regards, Krzysztof
On Mar 5, 2010, at 11:38 AM, Krzysztof Kosiński wrote:
I added some comments to the image properties blueprint.
Thanks. It's been quite a while since I've looked it over, and might not have actually edited anything there yet.
The main disagreement I have is with the Embedded / Linked radio buttons. This cannot be a radio button, because clicking on "Linked" has to bring up a file browser, and doing so in response to a radio button change is very bad.
Eeek!
Yes, it definitely sounds like it needs some "UI love" and review it with a hard usability viewpoint.
A radio button would be better for the choice between an absolute and relative link.
EEEEK!!!
Absolute links are quite troublesome, and were one of the worst things from our Sodipodi legacy. We'll need to seriously think before allowing them in.
On Saturday 06 March 2010 04:01:10 Jon Cruz wrote:
On Mar 5, 2010, at 11:38 AM, Krzysztof Kosiński wrote:
A radio button would be better for the choice between an absolute and relative link.
EEEEK!!!
Absolute links are quite troublesome, and were one of the worst things from our Sodipodi legacy. We'll need to seriously think before allowing them in.
Just a question: do we allow e.g. http url there?
Regards, Martin Sucha
2010/3/6 Jon Cruz <jon@...18...>:
A radio button would be better for the choice between an absolute and relative link.
EEEEK!!!
Absolute links are quite troublesome, and were one of the worst things from our Sodipodi legacy. We'll need to seriously think before allowing them in.
I think absolute links should be allowed, but relative links be the default. Absolute links are useful when you have a large shared image that you need to reuse in several files in different folders, like a company logo.
Regards, Krzysztof
On Mar 6, 2010, at 10:37 AM, Krzysztof Kosiński wrote:
2010/3/6 Jon Cruz <jon@...18...>:
A radio button would be better for the choice between an absolute and relative link.
EEEEK!!!
Absolute links are quite troublesome, and were one of the worst things from our Sodipodi legacy. We'll need to seriously think before allowing them in.
I think absolute links should be allowed, but relative links be the default. Absolute links are useful when you have a large shared image that you need to reuse in several files in different folders, like a company logo.
(smart phone wasn't too smart with webmail. Trying to reconstruct what I attempted earlier)
Exactly. You've hit right on the main first use case we have to address. That's probably a main area we need to think of.
For these situations, contents on a web page should not include the "http://..." part in their links. Relative links would often be good too, but sometimes absolute will work out better in practice. So, given that the links shouldn't have "http:://..." in them and that it is almost impossible to replicate such absolute locations on a designer's local computer anyway, simply allowing absolute links won't solve things.
However... even if one were to have full URLs in the links, there would be a good chance that the final target assets might not even be at the final location. It would be quite common for a designer to work with things in some staging area before they get pushed to live locations.
There are other issues too. I'll try to rough out a summary in a bit.
So the main thing here is probably that you've identified the first problem area we have to be sure to cover. That's good and we should make sure we follow up on this point.
If inkscape is to support http linked images, it also needs to have proxy support.
-Rob A>
On 3/6/10, Jon Cruz <jon@...18...> wrote:
On Mar 6, 2010, at 10:37 AM, Krzysztof Kosiński wrote:
2010/3/6 Jon Cruz <jon@...18...>:
A radio button would be better for the choice between an absolute and relative link.
EEEEK!!!
Absolute links are quite troublesome, and were one of the worst things from our Sodipodi legacy. We'll need to seriously think before allowing them in.
I think absolute links should be allowed, but relative links be the default. Absolute links are useful when you have a large shared image that you need to reuse in several files in different folders, like a company logo.
(smart phone wasn't too smart with webmail. Trying to reconstruct what I attempted earlier)
Exactly. You've hit right on the main first use case we have to address. That's probably a main area we need to think of.
For these situations, contents on a web page should not include the "http://..." part in their links. Relative links would often be good too, but sometimes absolute will work out better in practice. So, given that the links shouldn't have "http:://..." in them and that it is almost impossible to replicate such absolute locations on a designer's local computer anyway, simply allowing absolute links won't solve things.
However... even if one were to have full URLs in the links, there would be a good chance that the final target assets might not even be at the final location. It would be quite common for a designer to work with things in some staging area before they get pushed to live locations.
There are other issues too. I'll try to rough out a summary in a bit.
So the main thing here is probably that you've identified the first problem area we have to be sure to cover. That's good and we should make sure we follow up on this point.
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Don't know about socks, but at least basic http proxy is necessary for many corporate users (and a few ISP's, too)
-Rob A.
On Sun, Mar 7, 2010 at 5:42 PM, Jon Cruz <jon@...18...> wrote:
On Mar 7, 2010, at 2:32 PM, Rob Antonishen wrote:
If inkscape is to support http linked images, it also needs to have proxy support.
You would probably have to define exactly what you mean by "proxy support". Does that include SOCKS, for instance?
I'd also be worried that allowing http references would enable things like pixel tagging, etc. that could be considered a privacy violation. (I.e. Download a svg file from openclipart that has an embedded linked tracking URL)
-Rob A>
On 3/7/10, Jon Cruz <jon@...18...> wrote:
On Mar 7, 2010, at 2:55 PM, Rob Antonishen wrote:
Don't know about socks, but at least basic http proxy is necessary for many corporate users (and a few ISP's, too)
Yes. Which is one of the more complicated reasons to avoid supporting direct HTTP links in Inkscape itself.
On Mar 7, 2010, at 3:08 PM, Rob Antonishen wrote:
I'd also be worried that allowing http references would enable things like pixel tagging, etc. that could be considered a privacy violation. (I.e. Download a svg file from openclipart that has an embedded linked tracking URL)
Bingo!!!!
Yet another issue identified and raised. Buy that man a cookie!
On Monday 08 March 2010 00:08:34 Rob Antonishen wrote:
I'd also be worried that allowing http references would enable things like pixel tagging, etc. that could be considered a privacy violation. (I.e. Download a svg file from openclipart that has an embedded linked tracking URL)
-Rob A>
Obviously, downloading remote resources without user consent is bad.
I was asking whether we allow http urls there because it has implications for the UI.
Please consider following: You open existing svg file that contains remote image url, then open image properties. Either we need to disable(as in display in grey) the whole absolute/relative/embed thing or upon using, display a message to the user explaining they can use this only with local urls. What is your opinion on this?
Another thing to consider is what to do if document has set xml:base attribute.
Regards, Martin Sucha
participants (6)
-
unknown＠example.com -
Jon Cruz -
Krzysztof Kosiński -
Martin Sucha -
Rob Antonishen -
Steren