Posted 7 June 2024, 5:20 am EST - Updated 7 June 2024, 5:25 am EST
Bad Printing Quality after Upgrade AR11 -> AR17
Posted by: travis.beltrametti on 7 June 2024, 5:20 am EST
-
travis.beltrametti
-
anand.sinha
Posted 10 June 2024, 3:51 am EST
Hi Travis,
As far as the image is concerned if this issue does not occur when you preview the report on your system then it is very likely that this issue is specific to the printer/printer drivers.
However, could you please try upgrading to the latest version of ActiveReports 17 from here Download Version History and test if the issue persists?
If the issue persists please try sharing a sample that replicates this issue so we can test the same on our end and further investigate the same.
Regards,
Anand -
travis.beltrametti
Posted 10 June 2024, 10:04 am EST
Hi Anand
It cannot be specific to the printer drivers because it behaves differently on the exact same system with the exact same report but different versions of AR. We cannot change printer settings for all of our 1000 customers to make it work. It’s either a bug or a setting which we are unaware of.
Nonetheless, I’ll try to update to latest hotfix.
-
anand.sinha
Posted 11 June 2024, 1:12 am EST
Hi Travis,
Sure, please do let us know your observations after updating to the latest version of ActiveReports 17 and if the issue persists please try sharing a minimal sample that replicates the issue so we can test the same on our end and further investigate the issue.
Regards,
Anand -
travis.beltrametti
Posted 11 June 2024, 8:13 am EST
Unfortunately upgrading to 17.3 didn’t help. The quality is bad. I made a test to reproduce. Of course you would need a receipt printer to test this.
-
anand.sinha
Posted 12 June 2024, 5:11 am EST
Hi Travis,
We tried printing your reports using both of your Bad/Good print projects and there does not seem to be much difference between the prints (see attached image).
However, as we do not have a receipt printer to test the issue with therefore we have escalated this issue to our development team with Ticket ID: AR-33654 and will let you know of any updates we get from them.
Regards,
Anand -
anand.sinha
Posted 13 June 2024, 7:22 am EST
Hi Travis,
As per the development team ActiveReports from version 13 onwards rendered text as images using DsDocs/GcDocs instead of GDI+ to make the reports WYSIWYG, unfortunately, we cannot revert back to GDI+ as it has a lot of problems but they have suggested that you may try using different fonts or use custom fonts which seems appropriate for your requirements.
Apologies for the inconvenience.
Regards,
Anand -
travis.beltrametti
Posted 14 June 2024, 2:38 pm EST
That are indeed bad news :-(. Aren’t there any settings to improve the quality?
-
katyayny.raghuvanshi
Posted 17 June 2024, 11:56 pm EST
Hi Travis,
We understand your concern, but as per our development team, the workaround for this issue would be to use different fonts.
We appreciate your understanding!
-
travis.beltrametti
Posted 16 September 2024, 4:27 am EST - Updated 16 September 2024, 4:32 am EST
Hi Team
I need to roll up this issue, as it generates a lot of problems for all of our customers. Any other people having this issue? Using a different font doesn’t really seem the solution - we are using Arial, and I expect a simple report with Arial being printed correctly on a receipt printer.
This is really a serious degradation, I would expect the quality to be at least the same or better on a newer product, but not worse.
Can you please esaclate a fix for this issue?
-
katyayny.raghuvanshi
Posted 17 September 2024, 6:46 am EST
Hi Travis,
We understand your concern. Could you please try out the following suggestions and let us know if they help:
- Try exporting your reports to PDF and then try printing the same. You may refer to the attached documentation for the same: https://developer.mescius.com/activereportsnet/docs/versions/v17/online/pdf-export-page-rdl.html
- Try upgrading to ActiveReports 18 to check if the issue persists in the latest version or not
If the issue still persists, please provide us with your environment details/printer details so that we can request our development team to provide support for GDI+ (if possible) for the same. Please note that if this happens, the request will be escalated to our PMs, and the fix might be available in the v20+ versions.
-
travis.beltrametti
Posted 24 May 2025, 2:30 am EST
Just a quick heads-up, was this fixed in any version > 17?
Thanks
-
anand.sinha
Posted 26 May 2025, 4:10 am EST
Hi Travis,
Unfortunately, the issue has not been fixed. However, the development team has mentioned that as a workaround, you can use Adobe to print by customizing your print button.
They have shared the following code snippet:var viewer = new GrapeCity.ActiveReports.Viewer.Win.Viewer(); var tempFiles = new System.Collections.Generic.HashSet<string>(); var oldPrintButton = (System.Windows.Forms.ToolStripButton)viewer.Toolbar.ToolStrip.Items[2]; var newPrintButton = new System.Windows.Forms.ToolStripButton(oldPrintButton.Text, oldPrintButton.Image, (_, _) => { // Disable user interaction viewer.UseWaitCursor = true; new System.Threading.Tasks.Task(() => { var tempFileName = System.Guid.NewGuid().ToString("N"); var fullPdfTempPath = System.IO.Path.Combine(System.IO.Path.GetTempPath(), tempFileName + ".pdf"); tempFiles.Add(fullPdfTempPath); // Export to PDF file if (viewer.OpenedReport == GrapeCity.Viewer.Common.ViewModel.OpenedReport.Section) viewer.Export(new GrapeCity.ActiveReports.Export.Pdf.Section.PdfExport(), new System.IO.FileInfo(fullPdfTempPath)); else viewer.Render(new GrapeCity.ActiveReports.Export.Pdf.Page.PdfRenderingExtension(), new GrapeCity.ActiveReports.Rendering.IO.FileStreamProvider(new System.IO.DirectoryInfo(System.IO.Path.GetTempPath()), tempFileName) { OverwriteOutputFile = true }, null); // Enable user interaction viewer.BeginInvoke(new System.Windows.Forms.MethodInvoker(() => viewer.UseWaitCursor = false)); // Print result PDF file with default printer - required Adobe Acrobat installed new System.Diagnostics.Process { StartInfo = new System.Diagnostics.ProcessStartInfo { UseShellExecute = true, CreateNoWindow = true, //Verb = "print", FileName = fullPdfTempPath } }.Start(); // Process }).Start(); // Task }, oldPrintButton.Name); newPrintButton.Size = oldPrintButton.Size; newPrintButton.ImageTransparentColor = oldPrintButton.ImageTransparentColor; newPrintButton.ToolTipText = oldPrintButton.ToolTipText; // Replace the "Print" button viewer.Toolbar.ToolStrip.Items.RemoveAt(2); viewer.Toolbar.ToolStrip.Items.Insert(2, newPrintButton); // Disable the build-in print shortcut viewer.SetShortcutCommandState(GrapeCity.ActiveReports.Viewer.Win.ViewerCommand.Print, false); // Manage the "Print" button state newPrintButton.Enabled = false; viewer.RefreshReport += (_, _) => viewer.BeginInvoke(new System.Windows.Forms.MethodInvoker(() => newPrintButton.Enabled = false)); viewer.ErrorOccured += (_, _) => viewer.BeginInvoke(new System.Windows.Forms.MethodInvoker(() => newPrintButton.Enabled = false)); viewer.LoadCompleted += (_, _) => viewer.BeginInvoke(new System.Windows.Forms.MethodInvoker(() => newPrintButton.Enabled = viewer.CanExport && System.Drawing.Printing.PrinterSettings.InstalledPrinters.Count > 0)); FormClosing += (_, _) => { foreach (var tempFile in tempFiles) try { System.IO.File.Delete(tempFile); } catch { } };Regards,
Anand -
travis.beltrametti
Posted 26 May 2025, 4:17 am EST
Hi Anand
Thanks for your answer and the workaround. Unfortunately this is not an option, because we cannot ensure Adobe is installed and also need to insist on high printing speed. We don’t want to buy a or use a product that depends on other products to be installed.
Can you keep the dev team posted? Thank you.
-
travis.beltrametti
Posted 4 November 2025, 3:33 pm EST
We’d like to purchase another AR license, but are unsure if this issue will be fixed? Since our product is in POS field, there is the need to be able to print a good quality report on a receipt printer.
Could you give us an idea if this will be fixed and if we can count on AR in the future?
-
anand.sinha
Posted 7 November 2025, 1:28 am EST
Hi Travis,
The developers have mentioned that the next release of ActiveReports, i.e., ActiveReports v20, introduces Direct2D printing, which can help in resolving your issue.
Regards,
Anand -
travis.beltrametti
Posted 7 November 2025, 11:43 am EST
Ok, do you have a timeline when we could start testing? Also a prerelease / beta would be helpful to find out if the issue is resolved for us.
Thank you
-
anand.sinha
Posted 10 November 2025, 1:52 am EST
Hi Travis,
ActiveReports v20 is expected to be released in mid-end of the first quarter of 2026, around February. We’ll keep you updated.
Regarding a prerelease/beta version, we have asked our development team if it would be possible to share it and a timeline for when that would be available. We’ll let you know about any updates regarding the same.
Thanks,
Anand -
julien.iseli
Posted 1 May 2026, 3:16 am EST - Updated 1 May 2026, 3:22 am EST
Hi Anand,
I’m taking over regarding this issue. As we can see in the attached photo, the text printed from ActiveReports Designer v17 appears to be slightly shrunk compared to text of the same size printed from MS Word. We can also see that the print quality is degraded most probably because of the shrinking.
The paper size is correctly configured, the margins are set to 0, and the CanShrink properties are set to FALSE. The printer’s “Reduced size print” setting (EPSON TM‑m30III) is configured to “Do not reduce”.
Do you have any idea where this shrinking might be coming from?
-
anand.sinha
Posted 4 May 2026, 5:15 am EST
Hi Julien,
As mentioned above, ActiveReports 20 introduces Direct2D printing, which may help mitigate your issue.
Could you please try upgrading your project to ActiveReports 20 and see if the issue persists?
You may download ActiveReports 20 from here: Download ActiveReports.If the issue persists, please try sharing a minimal, replicable sample so we can reproduce the issue on our end and further investigate the same. Also please tell us more about the environment, font, paper and printer details on which the issue is being reproduced.
Thanks,
Anand -
julien.iseli
Posted 19 May 2026, 3:20 am EST
Hi Anand,
Thanks for your feedback. It does indeed look better with version 20 (apart from a margin issue to look into). Still not as good as native printing but good enough for our use case. Unfortunately, license got expired while I was away, preventing us from conducting all necessary tests. Would it be possible to extend our trial period?
Please let me know.
Julien
-
anand.sinha
Posted 19 May 2026, 5:20 am EST
Hi Julien,
As this is a public forum sharing a key won’t be feasible here. Therefore, we’ll request you to get in touch with our our sales team and request an extension on your trial period.
You can contact our sales team at activereports.sales@mescius.com or call 1.800.858.2739.
Regards,
Anand -
julien.iseli
Posted 29 May 2026, 3:59 am EST - Updated 29 May 2026, 4:05 am EST
Hi Anand,
Good news, upgrading to v20 with the trial has improved the print quality.
However, we are now encountering a new issue: the report is being cut off on the left side, as shown in the attached image.
The report itself has a left margin of 0.3 cm, which has remained unchanged between the v17 and v20 prints.
Ideally, we would like to resolve this without modifying the reports themselves, as they are custom-built by customers and there are too many to update individually.
Do you know if there is a setting or configuration in the code that we can adjust to prevent this issue?
-
anand.sinha
Posted 1 June 2026, 1:24 am EST
Hi Julien,
This feels weird, as ActiveReports.NET does not have any provision for adding a negative margin, so logically, you can never make controls cut off on the left.
This leads us to believe that the issue may be specific to the print API or the printer. To debug the exact cause of the issue, we’ll need a reproducible sample. Could you please share a minimal, replicable sample so we can test the issue on our and and further investigate the same?
Thanks,
Anand -
travis.beltrametti
Posted 5 June 2026, 2:31 am EST
Hi Anand,
After further investigation, we identified that the latest version of the library no longer automatically compensates for the printer’s non-printable area (hard-margin). We have updated our code to account for this behavior, and it is now working as expected.
pageReport.Document.Printer.PrinterSettings.DefaultPageSettings.HardMarginXCould you please confirm whether this aligns with our understanding?
Best regards,
Travis -
anand.sinha
Posted 5 June 2026, 4:08 am EST
Hi Travis,
ActiveReports does not define the ‘Printer.PrinterSettings.DefaultPageSettings’ values. Rather, these settings are exposed by the printer drivers of the selected printer and are only fetched by ActiveReports for printing.
So the actual value depends on the installed printer and its drivers rather than ActiveReports itself. This indicates that there might be a printer change or driver update which may have changed these values.
Regards,
Anand -
travis.beltrametti
Posted 5 June 2026, 8:23 am EST
Hi Anand,
I do not agree with the explanation that this behaviour depends on the printer.
The issue can be reproduced simply by printing the same report on AR17 and then on AR20 without making any changes to the report. The result is different: on AR20, the report is cut off on the left side.
This indicates that the behaviour is related to the application version rather than to the printer itself. From our perspective, this is a regression and should therefore be considered a bug.
Replacing or adjusting all customer-specific reports whenever a version update is installed is not a feasible solution. Existing reports that worked correctly in previous versions should continue to work after an upgrade without requiring modifications.
Could you please investigate what changed between AR17 and AR20 that could cause this behaviour and provide a fix?
Thank you.
-
anand.sinha
Posted 8 June 2026, 1:50 am EST - Updated 8 June 2026, 2:01 am EST
Hi Travis,
Apologies for the inconvenience. We tried to replicate the issue on our end by comparing the HardMargin values in ActiveReports v17 and v20, but they appear the same for the same printer (see attached screenshot).
We have attached our projects for reference. Could you please try running the projects on your end to see whether the values still appear different for the same ‘Printer.PrinterName’?If the issue persists in your project for the same printer, could you please try sharing a minimal replicable sample of your project so we can share the same with our development team incase of a bug.
Thanks,
Anand -
travis.beltrametti
Posted 8 June 2026, 2:17 am EST
Hi Anand,
Just a small clarification: we’re not concerned that the HardMargin values themselves have changed — in fact, we don’t really care about the actual values.
The issue is that with exactly the same report, after updating AR, the report is now cut off on the left side. It appears to us (although this may just be a coincidence) that increasing the left margin by the printer’s hard margin makes the output look almost identical to what we had in AR17.The original issue with the print quality has been resolved, which is great. However, our expectation is that upgrading AR should not require any report changes for existing reports.
The HardMargin information was only meant as a friendly hint for the development team in case it helps identify a possible bug. We’re not certain ourselves if this is the issue, but we would be very happy if you could fix it, as we cannot change every report after updating AR17->AR20
Thanks for looking into this.
Best regards,
Travis -
anand.sinha
Posted 8 June 2026, 11:49 am EST
Hi Travis,
Apologies for the inconvenience. We understand the issue you are facing. However, we won’t be able to comment on the exact source of the issue unless we are able to replicate the issue ourselves.
Therefore, when you indicated that you observe a change in the HardMarginX value, we tried to test whether the same is replicable to us as well.However, we have escalated this issue to our development team (Internal Tracking ID: AR-37572) as well to see if they are able to provide any insights into why this issue could happen.
We’ll let you know of any updates regarding the same.Thanks for your patience.
Regards,
Anand -
anand.sinha
Posted 9 June 2026, 5:16 am EST
Hi Travis,
The development team had some follow-up questions. Could you please tell us more about:
- What exact printing do you use? Is it some print logic you have handled through code, or are you using the built-in print button of the WinForms viewer/JSViewer?
- Could you test if the issue is reproducible with a virtual printer like ‘Microsoft Print to PDF’?
- Could you test what the behaviour is like when the report is exported to PDF instead of directly printing it?
Further, the developers have mentioned that a similar issue was seen with the initial release of ActiveReports v20.0.0. Could you please try upgrading to the latest release of ActiveReports 20 from here and see if the issue persists?
If the issue persists, then they have mentioned that they have implemented Direct2D printing from ActiveReports 20 onwards, so you may try changing it back to GDI in the ‘ActiveReports.config’ by changing the ‘PrintingSystem’ property. The config is located in the ‘Program Files (x86)/MESCIUS’ folder.Thanks,
Anand
