DXF import: non-instantiable Symbol (malformed URI)

A'symbol' (it's actually a clone of a (hidden) <symbol> object) can be converted to an 'editable' object like other clones: select and unlink (see menu 'Edit > Clone').

Apparently blocks in dxf are converted to SVG symbols (which is great Imho, that's IIRC very close to how blocks are used in AutoCAD).

The symbol btw is present in the Symbols dialog, but not visible rendered (no style information) - it can be selected by a click in the top-right area, and can be 'removed' from the drawing by using the button below the symbol icon view (if you prefer that to the 'unlink clone' method).

Thanks for the info - I did not realise it was a clone.
I kept looking for the "Object -> Symbol to Group" tool as mentioned here:
http://wiki.inkscape.org/wiki/index.php/SymbolsDialog

It does work exactly as you report.
But I still can't get it to be DragnDrop'd into the doc - like other
symbols - from the Symbol dialog.

E.g. In the Symbols Dialog
  - I select AIGA symbols
  - click on first one and drag it onto doc.
  - it appears when I release mouse.
But
if I select the "Current document" in Symbols dialog
- select the visible symbol (loaded from the DXF)
- and DnD it across to doc
- on release there is no symbol added.
I see warning on my console **(inkscape.exe:5588): WARNING **:
Malformed URI

I also note that when I try to transform selected shape (from DXF) I get
an error on my console:
**(inkscape.exe:5588): WARNING **: Invalid state when picking: STATE_BOX
= 0, STATE_PICK = 4

and the only thing I can find different is:
- there is no group under the DXF loaded symbol holding all the paths.
- there is a group under the AIGA symbol holding all the paths.

On 4/18/2014 3:51 AM, ~suv wrote:
> A'symbol' (it's actually a clone of a (hidden) <symbol> object) can be
> converted to an 'editable' object like other clones: select and unlink
> (see menu 'Edit > Clone').
>
> Apparently blocks in dxf are converted to SVG symbols (which is great
> Imho, that's IIRC very close to how blocks are used in AutoCAD).
>
> The symbol btw is present in the Symbols dialog, but not visible
> rendered (no style information) - it can be selected by a click in the
> top-right area, and can be 'removed' from the drawing by using the
> button below the symbol icon view (if you prefer that to the 'unlink
> clone' method).
>

On 2014-04-18 13:32 +0100, Neon22 wrote:> Thanks for the info - I did not realise it was a clone.
> I kept looking for the "Object -> Symbol to Group" tool as mentioned here:
> http://wiki.inkscape.org/wiki/index.php/SymbolsDialog

Please note that the wiki page is not a documentation of a feature in a stable released package - those are devel notes, of a feature new in trunk, still in parts 'work-in-progress'. The dialog was later partially refactored by Martin Owens: AFAIU he had to remove the menu entries because he changed logic of how symbols can be edited now: by selecting the preview image in the Symbols dialog instead of an instance inserted on the canvas, and then clicking on the button with the tooltip 'Remove symbol from current document' below the icon view holding the preview images of the symbols.

> It does work exactly as you report.
> But I still can't get it to be DragnDrop'd into the doc - like other
> symbols - from the Symbol dialog.
(…)
> if I select the "Current document" in Symbols dialog
> - select the visible symbol (loaded from the DXF)
> - and DnD it across to doc
> - on release there is no symbol added.
> I see warning on my console
>> **(inkscape.exe:5588): WARNING **: Malformed URI

Confirmed - likely that's due to the spaces in the id of the symbol generated by the dxf importer script. IIRC those are not allowed in SVG id attributes (but this needs to be verified). Or the parser fails to handle the spaces correctly (the symbol is inserted, but it does not find the referenced original -> the message in the status bar says 'Orphaned clone').

Possibly the DXF importer needs to be adjusted to support the Symbol dialog better (no spaces in id's for <symbol> elements (?).

> I also note that when I try to transform selected shape (from DXF) I get
> an error on my console:
>> **(inkscape.exe:5588): WARNING **: Invalid state when picking: STATE_BOX = 0, STATE_PICK = 4

Unrelated to the specific problem reported here. These warnings occur in various situations and are tracked in bug #1256597.

> and the only thing I can find different is:
> - there is no group under the DXF loaded symbol holding all the paths.
> - there is a group under the AIGA symbol holding all the paths.

IIRC this was recently changed to no longer be a requirement (a group as container element inside the <symbol> definition):

> Rewrite of symbol creation code. Partial fix for 1201325.
>
> Symbols cannot have 'tranform' attribute. The old code copied the group
> 'transform' attribute to the symbol. The new code creates an intermediate
> group with the required 'transform' if it is not a simple translation. A
> simple translation is removed and applied instead to the new <use> element.
>
> Multiple objects can now be turned into a symbol without first grouping the
> objects. (At the cost that multiple groups can no longer be turned into
> multiple symbols at one go.) This better matches marker and pattern creation.

Source: <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13057>

On 2014-04-17 17:51 +0100, ~suv wrote:
> The symbol btw is present in the Symbols dialog, but not visible
> rendered (no style...

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.

a similar problem is encountered when non-Ascii characters are used in dxf block id's or svg symbol names.
attached is an edited version of the dxf file, where the block name has been changed to just Sofá.

the imported svg file is attached here. In the svg file, the 'use' element contains the utf-8 encoded value xlink:href = #Sof%C3%A1
the 'symbol' element contains the original value, which is: id = Sofá
the symbols dialog box contains the tooltip Sofá when the mouse hovers over the symbol.

the console displays the message
** (inkscape.exe:4004): WARNING **: Malformed URI
when you click on the symbol in the Symbols dialog box,
and the symbol refuses to drag and drop.

> the imported svg file is attached here.
> (…) and the symbol refuses to drag and drop.

Can't fully confirm - the clone of the symbol is created (copied to the clipboard when selected (produces the first 'Malformed URI' warning), and pasted into the document when drag&dropped (2 more warnings)), but it doesn't render visibly. Watch the messages in the status bar: after drag&dropping from the symbols dialog onto the canvas, it says:
"Clone [orphaned] in layer I-FURN. Use Shift to … "
and the file (attached) now has two clones in the layer 'I-FURN':

  <g
     inkscape:label="I-FURN"
     inkscape:groupmode="layer"
     id="g7683">
    <use
       y="-225.022812"
       x="311.043266"
       xlink:href="#Sof%C3%A1"
       id="use7685" />
    <use
       id="use7983"
       xlink:href="#Sofá"
       x="0"
       y="0"
       width="100%"
       height="100%" />
  </g>

attached is a modified version of the file dxf_input.py. This can be tested by copying it to the directory Inkscape\share\extensions\.
This fixes the original issue caused by blank spaces. These are replaced with '_'. The symbol can now be dragged and dropped.

It does not address the issue related to non-Ascii characters. I suspect this will have to be handled as a separate bug, probably in the Symbols dialog code, not in Python.

fix committed to rev 13294

Is there a way to perform Edit > Clone > Unlink action from python interface?

Also: please make small correction to dxf_input.py - remove stroke from style when cheating DXF-point arrow:
in section def generate_gcodetools_point(xc, yc):
    path= 'm %s,%s 2.9375,-6.34375 0.8125,1.90625 6.84375,-6.84375 0,0 0.6875,0.6875 -6.84375,6.84375 1.90625,0.8125 z' % (xc,yc)
    attribs = {'d': path, inkex.addNS('dxfpoint','inkscape'):'1', 'style': 'stroke:#ff0000;fill:#ff0000'}
    inkex.etree.SubElement(layer, 'path', attribs)

New style shoud be 'stroke:none;fill:#ff0000'

The reason: "filled arrow'a area" points to exact original DXF point location, but the "stroke outline" jumps over by the stroke width.

>> New style shoud be 'stroke:none;fill:#ff0000'

style change has been committed to rev 13304

Alvin, thank you!
Also - inkex.localize() IS working under linux/developmente release, but IS NOT working under widows-stable. I've added
try:
 inkex.localize()
except:
 pass

block and latest dxf_input.py works under windows-stable release well enough.

Also dxf_import.py has a bug - when inserts a block from .DXF a ghostly part of the block presents. After opening this dxf in QCAD and EXPLODE ghos-part disappers.

Sorry, attachment problem: 3 files in archive -
1. DXF causing problem
2. DXF after EXPLODE command ( not causing a problem)
3. Inkscape screenshot right after importing with ghostly copy (part of the original DXF is copied during import operation by dxf_input.py)

P.S. Is it better to add new ticket? Sorry again about overweighting a post.

> Also - inkex.localize() IS working under linux/developmente release, but IS NOT working under widows-stable.

To be expected (there have been several breakages, and extensions in trunk are no longer backwards compatible with current stable (the change of the translation strings is one of them, changes wrt to unit handling another one).

> Is it better to add new ticket?

Yes, please - this ticket was filed about a specific issue, and closed earlier. Other DXF import issues should be tracked in separate reports - otherwise tracking progress (and potentially backporting fixes from trunk to the stable branch) gets really cumbersome (or impossible).

bug #1313156 submitted.

Please help: Is there a way to perform Edit > Clone > Unlink action from python interface?