trunk no longer always embeds when pasting bitmap from clipboard

[su_v]

Inkscape 0.48+devel r10627 on Mac OS X 10.5.8 (i386)

Follow-up to bug #211607:
«Pasted pixel data is embedded and no external file is created.»
<https://bugs.launchpad.net/inkscape/+bug/211607/comments/33>
«Bitmaps are now always embedded when pixel data is pasted
 or dragged into Inkscape's window»
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Improved_bitmap_image_import>

Images pasted from the clipboard in current trunk are no longer always embedded: they now appear to follow the settings last used when importing a bitmap image via 'File > Import...'. IMHO these two actions are intended to use independent settings so that users can rely on having temporary images from the clipboard always embedded in the file (and e.g. not lost after the next reboot because they link to an image file in $TMP).

Steps to reproduce:
1) quit Inkscape, rename/move preferences file
2) open inkscape with new document
3) paste image from clipboard -> embedded
4) import bitmap image (PNG) via 'File > Import' and choose '[x] Link'
5) paste image from clipboard -> linked

As far as I could test with archived revisions, the regression was introduced for 'System default' (en_US) UI language between r10481 (works as expected) and r10485 (images are linked if last imported bitmap image of the same file format was linked). The setting (embed/link) is stored in the preferences file for each file format separately: 'org.inkscape.input.gdkpixbuf.*.link').

Most likely introduced with the "minor UI fix" in r10484:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10484>

The same issue already occurred in earlier revisions for a few other UI languages which - as far as I could reproduce it - at that time seemed to use translated strings in the 'GDK pixbuf Input' dialog (IIRC French, Russian, Dutch and maybe others).

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 10614.

[jazzynico (jazzynico)]

It can also be reproduced with 0.48.1 and 0.48.2, on Windows XP.
I'll try with old trunk revisions later, but I'm almost sure there's no link between the issue and the changes in 10484 (only UI labels are modified, not values).

[su_v (suv-lp)]

> It can also be reproduced with 0.48.1 and 0.48.2, on Windows XP.

Which $LANG (system locale)?

> but I'm almost sure there's no link between the issue and the changes in 10484

As mentioned, with LANG="en_US.UTF-8" (Inkscape Preferences > Interface > Language: 'System default') I can only reproduce it with > r10848, and not with stable versions or earlier revisions.

With different locale settings (i.e. translations used), the issue occurs on older versions too, e.g.:

# reproduce with stable and trunk:
LANG="fr_FR.UTF-8" inkscape
# reproduce with trunk > r10484 only:
LANG="en_US.UTF-8" inkscape

[jazzynico (jazzynico)]

Damned. I removed the prefs file and forgot to switch back to English...

> # reproduce with stable and trunk:
> LANG="fr_FR.UTF-8" inkscape
> # reproduce with trunk > r10484 only:
> LANG="en_US.UTF-8" inkscape

Confirmed.

[su_v (suv-lp)]

I do have to add that
a) when testing different revisions of trunk on my system, I do not revert the branch and rebuild: I keep copies of the installed binary around - they all use the same installed translation files (and other shared resources) of the latest revision of trunk.

b) the stable branches are each installed into separate prefixes and do not share any of the 'shared resources'.

(Just in case this is somehow related to po files, inkscape.pot and gettext for optiongroup parameters).

[su_v (suv-lp)]

I would like to propose to raise the importance of this one:
1) It can result in _data loss_ (that's how I learned that the expected behavior had changed in trunk: while creating a small tutorial with pasted screenshots of individual dialogs, I failed to notice that the screenshots pasted from the clipboard did no longer get embedded as expected. Next time I wanted to continue working on the file, the linked PNGs in $TMP were gone).
2) IMHO the workflows in general are too different to share the same setting: if an image file exists on disk, it is save to link to it by default (you are prompted each time when importing, anyway). Images pasted from the clipboard are transient by nature and need to be embedded or - when linked - explicitly stored on disk as new file (in the same directory as the current SVG document or in $HOME for unsaved documents). Even more so as pasting from clipboard does _not_ offer the choice to embed or link, nor can the setting be changed without explicitly importing an existing bitmap image from disk (type: PNG).

[jazzynico (jazzynico)]

I confirm the risk of data loss is quite high due to that issue.
Increasing importance to high.

[su_v (suv-lp)]

Related:
Bug #855440 “Two consecutive clipboard imports get same temporary xlink:href file”
<https://bugs.launchpad.net/inkscape/+bug/855440>

[jazzynico (jazzynico)]

The patch attached in Bug #171842 'Add an option to the preferences-dialog: "Auto embed images"' also fixes the reported issue.
Can be applied to the 0.48.x branch after (relatively easy) modification.

[jazzynico (jazzynico)]

Committed in the trunk, revision 11097.

[Kris (kris-degussem)]

Dropping the backport proposed tag: applying the patch to 0.48.x would introduce new strings, requiring all translations to be updated.

[su_v (suv-lp)]

Reopening, see
https://bugs.launchpad.net/inkscape/+bug/855440/comments/5

[su_v (suv-lp)]

Fix committed to trunk in r13867:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13867

[su_v (suv-lp)]

Backported by Scislac to 0.91.x in r13716.