@yuriy.mazurchuk : Also its not for supporting new accesibility but to prevent the merged pdf from loosing already exisitng accessibility of pdfs.
Hi @pankajgupta !
Yes, you are right - the library will no longer lose existing accessibility. The release will be published within a few days - once we retest all changes and deploy it. I will notify here.
@yuriy.mazurchuk : Thank you. Could you please confirm on release date, that will help us plan our deliverables. Also, Could please verify the bug with attached docs in above threads?
hi yuri,
Please try to push it in the july release, because there are multiple high value customers waiting on this feature
Hi @amitdash , @pankajgupta !
The fixes are done in .NET and Java versions, we are running various tests and regressions to ensure for product stability. We plan to deploy the release early next week.
Thanks @yuriy.mazurchuk : Will verify with the latest version. Please notify us whenever it is available for consumption and the version number.
Hi @pankajgupta !
Please be aware that July 25.7 release was deployed with fix
https://releases.groupdocs.com/java/repo/com/groupdocs/groupdocs-merger/25.7/
For the upcoming months we plan to implement additional fixes for the missing tags and include these fixes into .net and java releases as well.
Thank you!
Hi @yuriy.mazurchuk : I checked the merged file for the attached pdfs above with above provided 25.7 and still it has all accessibility lost compared to original docs. I can see only Bookmarks have passed when compared to old one. Please find the attached report.
cc: @amitdash
response.pdf (548.7 KB)
Screenshot 2025-07-25 at 5.31.41 PM.jpg (268.6 KB)
Hi @pankajgupta !
Thank you for the detailed update and report.
Let me analyze it and get back with the estimation of a more accurate fix delivery.
Thank you!
hi yuriy,
Please note that this is a critical issue for us and the customer is awaiting a fix. Please let us know the fix date at the earliest.
Hello,
We have tested the merging process using version 25.7 with the 7 PDF files you previously provided. The result was produced without any of the errors you mentioned.
If you used different documents for your recent test, please share them with us so we can investigate further.
Below is the code sample adapted to your case that we used during our testing:
import com.groupdocs.merger.Merger;
import com.groupdocs.merger.options.JoinOptions;
import java.io.*;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.List;
public class PdfMergerApp {
public static void main(String[] args) throws IOException {
List<String> pdfFilePaths = List.of(
"Condizioni_Generali_Fornitura_Estra.pdf",
"Informativa_Privacy_Qualita_Commerciale.pdf",
"Lettera_Accompagnamento_Plico_Contr.pdf",
"Modulo_Dati_Catastali_Estra.pdf",
"Modulo_Reclamo_Estra.pdf",
"Modulo_Ripensamento_Estra.pdf",
"Proposta_Fornitura_Estra_Luce.pdf"
);
List<byte[]> pdfByteArrays = new ArrayList<>();
for (String path : pdfFilePaths) {
byte[] bytes = Files.readAllBytes(Paths.get(path));
pdfByteArrays.add(bytes);
}
ByteArrayOutputStream mergedPdfOutputStream = new ByteArrayOutputStream();
try (InputStream firstPdfInputStream = new ByteArrayInputStream(pdfByteArrays.get(0))) {
Merger merger = new Merger(firstPdfInputStream);
for (int i = 1; i < pdfByteArrays.size(); i++) {
try (InputStream pdfInputStream = new ByteArrayInputStream(pdfByteArrays.get(i))) {
merger.join(pdfInputStream, new JoinOptions());
}
}
merger.save(mergedPdfOutputStream);
} catch (Exception e) {
throw new RuntimeException("Error 1", e);
}
try (FileOutputStream fos = new FileOutputStream("merged_output.pdf")) {
mergedPdfOutputStream.writeTo(fos);
}
}
}
merged_output.pdf (864,5 КБ)
Please let’s double check the difference in the source code and input files to find out the difference to reproduce the problematic output file.
So far we can not reproduce the output document with mentioned Accesibility issues.
Hey @AlekseiSemenchenko : It’s bit surprising. I tried again with the provided 25.7 Merge and with same files as attached above in Individual Pdfs.zip and the out put is attached here:
response (2).pdf (687.7 KB)
with report:
Screenshot 2025-07-29 at 7.06.35 PM.jpg (268.6 KB)
You can see our code above, i don’t see any difference technically. Can you help us what could be the possible reasons of failures in our case?
Also, the merged file attached by you has still couple of failures though thankfully most passed
Screenshot 2025-07-29 at 6.56.45 PM.png (493.8 KB)
Hi @AlekseiSemenchenko , i tried your code as well with merger 25.7. It seems still same accessibility failures for me.
Hi,
To ensure we’re analyzing the same scenario and understand why you’re seeing different results with the same product version,
let’s align our source code and environments using the shared GitHub repository.
Please download and run the test project from the provided repository on your setup.
Before executing, make sure to copy the following input files with exact file names into the /SampleFiles/pdf folder:
- Condizioni_Generali_Fornitura_Estra.pdf
- Informativa_Privacy_Qualita_Commerciale.pdf
- Lettera_Accompagnamento_Plico_Contr.pdf
- Modulo_Dati_Catastali_Estra.pdf
- Modulo_Reclamo_Estra.pdf
- Modulo_Ripensamento_Estra.pdf
- Proposta_Fornitura_Estra_Luce.pdf
We did not include them into public repository due to possible sensitive information.
Please note: the first source file passed to the constructor (e.g., Condizioni_Generali_Fornitura_Estra.pdf)
heavily influences the accessibility structure of the resulting document:
Merger merger = new Merger(firstPdfInputStream);
If this initial file contains accessibility issues, they may be propagated into the output file.
The two errors you mentioned are actually present in the original input files and were therefore carried over into the final merged result.
In your earlier attempt, we suspect the mismatch occurred due to either:
- an outdated or mismatched library version
- differences in input files (e.g., the previously generated output had 19 pages instead of 18), suggesting different source content or structure.
Looking ahead, the upcoming version 25.8 will include an optional automatic correction mechanism designed to detect and fix such structural issues during processing.
This feature should improve stability when dealing with input files that contain known accessibility or structure problems.
Let me know once you’ve run the test — we’ll be able to compare results more accurately then.
Thanks!
UPD Please share as much details about your environment as possible
- what is environment OS,
- Java version
hey @AlekseiSemenchenko
I used same code as provided by you with same sequence of files. still the result is not as you mentioned. It is retruning me same as above response (2).pdf
Regarding env details:
- what is environment OS : Mac and linux
- Java version: 17
Is it possible to have a joint call and let’s get it checked together once?
hey @AlekseiSemenchenko : I am able to merge file with same output as you. But somehow we feel relying on first file for meeting the max accessibility is not the right strategy. It should consider max of all files.
Hi @pankajgupta!
You’re correct — the current fix in version 25.7 is not the ideal long-term approach. Our priority was to provide you with a quick solution as soon as possible.
For the upcoming 25.8 release, we’re working on a more general solution that will preserve accessibility artifacts from all source pages, regardless of which files are merged, to achieve the highest possible accessibility compliance. As part of this effort, we’ll also verify whether the PDF standards allow transferring these accessibility artifacts from the source documents to the corresponding pages in the destination document.
We’ll keep you updated as we make progress.
Thank you for your feedback!
Hi @yuriy.mazurchuk , @AlekseiSemenchenko ,
We are encounttering :
error: error reading bazel-out/k8-fastbuild/bin/external/com/com/groupdocs/groupdocs-merger/25.7/header_groupdocs-merger-25.7.jar; Unsupported size: 16667311 for JarEntry META-INF/MANIFEST.MF. Allowed max size: 16000000 bytes. You can use the jdk.jar.maxSignatureFileSize system property to increase the default value.
similar to: Groupdocs comparison jar SignatureFileSize issue
Can you help us on it, we aren’t able to consume this version due to it’s size.
Hi @pankajgupta,
Thanks for flagging this. We’ve published 25.7.1, which resolves the
Unsupported size … META-INF/MANIFEST.MF (max 16000000)
error. Please update to 25.7.1 and let us know if everything works on your side.
Thank you @AlekseiSemenchenko for the quick response. I have verified in local for accessibility in 25.7.1 and it seems no side effect. We will pull it to dev env and share the feedback. thanks
1 Like