Wrong conversion from Docx To Png with SaveAs in Aspose.Words.Java

tahir.manzoor · December 22, 2015, 10:07am

Hi Renato,

Thanks for your patience.

We have tested the same scenario on another Windows 7 system using Visual Studio 2008 and have not found the text bold issue. Please check the attached output Png. We have only changed the path of files in your code. Please check the following code snippet. While converting Docx to Png, we only found a warning message. See the attached image for detail.

HMODULE hJvmDll = LoadLibrary(L"C:\Program Files\Java\jdk1.8.0_60\jre\bin\server\jvm.dll");
options[0].optionString = "-Djava.class.path=e:/aspose-words-15.11.0-jdk16.jar;";
char* docFile = "e:/TestDocx.docx";
char* destFile= "e:/TestDocxConverted.png";

gianfranco.dancelli · December 22, 2015, 10:32am

Hi Tahir.

Thanks you so much for your effort.

Well, on our side we are wondering if we have to investigate differently.
We reproduce the issue with every C++ JNI application; instead every pure JAVA application works as expected.
You never reproduced the issue.

It’s very challenging, but we need a way to understand what is the difference between JNI and pure JAVA on our machines; maybe there is an environmental difference. Why JNI makes the application choose a different font style? Or if, the font is ok, why does the font rendering seem bold?

We’re wondering if debugging with OpenJDK makes sense. Or if it makes sense to hook every WinApi related to fonts (system font dir, font loading, font rendering, font measuring).

We’re wondering if, even if we are talking about Aspose-Words JAVA, on Windows there could be some native part belonging to the Aspose-Words JAR that could behave differently when running from JNI?

What’s your opinion?

Thanks again and regards,

Renato

tahir.manzoor · December 23, 2015, 10:33am

Hi Renato,

Thanks for your inquiry. Could you please open the command prompt and execute “Java -version” command and share the complete java version detail?

We are in communication with the product team about your query. We will get back to you soon.

gianfranco.dancelli · January 7, 2016, 2:04am

Hi Tahir,
this is the complete java version detail:

C:\Users>Java -version
java version “1.8.0_66”
Java™ SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot™ 64-Bit Server VM (build 25.66-b18, mixed mode)

Thanks once more for support.

tahir.manzoor · January 8, 2016, 12:46am

Hi Renato,

Thanks for sharing the detail. We will let you know once there is any update available about your issue from our product team.

aspose.notifier · May 11, 2016, 11:07pm

The issues you have found earlier (filed as WORDSJAVA-1249) have been fixed in this .NET update and this Java update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.

isispapyrusdev1 · March 22, 2017, 11:23am

Just copying here what talked abut in the priority support (likely the subscription won’t be renewed).

Raise priority and fix WORDSJAVA-1249 - Font forced to be bold if DOCX or HTML saved to Image via JNI

Hello.

I’m very sorry to ask again for such issue (WORDSJAVA-1249), but actually the fix you kindly provided since version 16.4.0 of aspose-words for Java didn’t solved. Here the old thread.
This is a very critical problem, since currently we have to save the docx or html file to PDF and then use another tool to get the derired page as an image. This is a very slow process.
Linked a small project C++ reproducing the problem. Luckily, the issue now happens on every Windows 10 machine, whilst in the past I could only experiment on Window 7 machines and only on a few of them the issue was reproducible.

BTW, there are some issues still open since tenths of months, and I begin to have some difficulties explaining such delay, above all while the renewal is so closed.

Thank you so much for your help.

Regards,

Renato
Hello again.

Here attached you may find the sample C program that loads the JVM via JNI and save the input file. In the ‘debug’ folder there are the two input files (htm and docx) and some PNG generated with the sample program. It’s easy to see how fonts Verdana and Tahoma are rendered in bold instead of regular.

System: Windows 10 64 bit
JRE: always the last stable downloadable
aspose-words: from 16.4.0 up to 17.2.0
Visual Studio: VS 2008 and VS2015

Thank you again.

Regards,

Renato

Hello Renato,

Please notice we were not aware that the issue was not fixed for you. Sorry for the inconvenience.

I am trying to run the sample program, but after setting of paths and linker, I get the error on execution on line 25:

“Unhandled exception at 0x71AAD9C1 in TestAsposeJNI.exe: 0xC0000005: Access violation executing location 0x00000000.”

Please check the attached screenshot. I suppose you can execute the application on your side without error?

Thanks,
Boris Pazin
Enterprise Lead,
Aspose
Yes, please add to the environment path variable the path to the JVM.DLL of your JRE.

Then, please put the aspose-word jar in the solution folder.
Finally, please check the path to the input file.

Hi Renato,

Thank you for providing additional information.

We are working on this issue and will get back to you soon.

Thanks,
Boris Pazin
Enterprise Lead,
Aspose
Hi Boris.

Finally we find solved the problem: the JVM must be started passing also the option -Dfile.encoding=UTF-8.

Since 1) the C code instatiating the JVM didn’t pass it, it failed to convert Verdana fonts, and 2) running from NetBeans worked, we wrongly thought it was a JNI issue.
Then, we tried to run a jar from the command line (java.exe - jar …) and it failed with Verdana!
So finally we checked the command line of NetBeans and found that it passes such option.

Do you or your team have any consideration about such detail? And, is there any other option that it’s better (say, mandatory) to set to run aspose-words properly?

Thank you.

Regards,

Renato

Hi Renato,

I am glad you figured it out.

By default, character set for JVM is depending of operating system and that explains why it worked correctly on some computers, while didn’t work on others.

We had some rare cases where issues related to not supported encoding are resolved by adding -Dfile.encoding=UTF-8, but it’s not mandatory.

Best Regards,
Boris Pazin
Enterprise Lead,
Aspose
Hi Boris.

Yes, sure it was complex, and some questions arise:
we are wondering how Aspose is handling such subject. Is there any hint about it in the documentation?
does Aspose development team know exactly what is happening in our specific case, passing or not that option? Please, consider that there is no evidence of this kind of problems at run-time, such as exceptions or error messages.
since there were some similar, although rare, cases with the same solution, does Aspose have a guideline or a best practice about this aspect?
is there any further JVM option that Aspose advises to set, to avoid any other rare case?
Thank you for your time.

Regards,

Renato

Hi Renato,

Thank you for your questions.

We don’t have anything about this subject in documentation. Please notice that very few users are calling Java from C++.
Since it is probably encoding problem, it could be that font on problematic machine doesn’t have required glyphs, or in some other way can’t be used in default encoding. If Aspose.Words can’t use some font or only some glyphs for any reason (font is not available, doesn’t support certain encoding, not enough rights to load it etc.), they are replaced with other font. The font substitution explains why text looks different in output.
If certain encoding is not supported, we suggest to try it with -Dfile.encoding=UTF-8.
We don’t advise any JVM option to be set. Products should work with any settings. But in specific scenarios, it could be needed to adjust JVM options. Typical example is if you work with very large files, then you could use -Xms and -Xmx options to increase available memory.

Thanks,
Boris Pazin
Enterprise Lead,
Aspose
Hi Boris.

Thank you for your answers.

About question 1, please, consider that the problem occurs also running from pure JAVA.

I’d like to talk some more about point two. In this very case, what happens is different than a simple font substitution, for three reasons:
such substitution happens only saving as an image, whilst saving as PDF everything is OK. This makes us suppose that aspose-words has two different engines, also for the input parsing phase, and the image engine is less robust than the PDF one;
the font substitution does not happen as usual, in fact no font-substitution call back is called;
even assuming that the font substitution happens for some encoding or glyph problem, it’s very strange that the consequence is a style corruption, that makes a regular text run become bold.

So, it seems that the image engine, for whatever reason, does not split the input text into the right number of text runs. Sure, that option solves and this is good.

Thanks for the details shared in answer 4.

Regards,

Renato
Hi Renato,

Thank you for your comments.

I am sharing this with the team, and will get back to you when we have more details.

Thanks,
Boris Pazin
Enterprise Lead,
Aspose

tahir.manzoor · March 23, 2017, 3:57am

Hi Renato,

Thanks for your inquiry. Unfortunately, there no update available from our product team yet. We will inform you once there is any update available about your query from our product team .

Thanks for your patience.