We have regressions in our Java software after updating Aspose a while back. We are currently using the latest Aspose version 20.8. The regression was caused due to comment range nodes being allowed in block-level nodes.
Question 2: Does anyone know if there is a simple way to prevent this behavior? I recall seeing an API in the past that might disable this new behavior, but I’m not sure if it works anymore or is available any longer. I will look into that some more shortly.
Thanks for any tips or suggestions on this one! I would prefer to simply switch off this behavior if possible or if there is a small programmatic solution, that would be helpful as well. I’m going to be looking into both options.
Note: The code is extending the DocumentVisitor and in visitBodyStart(), it iterates over the child nodes and now encounters an unexpected comment range start. I suppose I could simply force this node into the next adjacement paragraph node (but I don’t know it will be a paragraph node. It might be a table node that is next. What is the most general and straightforward way to revert the behavior to how it used to be?
I would be interested in ensuring none of the elements like bookmarks or comment ranges are allowed in block-level nodes ( on Block, Cell, Row Levels), so if the solution can handle all scenarios, that would be ideal.
Also, I think I found an error in the documentation. While reviewing Aspose.Words Document Object Model (DOM)|Aspose.Words for Java, I see that CommentRangeStart, CommentRangeEnd are listed as if they are inline-level nodes. It appears they are a hybrid now. They may be inside inline or block-level nodes. Should this be clarified?
I wasn’t able to find an API to turn off the new behavior. I’m just looking for advice on how to undo this when using the document visitor. Do I just need to relocate each CommentRangeStart, CommentRangeEnd to the next adjacent paragraph node if it’s not already in one (I am doubtful it is that simple)? Is this a safe change to make while the document visitor is executing or do I need to make the change prior to having the document visitor visit the document? Which other node types and situations should I consider that were also impacted by this change?
Starting from Aspose.Words 18.9, the bookmarks are allowed on block, cell, and row levels. In the previous versions, bookmarks were moved into the next nearest paragraph on document loading. However, it is not same for CommentRangeStart and CommentRangeEnd.
To ensure a timely and accurate response, please attach the following resources here for testing:
Your input Word document.
Please attach the output Word file that shows the undesired behavior.
Please attach the expected output Word file that shows the desired behavior.
Please create a simple console application ( source code without compilation errors ) that helps us to reproduce your problem on our end and attach it here for testing.
As soon as you get these pieces of information ready, we will start investigation into your issue and provide you more information. Thanks for your cooperation.
PS: To attach these resources, please zip and upload them.
Thank you. I am attaching Demo.zip which contains:
AsposeDemoFor137251.jar
forDefect137251.rtf
README.txt
It is packaged with the latest Aspose version 20.8.
Folder AsposeDemoFor137251_lib must contain aspose-words-20.8.0-jdk17.jar - I removed it so that upload wouldn’t hit the size limit.
The code is as follows:
public class AsposeDemo {
public static void main(String[] args) {
File inFile = new File("forDefect137251.rtf");
try {
System.out.println("Attempting to read: " + inFile.getCanonicalPath());
} catch (IOException e) {
throw new RuntimeException(e);
}
try (InputStream is = new FileInputStream(inFile)){
Document doc = new Document(is);
DocumentVisitor visitor = getDocumentVisitor();
doc.accept(visitor);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static DocumentVisitor getDocumentVisitor() {
return new DocumentVisitor() {
public int visitBodyStart(Body body) throws Exception {
NodeCollection childNodes = body.getChildNodes();
for (int i = 0; i < childNodes.getCount(); i++) {
Node currentNode = childNodes.get(i);
if (currentNode.getNodeType() == NodeType.COMMENT_RANGE_START) {
throw new RuntimeException("Unexpected node type encountered");
}
}
return VisitorAction.STOP;
}
};
}
}
From the discussion above, I understand it should not hit the line “throw new RuntimeException(“Unexpected node type encountered”);” However, this is what happens each time I run it. From what I can tell, this regressed in this range: (19.7, 20.6]. It was known to be working at v 19.7 and then confirmed as failing in v 20.6. I do not know the exact version where the behavior changed.
Please let me know if that is enough detail above. I was not able to provide an output file. The output is just a console exception message proving that the CommentRangeStart is directly in the Body node unlike in prior releases.
Would a suitable workaround in the short term be for us to move that range into the next adjacent paragraph or table? I can’t help but think there might be some other type of node besides paragraph or table that I might need to consider as well… Those are the 2 main ones I could think of. The workaround seems to work as expected.
Thank you @tahir.manzoor - Based on the analysis of the issue, do you know if the following would be a suitable workaround in the meantime? We might need a workaround in the meantime due to other time constraints:
Please note that the latest version of Aspose.Words imports the CommentRangeStart as block level node. You can use following code snippet to write your code according to your requirement. Hope this helps you.
NodeCollection childNodes = doc.getFirstSection().getBody().getChildNodes(NodeType.ANY, false);
for (int i = 0; i < childNodes.getCount(); i++) {
Node currentNode = childNodes.get(i);
if (currentNode.getNodeType() == NodeType.COMMENT_RANGE_START) {
if (currentNode.getParentNode().getNodeType() == NodeType.BODY)
{
//Your code...
}
}
}
@tahir.manzoor - Thank you. Just to make sure I understand this issue. It should not be a block level node? When the fix is delivered it will be treated as an in-line level node again, correct? That’s how it used to work.