SmartArts are exported incorrectly in output DOC/RTF using .NET

Hi Aspose support,
In our product we have functionality that converts SmartArts to images and replace SmartArt shape with resulted image shape.
Similar to what MS Word do when converts DOCX document with SmartArts into DOC/RTF format.
After testing this approach we were faced with the different issues. Please see the list:

Case#1:
Wrong fill color of SmartArt and text highlighting is not applied for text in SmartArt.
Please see screen shot of the problem (left side - how it was converted with Word, right side - with Aspose):
SmartArtColorIssue.png (276.0 KB)
Original document:Case#3.zip (34.7 KB)
Document with problem after conversion:Case#3_Converted.zip (127.4 KB)

Expected result: SmartArt fill colors and text highlighting (in converted image) should stay the same as in original SmartArt (like Word does)

Case#2:
Wrong 3D styles of SmartArts and text issues.
After conversion SmartArt to image, SmartArt loses 3D style and text inside does not fit to text box or has incorrect color, see screen shot:
3DStyleIssue.png (112.3 KB)

Source document:SmartArt 3D.zip (18.5 KB)
Resulted document after conversion:SmartArt 3D_Converted.zip (28.5 KB)
Expected result: Converted SmartArt should have 3D style and text should look the same as in original document;

-Problem with fitting text into shape bounds:
TextSizeIssue.png (54.1 KB)

Source document:TextSize.zip (15.5 KB)
Resulted document after conversion:TextSize_Converted.zip (22.0 KB)
Expected result: Text should fit to SmartArt bounds, as in original document;

-Text color problem:
TextColorIssue.jpg (212.7 KB)

Source document:TextColor.zip (333.5 KB)
Resulted document after conversion:TextColor_Converted.zip (729.4 KB)
Expected result: Text should have the same color as in original SmartArt;

Case#3:
Wrong text orientation after conversion SmartArt to image:
WrongTextOrientation.png (50.4 KB)

Source document:Case#3.zip (21.4 KB)
Converted document: Case#3_Converted.zip (20.3 KB)
Expected result: Text in converted to image SamrtArt should have the same orientation as in original document/SmartArt.

Conversion whole document to DOC format does not work for us and it does not solve the problem. Format should stay the same, but SmartArts should become images.
Tested on Aspose.Words.dll v19.8

Code sample:

ImageSaveOptions optionsPng = new ImageSaveOptions(SaveFormat.Png);
optionsPng.Scale = 2;

DocumentBuilder builder = new DocumentBuilder(_doc);
	ReplaceShapes(_doc, optionsPng, builder);


	
	private void ReplaceShapes(Document doc, ImageSaveOptions options, DocumentBuilder builder)
{
    NodeCollection shapes = doc.GetChildNodes(NodeType.Shape, true);
    // Loop from last one to first one
    for (int i = shapes.Count - 1; i >= 0; i--)
    {
        try
        {
            Shape shape = (Shape)shapes[i];

            if (!(shape.HasChart || shape.HasSmartArt)) continue;
      
            using (MemoryStream stream = new MemoryStream())
            {                       
               shape.GetShapeRenderer().Save(stream, options);

               shape.AnchorLocked = true;
				   builder.MoveTo(shape);

				   InsertImage(builder, stream, shape);
    		   shape.Remove();            
            }
        }
        catch (Exception e)
        {                    
        }
    }
}
	
	private Shape InsertImage(DocumentBuilder builder, Stream imgContent, Node sourceNode)
{
    Shape image = null;

    Shape sourceShape = (Shape)sourceNode;
		if (sourceShape.IsInline)
    {
			image = builder.InsertImage(imgContent, sourceShape.Width, sourceShape.Height);
    }
    else
    {
			image = builder.InsertImage(imgContent, sourceShape.RelativeHorizontalPosition, sourceShape.Left,
                        sourceShape.RelativeVerticalPosition, sourceShape.Top, sourceShape.Width, sourceShape.Height,
                        sourceShape.WrapType);
           
    }
                
    return image;
}

Please help with these problems.
Thanks.

@licenses

We have tested the scenario and have managed to reproduce the same issue at our side. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET-19164. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

@licenses

For case 2, we have logged the following issues in our issue tracking system.

Issue ID is WORDSNET-19165.

Issue ID is WORDSNET-19166.

Issue ID is WORDSNET-19167.

We have logged this problem in our issue tracking system as WORDSNET-19168. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

The issues you have found earlier (filed as WORDSNET-19168) have been fixed in this Aspose.Words for .NET 19.11 update and this Aspose.Words for Java 19.11 update.

Great. What about other cases, were they fixed as well?

@licenses

Unfortunately, there no estimate available at the moment for the other issues. We will inform you via this thread as soon as there is any update available on these issues. We apologize for your inconvenience.

The issues you have found earlier (filed as WORDSNET-19167) have been fixed in this Aspose.Words for .NET 20.6 update and this Aspose.Words for Java 20.6 update.

It is to inform you that the problem with highlight color will be resolved in Aspose.Words 20.7. However, there is another problem in output that is with fill color. We have logged new issue as WORDSNET-20638 for it. We will inform you via this forum thread once this issue is resolved.

The issues you have found earlier (filed as WORDSNET-19164) have been fixed in this Aspose.Words for .NET 20.7 update and this Aspose.Words for Java 20.7 update.

Hi @tahir.manzoor,
WORDSNET-19168 - Fixed. Checked with latest Aspose.Words.dll v20.7.0
WORDSNET-19167 - Fixed. Checked with latest Aspose.Words.dll v20.7.0

WORDSNET-19164 - Partially fixed. Checked with latest Aspose.Words.dll v20.7.0. In this case the problem with text highlighting is fixed, but there’re other problems left: wrong background color and wrong font for some elements. Sorry if I was not so specific for a description of the problem, I thought, from the screenshot, it’s obvious what are the issues. Please see screen shot:
BackgroundColorIssue.png (243.0 KB)

UPD:
Sorry, missed your previous comment about opened case WORDSNET-20638, for background issue. But pay attention on wrong font issue as well.

@licenses

We have tested the scenario and managed to reproduce this issue at our end. We have logged this issue as WORDSNET-20876 in out issue tracking system. We apologize for your inconvenience.

The issues you have found earlier (filed as WORDSNET-20638) have been fixed in this Aspose.Words for .NET 20.8 update and this Aspose.Words for Java 20.8 update.

@licenses

Further to my previous post, we noticed some more issues with document conversion and have been logged as follow:

  • WORDSNET-20963 (Text with font “HGSoeiKakugothicUB” does not render correctly after converting to PDF)
  • WORDSNET-20965 (The direction of the text changes after converting to PDF)

You will be notified via this forum thread once these issues are resolved. We apologize for your inconvenience.

@licenses

Please note that “HGSoeiKakugothicUB” is an MS Word cloud font (see Cloud fonts in Office - Microsoft Support). MS Word loads it from cloud into "\AppData\Local\Microsoft\FontCache\4\CloudFonts" folder when document with this font is opened.

Aspose.Words currently does not support MS Word cloud fonts. I.e. Aspose.Words does not load the fonts from Microsoft cloud and does not access cloud fonts folder by default. In order to use “HGSoeiKakugothicUB” font, please provide it to Aspose.Words either by adding cloud fonts folder to font sources or by copying font file.

Got it. Thanks. Can you be more specific? Should the path be specified in codes or Aspose automatically detects that location?
Let’s say if the font will be in that location.

@licenses

When a font is installed on a machine, Aspose.Words automatically detects it while document conversion. You can also set the font’s source path as shown in following code example.

Document doc = new Document(MyDir + "Rendering.docx");

// Retrieve the array of environment-dependent font sources that are searched by default
// For example this will contain a "Windows\Fonts\" source on a Windows machines
// We add this array to a new ArrayList to make adding or removing font entries much easier
ArrayList fontSources = new ArrayList(FontSettings.DefaultInstance.GetFontsSources());

// Add a new folder source which will instruct Aspose.Words to search the following folder for fonts
FolderFontSource folderFontSource = new FolderFontSource("C:\\MyFonts\\", true);

// Add the custom folder which contains our fonts to the list of existing font sources
fontSources.Add(folderFontSource);

// Convert the ArrayList of source back into a primitive array of FontSource objects
FontSourceBase[] updatedFontSources = (FontSourceBase[]) fontSources.ToArray(typeof(FontSourceBase));

// Apply the new set of font sources to use
FontSettings.DefaultInstance.SetFontsSources(updatedFontSources);

doc.Save(ArtifactsDir + "Rendering.SetFontsFoldersSystemAndCustomFolder.pdf");

A post was split to a new topic: Roundcubefour

The issues you have found earlier (filed as WORDSNET-20876) have been fixed in this Aspose.Words for .NET 21.1 update and this Aspose.Words for Java 21.1 update.

@licenses We completed analyzing the issue WORDSNET-20965 and concluded to close it as ‘Won’t Fix’.
The language specified in the lang attribute of the a:rPr tag affects the text direction. In the attached document, lang is set to ar-SA (Arabic Saudi Arabia), and MS Word renders the Thai text from right to left:

          <a:r>
            <a:rPr lang="ar-SA">
              <a:solidFill>
                <a:sysClr val="windowText" lastClr="000000"/>
              </a:solidFill>
            </a:rPr>
            <a:t>ดนประธาน</a:t>
          </a:r>

Changing lang to th-TH (Thai Thailand) makes Word to render the Thai text from left to right. The ar-SA value in the lang attribute affects the direction of Thai but not English. Since both Thai and English should be written using the same direction, this MS Word’s behavior is inconsistent. In addition, MS Word renders regular Thai with lang set to ar-SA from left to right.

    <w:p>
        <w:r>
            <w:rPr>
                <w:lang w:val="ar-SA" w:eastAsia="ar-SA" w:bidi="ar-SA"/>
            </w:rPr>
            <w:t>ดนประธาน</w:t>
        </w:r>
    </w:p>

We have concluded that Aspose.Words should not copy MS Word’s behavior for Thai text inside DML shape as it is inconsistent and incorrect.