QCAD.org Forum

QCAD Pro 3.19.2, Xubuntu Linux 64-bit

I made up a simple little title block with the CE and saved it as a DXF. It includes the QCAD logo, where QCAD.org is constructed from hatched (solid fill) geometry rather than simple lines. I later added a projection symbol with QCAD Pro (that edit has nothing to do with this issue) and saved it as a 2018 DWG. It looks like this on the original DXF:



When I load the DWG (2018 or 2013, same results), I get this:



I can re-do the hatch, but upon re-loading, it's wrong again. Looking back through the command line history, there are several errors like this:
...or another hex value, which is the handle of the hatch.

Any idea why it's not saving the hatch?

I've attached the DXF and DWG drawings.

Thanks.

The outline for the hatch isn't clean - it has gaps. Yes, it will work in certain circumstances but has problems if you play around with it like modifications or different formats. This screenshot is your "working" dxf - I just scaled the logo and it already failt.
Please check and correct the contur for the hatch. I'm sure that is all what it takes.

I'll take a look. What's strange is that when I created the logo, all the endpoints were snapped to each other. That's why I didn't suspect that as the cause (and also that it does hatch successfully, it just won't save).

Oh well...

Thanks.

Think about to use the "Round" tool to get a perfect closed outline.

I hear you, but logically if two endpoints snap together, "together" should imply the same exact coordinates regardless of scale, or anything else for that matter. I realize in a a programming context, 'exact' is rarely exact (floating point imprecision and all that), but... I don't know how Andrew is handling that (are unsigned longs large enough?), but the process of snapping seems to me that imply that the 'moving' endpoints coordinates are assigned the exact same value as the static endpoint, hence the 'snap'. So it's strange -- to me at least -- that two endpoints snapped together can later 'degrade' to where they're n longer at the same location, apparently. If it was exact enough for hatching to work initially, what caused it to later be too inexact? Limitations of the file format (surely not)?

At any rate, I'll take a (very) close look and see what happens.

lphilpot wrote:So it's strange -- to me at least -- that two endpoints snapped together can later 'degrade' to where they're n longer at the same location, apparently.

Yes, if endpoints are properly snapped / trimmed that would be the case.

lphilpot wrote:If it was exact enough for hatching to work initially, what caused it to later be too inexact? Limitations of the file format (surely not)?

Yes, that's most likely exactly what the problem was: QCAD is apparently a bit more tolerant when bridging small gaps, whereas Teigha and the DXF/DWG format refuse to bridge those same gaps. However, if outlines are snapped / trimmed properly, both should be happy. One way to ensure that an outline always stays closed is to convert that outline into a closed polyline. Closed polylines form by definition a closed loop without gaps.

Quick fix:
- Delete all fills
- Select all outlines of the letters
- Draw > Polyline > Create from Selected Entities
- Create hatch from polyline outlines

I was still getting one segment that was wrong and caused the hatch not to save. I exploded everything, created polylines one letter at time, rehatched and it saved/reloaded properly.

Thanks.