PDF Document radio buttons are jagged when saved as pdf

we are using aspose words/ java to generate word documents and also save pdf documents from the same code stream. when we insert html radio buttons into the word document the fidelity is good and they look like radio buttons. when the same code is saved as a PDF, the radio buttons appear jagged. Is there a way to improve the fidelity of the radio buttons when saved as a PDF ?

Here is an image comparison as well as source code and output.
image.png (29.1 KB)
radioissue.pdf (17.7 KB)
Temp.zip (31.5 KB)

@paul.calhoun,

Thanks for your inquiry. We tested the scenario and have 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-17047. 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.

I have contacted sales about purchasing support for the three open tickets I have with Aspose Words/Java. in their response they stated

“… we would encourage you to ask the Support Team on the thread if buying the Paid Support will be advantageous in your case.”

So that’s what I am doing. Will purchasing support be advantageous for these three open tickets and provide us a quicker response?

@paul.calhoun,

We will check if raising the priority of this issue (WORDSNET-17047) to Paid Support will help to implement the fix of this issue faster? We will keep you posted on further updates.

Please also share the thread links of your other two issue that you want to check.

Here are the other two open tickets

WORDSNET-16730
WORDSNET-16844

@paul.calhoun,

The fix of WORDSNET-16730 will be available in next 18.7 version of Aspose.Words.

We will also check if raising the priority of issue (WORDSNET-16844) to Paid Support will help to implement the fix of this issue faster? We will keep you posted on further updates.

I have not heard back from you on this issue to whether purchasing support will get the above open ticket (16844) escalated to be fixed in a timely fashion. We need to make a decision on what our options are as soon as possible.

@paul.calhoun,

I am afraid, raising the priority of this issue (WORDSNET-17047) to Priority or Enterprise Support level will not help to implement the fix of this issue faster. We are still investigating the best possible way to fix it. Much deeper research is required. Rest assured, we will inform you via this thread as soon as this issue is resolved. We apologize for your inconvenience.

WORDSNET-16730 has been resolved in 18.7 version. The next version of Aspose.Words for Java i.e. 18.7 will be released in next 2-3 days.

Regarding WORDSNET-16844, please follow this thread for further proceedings.

So for us, this is MORE than an inconvenience. This is PREVENTING US from using an ASPOSE solution in our production system. We are production legal documents and while it might seem trivial to ya’ll that the radio buttons are not perfect circles, to lawyers it jumps out as being VERY UNPROFESSIONAL.

I find it exasperating to say the least that ya’ll are not able to provide us ANY time frame on the resolution of this issue.

I’m VERY concerned that what this really means is it is a LOW priority and will not be given much time an attention.

I am ALSO confused why escalating this to Priority or Enterprise Support would NOT reduce the amount of time to fix this issue.

We very MUCH WANT to use your product, but you are making it increasingly difficult justify the cost based upon having to wait MONTHS for fix’s to be implemented.

And a reminder, while this is FREE support, we are PAYING customers.

@paul.calhoun,

The radio button in the source document is represented by object. For this object “shape” and “control” elements are specified. The shape has the specified imageData (image.png, this image is rendered when converting to PDF). And the control has the specified ActiveX.xml. Unfortunately, Aspose.Words currently cannot render the ActiveX element, and uses the shape image.

If we disable ActiveX in MS Word, the result will be the same as produced by Aspose.Words (see msw-2016-after-disable-ActiveX.pdf (7.4 KB)).

Your issue (WORDSNET-17047) depends upon the resolution of internal issue WORDSNET-13250. The problem (WORDSNET-13250) actually requires us to implement a new feature in Aspose.Words and we regret to share with you that implementation of this new feature has been postponed for now because of complexity. Therefore, WORDSNET-17047 is postponed until at least WORDSNET-13250 is resolved, we will review your issue after the resolution of WORDSNET-13250.

We have also noted your concerns and in the meantime while you are waiting for a fix, we may be able to calculate estimates (time frame) for your issue and share workaround with you. We will keep you informed of any further updates. We apologize for your inconvenience.

@paul.calhoun,

Moreover, there are two approaches to render ActiveX objects. The first is to instantiate the proper ActiveX server (radio button ActiveX control in this case) and ask it to render the control. The second is to simply use the image saved in ActiveX object description.

MS Word uses the first approach, because it has all the MS Windows controls at its disposal, while Aspose.Words uses the second one, since its multi-platform nature (ActiveX controls are not cross-platform). Normally, this approach works without any issue, so we consider this case (WORDSNET-17047) an exception.

Your source document contains two images for radio button ActiveX control (see attached “image1.png” and “image2.png”). As you can see, Aspose.Words renders them correctly.

As a simple workaround you can try to fix the document with MS Word 2016 (at least). When you open it in MS Word 2016, you will see that compatibility mode is enabled. If you choose “File/Convert” in the main menu, or simply re-save the document, MS Word replaces radio button images with metafiles (see attached “image1.wmf” and “image2.wmf”) and Aspose.Words uses them while rendering. In this case PDF output is much better.

attachment.zip (1.2 KB)

But this option can not be implemented programmatically, correct ?

Opening and re-sarving the documents is not really an option for us.

@paul.calhoun,

I am afraid, currently there is no programmatic work around available for this issue. We will keep you posted on any further updates.

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