HATCH rendering issue of text box boundary paths

[bdaniere]

Describe the bug

Hi,

I'm coming back with a new question / problem about the DXF - SVG conversion. On the following model, the conversion is correct for the vast majority of entities.

However, the element (HATCH) corresponding to handle "17ECC6" does not appear correctly. Indeed, in the SVG output, the element is centered in the middle of the SVG and looks like a horizontal bar chart. This should be located in the middle diagram of the right column.

To Reproduce

from ezdxf.addons import odafc
from ezdxf.addons.drawing import matplotlib

doc = odafc.readfile("DWG_PATH")
dxf_modelspace = doc.modelspace()

matplotlib.qsave(
        layout=dxf_modelspace,
        filename="OUTPUT_PATH",
        bg="#FFFFFF00",
    )

power_unit_1.zip

Screenshots

[mbway]

Different versions of ODAFileConverter can sometimes produce different outputs so it would be easier if you uploaded the converted DXF file you are trying to draw.

Also an image of what you're expecting could be useful (if you have access to another CAD application which displays correctly)

Also, you are specifying SVG output, does this mean that other output formats like PNG are working?

[bdaniere]

Here is the DXF file : power_unit_1.zip The error is also present on output in another format, such as PNG

The expected result would be not to have this set of geometry resembling a horizontal bar chart :

In case you have an Autodesk account, here is an access to the DWG file on this document : https://autode.sk/3o2RyB0

I can see that the basic geometry is correct (the hatch is there, in the right place): it's probably the filling that spreads out on the final drawing

[mozman]

This is a valid HATCH with valid closed edge loops.

This is the extracted and selected HATCH entity in BricsCAD, same result when selected in the original DXF file:

I have no idea why only one loop is rendered and the rest is not:

• island detection is "nested", this means all paths are used
• multiple independent boundary paths in one HATCH entity is valid and a common usecase
• the loop orientation (clockwise or counter-clockwise) has no meaning for DXF
• it's not associative, so missing associated geometry can't be the reason

[mozman]

The edge paths have the "textbox" flag set, which the DXF reference explains as ... nothing like always.

I assume this should define a recess for a text object. The handling of this path is complicated, because it should be subtracted inside a filling and ignored inside a hole, which can't be done easily by the current implementation.

Expanding the visible HATCH beyond such text boxes:

[mozman]

Next problem: text box overlapping fill and hole can't be handled by the PyQt and Matplotlib backends in the current implementation:

DXF file in BricsCAD:

ezdxf view (PyQt):

ezdxf draw (Matplotlib):

This requires the text box to be split on the border between the fill and the hole, this is way beyond what I want to implement.

Simple solutions:

1. Ignoring stand alone text boxes as separated boundaries at the top level outside of any other boundary, which should solve this issue
2. Text box inside of another boundary: invalid rendering result as it is