Comment 5 for bug 1308986

well, this raises a rather difficult issue, way outside my experience. The code for dxf_input.py already incorporates a patch proposed by hefee in Bug 397793. This patch was designed to deal with non-Ascii characters and it appears to be working well. The patch incidentally also deals with blank spaces and replaces them with %20 as normal. The patch applies utf-8 encoding to the id in the 'use' element. So in our case the 'use' element in the main body of svg has the following
xlink:href = #Sofa%20-%2072_-273882-Level%201.
The corresponding 'symbol' element in the defs section is not encoded, so the id is given by
id = Sofa - 72_-273882-Level 1

This arrangement appears to work well for the original rendering, but does not work for the symbol drag and drop. I did a quick experiment to see if the problem could be solved by encoding both the 'use' element and the 'symbol' element, but this made matters worse instead of better. Now both the original rendering was broken, as well as the drag and drop of symbols.

It is not clear to me whether this is a deficiciency in the Python code or whether it is a deficiency in the drag and drop of symbols. It would seem that the best solution would be to continue to try to use utf-8 encoding rather than replace blanks with something else.