We were able to replicate the issue in our environment and logged it as PAGEJAVA-85 in our issue tracking system. We will further look into details of this issue and keep you posted with the status of its correction. Please be patient and spare us little time.
We are sorry for the inconvenience.
The issues you have found earlier (filed as PAGEJAVA-85) have been fixed in Aspose.Page for Java 20.1.
I encountered the same problem again, the file is attached…
yes, Can the program output the log to a file after the program reports an error? The detailed content is, for example, the file name of the processing error, the corresponding error content, so that we can find the problem.
We have tested the scenario in our environment with your all 3 files and noticed that program kept running and did not end with any result. Hence we have logged following issues in our issue tracking system:
We have also mentioned your above concerns along with the logged tickets and will share updates with you as soon as we have some regarding their resolution. Please be patient and spare us some time.
We are sorry for the inconvenience.
338ed76a-7a1c-421b-a4dc-18a2fef86f06.xps、e7d934a7-12d4-4418-b3bc-ea47ee7f8c0e.xps，Handle watermark error 。。
We again tried the scenario and noticed that out of memory exception occurs after 30 mins of code running. We have updated the issue information accordingly.
We tried to download the files but it gave 404 Not Found error. Would you please share the correct link to download the files.
The issues you have found earlier (filed as PAGEJAVA-91,PAGEJAVA-92,PAGEJAVA-93) have been fixed in Aspose.Page for Java 20.4.
Adding more to notification of bug fixes, you might have noticed that the sample files are somewhat irregular XPS documents, since they contain no real text. All the glyphs are rendered into paths. It seems like these files are the result of printing some document with Mircosoft XPS document writer. This is the reason why these file are quite large, although not consisting of any enormous number of pages.
Instead, they contain the very large amount of paths (order of several millions) and points (a few times more than paths).
So, basically, there is no wonder why JVM hangs or gets crushed, since due to particular reasons we have to load the entire document into memory before we start to save it. One reason is that we have to handle internal hyperlinks, if they are present in a document.
Nevertheless, this time it was possible to reduce memory consumption to some extent. But how effective this fix is depends on a specific environment. Anyway, we must keep in mind that if it will work fine with these sample files, there’s absolutely no guarantee that it will work with similar documents with, say, 700, 800 or 1000 pages.
We have also received another link to 2 XPS files from you. Would you please share if you are facing similar issue with them?
338ed76a-7a1c-421b-a4dc-18a2fef86f06.xps、e7d934a7-12d4-4418-b3bc-ea47ee7f8c0e.xps
Are these two files？
20.4 version of the API includes fixes against the above issues which were logged for out of memory exception. For the files (338ed76a-7a1c-421b-a4dc-18a2fef86f06.xps.e7d934a7-12d4-4418-b3bc-ea47ee7f8c0e.xps), separate issues have been logged in our issue tracking system as following:
We will surely inform you as soon as they are resolved. Please spare us some time.
Is there any new progress！！
Regretfully, the above-logged tickets are not yet resolved. We will let you know as soon as we make some definite progress towards their resolution. Please be patient and give us some time.
We are sorry for the inconvenience.
Has the problem been solved?
We have performed an investigation against the ticket IDs PAGEJAVA-107 and PAGEJAVA-108. We noticed that the source XPS document (19th page) is an invalid one and this causes the exception. Would you please share what type of behavior would you expect in such case from the API?
I don’t understand how to deal with this situation. Do you have any good suggestions.
At the moment, the API is throwing an exception in case of invalid page in the file. We can add more description to the thrown exception after further investigating it.