DWF not loading drawables for some layers

Aspose.CAD Product Family
1

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.

2

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

3

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.

4

@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.

5

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.

6

@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.

7

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.

8

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

9

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
10

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

11

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.

12

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

13

Good morning, I wanted to following on this issue with some additional information.

The client uses several GD&T symbols in their DWF drawings, mostly for dimensions/callouts. Many, if not all, of these symbols are part of the UTF-16 character set.

From what I can tell with the Aspose.CAD libraries it appears that DWF text may be handled as ASCII, possibly even only up to a value of 127. I believe this may be why some text elements are being read from the file(s) as alternate characters like ` and n. ALT+9005 is being read as lower case ‘g’.

It also appears that the rendering routines also render these as ASCII. I added UTF-16 substitution to replace the ‘g’ character being read from the file with the cylinder symbol (ALT+9005) but it is being rendered to the PDF as a hollow square instead.

Thought I’d add this in case it helps lead to a solution.

Thank you,
Sam

1 Like
14

@sking500,
thank you very much, we appreciate your findings and will research this.

15

FYI, since I am converting these CAD drawings to PDF before printing, I tried using the PDF search and replace function as described in the following blog post:

Replace Text in PDF|Aspose.PDF for .NET.

However, this does not work at all. The resulting new PDF still has the original symbols despite the Text value being reassigned properly (confirmed during debugging).

16

@sking500,
yes, the text is stored differently and can not be replaced in the PDF. You may replace the text in the drawing before export, e.g. Work with text|Documentation.

17

@sking500,
we need your help on the problem with incorrect symbols. Could you please clarify this more: we need the file with prpblem, and also can you send screenshots of the source image and the result image and mark on them the places where the differences that appear due to incorrect character reading are visible. Thanks a lot.

18

Alexy

Thank you for your reply. I have attached one of the original, source drawings (247499.idw.dwf within 247499.idw.7z) with this issue and a screenshot of the elements in question (247499.png).

As you may see in your testing, a few of the text elements are being read into the DwfWhipText objects’ Text property as the reverse single quote () and a few others are being read as lowercase n. The should be the +/- symbol instead (ASCII 177) and the n should be the diameter symbol (ASCII 216).

There is a separate drawing I can provide shortly where the cylinder symbol (UTF16 9005) is being read into the DwfWhipText object as lowercase g.

As a workaround for this I do a character substitution with the following code:

Aspose.CAD.Image _cadImage (passed into method)

if (_cadImage is Aspose.CAD.FileFormats.Dwf.DwfImage)
{
Aspose.CAD.FileFormats.Dwf.DwfImage dwfImg = _cadImage as Aspose.CAD.FileFormats.Dwf.DwfImage;
List texts = dwfImg.Pages[0].Entities
.Where(e => e is DwfWhipText)
.Select(e => e as DwfWhipText)
.ToList();
foreach (DwfWhipText text in texts)
{
string replace = Char.ConvertFromUtf32(sub.Value);
text.Text.AsciiString = elementText.Replace(sub.Key, replace);
}
}

sub.Key is a string to be replaced (`, n or g) and sub.Value is an Int32 to replace it with (177, 216 or 9005);

While debugging this code I can confirm that the DwfWhipText.Text.AsciiString property is reassigned properly and as I can see the plus/minus, diameter and cylinder symbols when I hover over the AsciiString property. However, when rendering the final output, the substituted text in the resulting PDF only displays properly when sub.Value <= 255 (e.g. within the standard ASCII range). When sub.Value > 255, the result is an empty square.

In summary, I believe there is two separate issues at work here. The first is the initial DWF file load where it is misreading certain characters. The second is the PDF rendering where it does not render characters with an ASCII value above 255 properly.

The latter issue (PDF rendering) may be a font issue - I noticed the font in the resulting PDF is set to Arial Bold which may not have character definitions above char(255) which is why is outputs a blank square for cylinder (UTF16 9005) while the plus/minus and diameter render properly. I have other Arial fonts on my PC but not Arial Bold so my computer may be substituting another Arial-based font for Arial Bold. None of the Arial fonts on my PC appear to support anything beyond the standard ASCII characters. I have asked the client which font they use in the original CAD drawing and am awaiting a response. I have tried looking for fonts installed on my PC which support UTF16 characters and try rendering the drawings using that font instead.

247499.jpg (110.1 KB)
247499.idw.7z (197.3 KB)

1 Like
19

@sking500,
thank you, we will look into it.

20

Just wanted to post an update. As far as the PDF rendering goes, it appears that the issue is, indeed a font issue. I tried replacing the font name with “Arial” for all of the cases where characters are being substituted with symbols and the symbols ended up in the resulting PDF displaying as they should. They also printed fine.

For testing I added the following line after text.Text.AsciiString = elementText.Replace(sub.Key, replace)

                        if (!string.IsNullOrWhiteSpace(alternateFont))
                        {
                            text.Font.Name.Value.AsciiString = alternateFont;
                        }

where alternateFont = “Arial”.

This is a “good enough” solution for the client.

1 Like