- We are using below logic to getPageIndex for node,
public Integer getNodePage(Node node, LayoutCollector collector, LayoutEnumerator enumerator)
throws Exception {
Integer pageIndex = null;
double minSize = 2;
Object renderObject = collector.getEntity(node);
if (renderObject != null) {
enumerator.setCurrent(renderObject);
double pageHeight =
((Section) node.getAncestor(NodeType.SECTION)).getPageSetup().getPageHeight();
double pageWidth =
((Section) node.getAncestor(NodeType.SECTION)).getPageSetup().getPageWidth();
double x = enumerator.getRectangle().getX();
double y = enumerator.getRectangle().getY();
double width = enumerator.getRectangle().getWidth();
double height = enumerator.getRectangle().getHeight();
if (width > minSize
&& height > minSize
&& x + width > 0
&& y + height > 0
&& x <= pageWidth
&& y <= pageHeight) {
pageIndex = enumerator.getPageIndex();
}
}
return pageIndex;
}
- Above logic is not working for “Fig.2” shape node from attached document, it is returning pageIndex “2” instead of “1”.
- This code was working fine with aspose-words version 23.6 but after upgrade it to 23.7 it is breaking on ubuntu:18.04 only(which we are using for CI/CD), this is working fine on Mac.
- Could you please assist on this?
bookmarked_S0029801820300834.docx (50.1 KB)
@ELSSAM_elsevier_com The problem might occur because fonts used in your document are not available in the environment where you process the document.
As you may know, MS Word documents are flow documents and do not contain any information about document layout. The consumer applications, like MS Word or Open Office builds document layout on the fly. Aspose.Words uses it’s own layout engine to build document layout while rendering the document to fixed page formats (PDF, XPS, Image etc.). The same layout engine is used for providing document layout information via LayoutCollector
and LayoutEnumerator
classes.
To built proper document layout the fonts used in the original document are required. If Aspose.Words cannot find the fonts used in the document the fonts are substituted . This might lead into the layout difference (incorrect coordinates returned by LayoutEnumerator
), since substitution fonts might have different font metrics. You can implement IWarningCallback to get a notification when font substitution is performed.
Thanks @alexey.noskov , but then how same document is working with aspose-words 23.6 version?
@ELSSAM_elsevier_com Probably there were some fixes that changed layout building logic. But anyways to build accurate layout the fonts used in the document are required.
Would it be feasible to have all fonts because we receive documents on runtime?
Also are you planning fix for this broken layout?
@ELSSAM_elsevier_com The is no broken layout, so there is nothing to fix. Regarding the fonts, Aspose.Words does not provide any fonts, it uses the fonts available in your environment. So providing the fonts required to build document layout is out of Aspose.Words responsibilities.
@alexey.noskov , as I said earlier same document is working fine with aspose-words 23.6 version on same Ubuntu environment doesn’t mean it does not have issue with fonts?
Also @alexey.noskov , we have already implemented “IWarningCallback” in our code and I don’t see any difference in output of missing fonts warnings with aspose-words 23.6 and 23.7 version.
I am attaching screenshot of logs with both versions.
Let us know how we can proceed on this?
23.6_output:
23.7_output:
@ELSSAM_elsevier_com I cannot reproduce the problem on my side. As I have mentioned it is impossible to build accurate document layout without fonts used in the document. As you can see from your logs fronts used in your document are not available in the environment where the document is processed. So the fonts are substituted, that affects the document layout.
@alexey.noskov , have you tried to reproduce this on Ubuntu?
@ELSSAM_elsevier_com Yes, I have tested on Ubuntu and rendering is correct, if the required fonts are available.
1 Like
After providing fonts on build environment, now we are getting correct pageIndex.
We are good to close this issue.
Thanks a lot for suggestion @alexey.noskov !
1 Like