Hatch not matching definition

[Lingwisyer]

Hi all,

I have one computer running aCAD2010 and another running aCAD2025LT and have run into an issue of hatches not matching. In the image below, the blue hatch is ANSI32 from 2010, and the yellow hatch is ANSI32 from 2025LT. Upon measuring the lines, 2025LT matches the hatch definition while the 2010 does not. Spacing ratio of 1:2.0, expected, vs 1:5.3... Other than the scale difference between acad.pat and acadiso.pat, is there anything that might be causing hatches to not match given the spacing is not even the correct ratio? I checked the two .pat files and the definitons are identical.

Ling.

[paullimapa]

2010 is so old and out of date so not much you can do about that one.

as for 2025, make sure you've installed the 2025.1 update

[cadffm]

Hi,

not 5.08 ?

There is nothing else than different definitions imperial/metric (fac 2.54).

And annotation feature can also display unexpected result in some situations.

Hatch property annotation=Yes

[Lingwisyer]

The 5.3 is the spacing ratio between lines, not between the two hatches.

[cadffm]

Yellow is Ansi32, blue is NOT the standard Ansi32 - also not in Acad2010 - the definition didn't changed.

Feel free to share a sample 2010 .dwg (copy the file and delete all except one ansi32 hatch, if needed).

[Simon_Weel]

If the definition in the .pat files is the same, I suspect they have a different scale factor?

[pendean]

@Lingwisyer You are going to have to hare your 2010DWG nd your 2025DWG files here please If you want help finding a solution (or cause).

[Kent1Cooper]

---

@Simon_Weel wrote:

If the definition in the .pat files is the same, I suspect they have a different scale factor?

---

The definitions are clearly not the same -- the proportion of the narrower space between lines to the wider space is very different -- so it's not just a scale factor problem, but different definitions, even though they may have the same name.

[Lingwisyer]

Odd... In playing around with the hatch in empty files today, the hatch is on the odd occasion changing...

I start a new file in aCAD2010,

hatch a square with the odd ANSI32 that the office has been using for years,

save, restart aCAD2010, open the file,

hatch edit and close the dialogue without any changes,

and the hatch updates to match the definition...

[paullimapa]

Same occurs when the 2010.dwg is opened in 2025. Once you edit the Hatch properties like changing the Island Detection Style or select additional boundaries the pattern would change to match with 2025's version...very odd behavior.

[cadffm]

Hi,

then the matter is clear.

So, someone made two essential mistakes on your side (in 2010)

1. The unforgivable mistake of changing a standard definition - you shouldn't do that with any standard definition.

2. The second mistake was that the definition wasn't really changed, but a second definition was added with the same name as a standard pattern.

(Order: first the original, second the fake definition with the same name)

- - -

Question 1: Do you want to keep both errors in the future, or just the first, or just the second, or better yet neither of them?

Suggestion: Do it the way I personally think it should be done and it makes technical sense.
_

In that case, you would be able to hatch as before, but the name would not be ANSI32, but perhaps ANSI32_rat53
Existing plans / existing old hatching could be easily updated to the new version - a small tool and one click are enough.

What does it look like. Should I help you?

[pendean · Accepted solution]

@Lingwisyer Thanks for the files. It appears you are ignoring the experienced advice from @cadffm 

1) Hatch patterns provided by Autodesk have literally not changed since the year 1991.

2) Your 2010 file contains a custom created-by-someone hatch pattern they chose to call ANSI31

3) Your 2025 file contains the true from-Autodesk hatch pattern that is in AutoCAD called ANSI31 that we can all match, in my case, AutoCAD 2022-23-24-25.

So... how would you like to proceed? I suggest your 2010 hatch be renamed something else so you can keep using it, copy that patterns into your 2025 setup with that new name. too.

[richard_387 · Accepted solution]

I can confirm that in a single drawing, one can have many hatches called the same name, but of differing definitions.

I drew the three hatches, all called AAAAA.pat, and they exist quite happily in the same drawing, as long as they are not altered. If you change the scale for example, the current definition file is read to create the pattern.

In the picture I drew ANS131 patterns, and tried to match properties with the top one. The hatch was altered to the current version of AAAAA.pat.

So the original observation can be explained, and take heed of the warnings about altering standard hatch patterns!

[cadffm]

That's how it works, because the source hatch definition is not part of the drawing and hatchs are not linking to the .pat files.

A hatch, onced created, is independing of pattern files/definition.

And now the question is: How do you like to handle it in the future?

I prefer to use your fav pattern as ANSI32_RAT53

and a tool to rename the pattern of existing hatchs from previous version.

[Lingwisyer]

So, I did a search through all of the loaded support folders and found the culprit. The ANSI defintions as well as a few others have indeed been modified in a .pat file from 2009... It was just never an issue as this file had always been the pattern source, until we added a LT this year (acadiso.pat vs acadltiso.pat) and updated our template which had not changed in the last decade. I did actually notice the hatch differences while I was using a different CAD program, but had just attributed it to a vendor variation...

I will extract and rename these custom definitions.

Thanks all,

Ling.