Free Support Forum - aspose.com

Question on Aspose unintentional number bulleting

A function of our application builds an RTF file from text (which is sent to us), and we use Aspose in the function.
We found that when the received text looks like bullets, the resulting RTF will show this as bullets, even when they are not.
For example a text of:

  1. some data.
    2.7 cm.

Will result in RTF showing:

  1.   some data.
    
  2.   7 cm.
    

Is this expected behavior, or a bug in the Aspose conversion method?
Is there a way to stop the bulleting entirely? Some other workaround?

Thanks.

@Aryef,

Please compress the following resources into ZIP format and attach the .zip file here for testing:

  • A simplified source Text file
  • RTF document showing the undesired behavior
  • Please also create a standalone simplified Console Application (source code without compilation errors) that helps us to reproduce this problem on our end and attach it here for testing. Please do not include DLL files in it to reduce the file size.

As soon as you get these pieces of information ready, we will then start investigation into your particular issue and provide you more information.

Hi, thank you for the assistance.
Unfortunately I am without development support to compile the requested simulation app.
However, I can offer a description of the code used:

  1. Text file - in the attached .zip
  2. RTF output - in the attached .zip

IN&OUTfiles.zip (1.7 KB)

  1. Function code:
using System;
using System.Text;
using Kodak.RISr2.Interface;
using Kodak.RISr2.Mapper.MappingFunctions;
using r2DocumentConverter;

namespace r2MappingFunctions.MappingFunctions
{
    public class ConvertFromTextToRTFUsingAspose : BaseMappingFunction
    {
		private static string Font = r2iConfiguration.Instance.ExternalReportingDefaultRTFConvertFont;

        public override string getTag()
        {
            return "{convertFromTextToRTFUsingAspose}";
        }

		public override string getValue()
		{
			return getDATAFromDoc(System.Text.Encoding.UTF8.GetBytes(Arguments["text"]));
		}

		public static string getDATAFromDoc(byte[] docBytes)
		{
			string strReturnvalue = "";
			
			try
			{
				Doc2PdfConverter.GetInstance().performAsposeLicenceLoad();
				byte[] RTFDoc = Doc2PdfConverter.GetInstance().convertRightNowWithEncodingAndFont(docBytes, Doc2PdfConverter.ConversionMethodType.Aspose, Doc2PdfConverter.DocumentFormat.Rtf, Encoding.UTF8, Font);
				strReturnvalue = System.Text.Encoding.UTF8.GetString(RTFDoc);

				int tmp = strReturnvalue.LastIndexOf('}');
				if (tmp < strReturnvalue.Length - 1)
				{
					strReturnvalue = strReturnvalue.Remove(tmp + 1);
				}
			}
			catch (Exception e)
			{
				strReturnvalue = e.StackTrace + "\n" + e.Message;
			}

			return strReturnvalue;
		}
	}
}

Would that be sufficient?
Thank you.
Arye.

@Aryef,

The RTF file “resulting_rtf.rtf” that you shared was actually produced by using an old 20.9 version of Aspose.Words for .NET. Please upgrade to the latest (21.6) version of Aspose.Words for .NET and see how it goes on your end? In case the problem still remains, then we need a simplified Console Application (source code without compilation errors ) to be able to reproduce this problem on our end. Also, we get this RTF file (21.6.zip (1.3 KB)) when converting this .txt to .rtf format by using the following simple code:

Document doc = new Document("C:\\Temp\\IN&OUTfiles\\Input_text.txt");
doc.Save("C:\\Temp\\IN&OUTfiles\\21.6.rtf");

Hi.
Thanks a lot for the reply.
Please a question - is the issue reproducible in your lab on 20.9?
Is 21.6 fixes a known bug in this area?
Thank you.

@Aryef

I am afraid, I am even not able to reproduce this problem when using 20.9 version on my end (see 20.9.zip (1.3 KB)). Can you please provide a simplified Console Application (source code without compilation errors) to be able to reproduce this problem on my end. Thanks for your cooperation.

Hi.
If it was not reproduced on 20.9, I am doubtful that the issue resolution could be 21.6.
Thank you.

@Aryef,

Unfortunately, it is difficult to say what the actual problem is without the source code (simplified but complete console application). We need this console application to be able to reproduce the exact problem on our end.