Drag and Drop from VSS failed

could you attach the .vss file that is leading to the failure?

also, if you have a .vss file that appears to be working, could you attach that as well?

Please add information about OS/platform to the bug description, thank you.

As mentioned by Alvin, test cases (VSS files) are required to allow further investigation of the reported issue.

Hi,

Please find asked data:

Inkscape 0.92.0 r15299 (64-bit)
OS : Windows 7

and typical VSS used for which it is not possible to import Symbols:

Aerial&audio.vss : not working
logicgates.vss : working

with working VSS attached.

Thanks to help me to understand what has to be done.

Try renaming 'Aerial&audio.vss', for example to 'Aerial_audio.vss'. Does that work for you?

Reproduced on OS X 10.7.5 with Inkscape 0.91 r13725, 0.92.0 r15299, lp:inkscape/0.92.x r15365.

Seems like a filename encoding issue as su_v suspected.

On Windows this issue seems to be two-fold:

_________________________________________________________
PART 1:
Same as bug #1656763. I guess only Windows is affected as we use "g_dir_read_name()" to get the available symbol files which should return the filename in the proper file system encoding on Unix.
On Windows this leads to errors like

E:\Temp\Inkscape\inkscape\0.92.x_64\build\inkscape\share\symbols\ä.vss:1: parser error : Start tag expected, '<' not found

for a file named "ä.vss" (i.e. the file was probably not even found on disk...)

I have fixed this part locally by applying the fix from the linked bug. However it still fails:

__________________________________________________________
PART2:
Even if the file is properly loaded there seems to be yet another issue (or even other issues) as I'm getting the following error even after the fix:

Entity: line 10: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xC3 0x5F 0x30 0x22
    <symbol id="Ã_0">
                ^

I guess Inkscape is using the file name internally to generate IDs which fails if the file name is not UTF8 or might always fail if it's not valid XML (I'm still looking into that, though, so I'm not completely sure about that yet).

__________________________________________________________

su_v: I guess on OS X you're only getting the bug in PART 2? Could you indicate the error output on the console (if any)?

> su_v: I guess on OS X you're only getting the bug in PART 2?

Console messages from Inkscape with lp:inkscape/0.92.x r15365:

Entity: line 8: parser error : EntityRef: expecting ';'
  <title>1662465-Aerial&audio.vss</title>
                                 ^
/Users/su_v/TEMP/inkmini-x11/config/inkscape/symbols/1662465-Aerial&audio.vss:1: parser error : Start tag expected, '<' not found
??ࡱ?
^

File info:
$ file "/Users/su_v/TEMP/inkmini-x11/config/inkscape/symbols/1662465-Aerial&audio.vss"
/Users/su_v/TEMP/inkmini-x11/config/inkscape/symbols/1662465-Aerial&audio.vss: CDF V2 Document, Little Endian, Os: Windows, Version 5.1, Code page: 1252, Author: anne journeau, Last Saved By: anne journeau, Name of Creating Application: Microsoft Visio, Last Saved Time/Date: Mon Mar 19 13:28:17 2012

su_v wrote:
> Console messages from Inkscape with lp:inkscape/0.92.x r15365 (...)

JFTR - if I rename the file as described in comment 6, the symbol library is parsed ok, listed in the 'Symbols' dialog as 'Aerial_audio.vss', with 6 symbols which all can be inserted into the document as expected.

OK, seems you're hitting yet another error (invalid characters in "title" attribute - I avoided that by not using the ampersand "&" in my test file) plus PART1.

I should be able to fix all of them.

However could you check if OS X is affected by bug #1656763 / bug #1416949 (they're basically the same issue)? I got the impression this was a Windows-only issue due to the win32/win64 tags but I think nobody ever confirmed that it didn't happen on other OSs.

Eduard Braun wrote:
> However could you check if OS X is affected by bug #1656763 / bug #1416949

Test case:

  1416949-test-äöü/442010-Frenchcurve.cdr
  1416949-test-äöü/1656763-grundriss.vsd

Both files open as expected (OS X builds are not affected by bug #1656763 / bug #1416949).

The attached patch fixes
- the original issue spotted in this bug (ampersand "&" in the filename which was resulting in an invalid title of the internally generated SVG document holding the symbols). The title is now properly escaped.
- the issue with non-ANSI filenames on Windows (i.e. German umlauts / Cyrillic characters). I applied the same fix as in bug #1416949.
- a third issue caused by invalid symbol IDs. Before it was possible to create IDs that were invalid XML (preventing to load the symbol file to start with) but it was also possible to create IDs that were accepted by the parser while resulting in invalid hrefs when actually using a symbol (therefore loading the symbols succeeded but as when attempting to add them to the document they were not visible due to the invalid href). With the patch all characters that do not match [a-zA-Z0-9_-] are replaced with an underscore "_") which should result in valid IDs in almost all cases.

@su_v: could you check whether this fixes the issue on OS X? If not we have to investigate further...

Patch tested successfully with lp:inkscape/0.92.x r15365 using the two VSS files attached to this report: both sets are listed in the Symbols dialog, symbols from both sets can be inserted into the current document, and display as expected after saving and reloading the file.

Commited in r15501
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15501

I suggest to also back-port for 0.92.2.

lp:inkscape r15501 fails to compile on Ubuntu 14.04.5 LTS, see attached build log.

Was already fixed in r15502 (I wonder why we could compile it in some environments but not in others...)

Fix committed for 0.92.x branch in r15375
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15375

Ok.
Thanks a lot for your support.
Stephane