AFAICT - at least on OS X - this only affects exports to the same location (directory aka folder) as the SVG file itself, with a custom file name for the exported PNG image (different than the object ID): neither export path nor the custom file name is stored as 'inkscape:export-filename' for the exported object as expected (and as in 0.48.x).
OTOH the information is correctly recorded for the exported object when exporting to a different folder (with absolute or relative path to the current location of the SVG file itself, does not matter).
In today's tests with archived builds on OS X 10.7.5:
- not reproduced with rev <= 11243,
- reproduced with rev >= 11250;
the regression seems related to changes between r11243 (behaves like 0.48.x) and r11250 (custom export file name is not stored if exported to the same folder as SVG file): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/11250
AFAICT - at least on OS X - this only affects exports to the same location (directory aka folder) as the SVG file itself, with a custom file name for the exported PNG image (different than the object ID): neither export path nor the custom file name is stored as 'inkscape: export- filename' for the exported object as expected (and as in 0.48.x).
OTOH the information is correctly recorded for the exported object when exporting to a different folder (with absolute or relative path to the current location of the SVG file itself, does not matter).
In today's tests with archived builds on OS X 10.7.5: bazaar. launchpad. net/~inkscape. dev/inkscape/ trunk/changes/ 11250
- not reproduced with rev <= 11243,
- reproduced with rev >= 11250;
the regression seems related to changes between r11243 (behaves like 0.48.x) and r11250 (custom export file name is not stored if exported to the same folder as SVG file):
http://
ISTM the changed behavior most likely is a side-effect of the refactoring in rev 11245 bazaar. launchpad. net/~inkscape. dev/inkscape/ trunk/revision/ 11245
http://