We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

DWF not loading drawables for some layers

I am evaluating the Aspose.CAD libraries for an automated DWF printing solution which converts the DWF to PDF first, then uses Aspose.PDF to print. My clients’ DWF files all appear to be single page but multiple layer.

The best I can tell is that when I use the Aspose.CAD.Image.Load() method it correctly as a DwfImage but it only loads the DwfWhipDrawables for the first layer at there are only 28 listed but should have several hundred. The Layers list on the DwfImage object has all layers listed, but only the first layer converts/prints, I am guessing due to the missing DwfWhipDrawables.

Any help you can provide or suggestions are greatly appreciated.

Edit: One correction, it appears that the drawables for the last layer are not loaded. I came across another DWF file with six layers and the only one missing drawables was the last layer. In each case so far, the missing layer is named “Symbols(ANSI)” and is always the last layer.

@sking500,
could you please add the file you are talking about, so we can test it?

Attached is a 7z file with three sample files. They all exhibit the same issue.

MissingDwfWhipDrawables-LastLayer.7z (543.3 KB)

Is there any classes I might be able to descend from to try overriding the functionality and “force” these drawables to load?

FYI, I was using Aspose.CAD v. 22.3.0 but upgraded to 22.6.0 last night and both versions exhibited this issue.

@sking500,
I created CADNET-8703 to look at this in more details.
I don’t think such classes exist, I believe loading of the entire content of the file is the right way to follow, probably, we skip some content. Let us investigate and come back.

Good morning, I was wondering if you have had the opportunity to test the files I provided? I understand you have only so many resources to draw from and testing may take some time. I have checked other CAD conversion solutions but yours is the only one that has come close to working and this is the final issue before I am able to deliver a solution to my client.

Thank you for your time and consideration.

@sking500,
Hello, yes, we have tested and found that some error occurs during reading of the file, that’s why it is incomplete. I can not guarantee this fix to appear in 22.7 being prepared, likely in 22.8.

Good morning. I am following up to ask if this fix will be in 22.7 or 22.8 and what the expected release dates for each version are so I can let my client know when I’ll have their project ready.

Thank you for your help.

@sking500,
Hello. I believe the fix is already available in 22.7 release here. Please, test it on your side.

Thank you for your reply. I have updated the tool and it appears that the issue has been fixed. I have notified my client to review the output and confirm.

I appreciate the prompt response and turnaround time on this.

1 Like

@sking500,
thank you too, we were happy to help.

The fixes are working great. However, it seems we have run into a separate issue with the 247499.idw.dwf file included in the original .7z attachment.

My client uses some special characters in some of their drawings, notably the plus/minus (ASCII 177) and radius (ASCII 216) symbols. For some reason, the values being read into the DwfWhipText objects are being read in as ` (ASCII 96) and n (ASCII 110) instead (respectively).

I have tried loading the DWF file using the SpecifiedEncoding setting in the LoadOptions and have used all eleven of the “western” code pages and their variants (Default, English, Roman, Latin, UTF, US, Western, etc.) but it makes no difference, they all produce the same result.

If I do a string replace on the DwfWhipText.Text.AsciiString value and replace the incorrect characters with the correct ASCII equivalents (converted from byte value to char to string), the drawing renders correctly. Since my client does not use lower case n nor ` anywhere in this or any other drawing (their notes and footers are all uppercase), I have written a character substitution function to replace these two values.

However, I wanted to alert you to this in case it is something that needs to be looked into.

FYI, for comparison purposes, I used a DWF to PDF conversion tool on a competitor’s website and it had the exact same issue so I am not sure if it is something with the file, itself, or if there is some undocumented DWF file stream handling to read Extended ASCII characters.

@sking500,
thank you for the feedback, we will check this problem in the scope of same CADNET-8703 issue.