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

Free Support Forum - aspose.com

Mu character converting doc to html

Hi,

I have a word document with a mu character.
mu.zip (9.2 KB)
Aspose.words for java converts this to

<span style=“font-family:Symbol”></span>
with the symbol itself rendered as character “\uF06D”.

This does not display in our system, and this page http://www.fileformat.info/info/unicode/char/f06d/index.htm says it is an invalid unicode character

I expected the character to be rendered as “\u03BC” or &mu;

The character in the word document is a word Symbol, see screenshot: lmuCapture.PNG (13.3 KB)

Could you have a look into this please?

thanks
Steve

@steve1elsevier,

We tested the scenario and managed to reproduce the same problem on our end. For the sake of correction, we have logged this problem in our issue tracking system. The ID of this issue is WORDSNET-17994. We will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.

Hi Awais,
Thanks for logging this.

  1. I am unable to view the jira. Can you say when/if this issue will be fixed?
  2. If will not be fixed in the next month, can you suggest a coded workaround?
  3. I have tested a few more scenarios. I created a doc with upper and lower case chars in symbol font, and also with upper and lowercase chars created from the Symbols dialog in symbols font (similar to the mu in mu.zip). All of these characters failed to render correctly.
    I also found that the “micro” symbol in Arial font - which is the same glyph as a Greek mu renders correctly as the micro character (181 in decimal. 0xB5 in hex).
    So its not just an issue with the special characters from symbols dialog, (and not just a problem with mu). There does seem to be an issue with the Symbols font in particular. I can’t say if the problem is more extensive than this. Hope this is of use.

I attach new document with these test cases symbols.zip (10.2 KB).

thanks
Steve

@steve1elsevier,

  1. Unfortunately, there is no direct way that you can use to track issues by yourself. But, you are welcome to ask your issue status via forum threads. We will verify the status from our internal issue tracking system and reply you back.

  2. Your issue is currently pending for analysis and is in the queue. We will inform you via this thread as soon as this issue is resolved or any workaround is available.

  3. We tested the scenario and managed to reproduce the same problem on our end. For the sake of correction, we have logged this problem in our issue tracking system. The ID of this issue is WORDSNET-17997. We will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.

@steve1elsevier,

Regarding WORDSNET-17994, you said that on your system the symbol is not displayed but most browsers on Windows do display it correctly on our end. Please also share the complete environment details (e.g. OS, Web browser, JDK versions etc) of the machine you are getting this problem on. Thanks for your cooperation.

@awais.hafeez
Thanks for this. I have had another look into exactly what’s happening and I now think that this issue is caused by a rendering bug at our end. Apologies for that.

@steve1elsevier,

Thanks for the details. We will keep you posted on any further updates on the linked issues.

@steve1elsevier,

Regarding WORDSNET-17997, please also check if this issue is the same as WORDSNET-17994 and it is also caused by a rendering bug on your end?

Hi Awais,
I can’t view your jira instance, so I can’t be certain. However I think these are the same issue. The mu/micro symbol in the first report was one of the set of symbols in the second report.

hope this helps

@steve1elsevier,

We believe that WORDSNET-17997 is duplicate of WORDSNET-17994 and have closed both of these issues. There is nothing to fix in Aspose.Words API. If we can help you with anything else, please feel free to ask.

The issues you have found earlier (filed as WORDSNET-16496) have been fixed in this update