Are you testing this from the Server client or the same workstation client (but different versions)? My point is to isolate the source of the root cause. If PDF reader/rendering what version and default options enabled.
I’ve tested this on 6 computers, 2 different servers, 2 different Corporations, atleast 4 printers – same exhibiting the problem. As far as I am concerned it isnt an isolated change. It may literally be a code change in the Task Agent how it queues Reports to SSRS… I’ll start comparing my SSRS Databases see if it adds additional parameters in the XMLs it sends to the ReportServer. I also have 10.1.500.46 and 10.2.300.13 so I can print both at the same time, to the same printer, with the same Style etc…
I am not calling this a bug, its a change, probably for the greater good - it would just help to understand the logic. 
and maybe some docs on it. Because now when you have margins in SSRS dont expect it to come out the way you think. If you say margin 0.25 – it will be 0.35 or 0.45. (If your print preview, you might not notice it because Adobe does whatever Adobe does) but if you Print direct to a Client Printer, you might notice it.
The only way I got the behavior to work like in 10.1 was to set the margins to 0, 0, 0, 0.
Not to throw more variables into the equation (actually trying to eliminate some) … Does this only effect “built-in” reports? Or does it show on BAQ Reports too?
Make an RDL that has no fields, just an 8" square rectangle. Set that RDL as a style for AR Form and print it out. Repeat on the other server/environment.
Then preview that report on each server/environment. From the PDF preview, print each one twice. Once with “Fit to page”, and again with “100%”
Be curious to see what that does.
Did you compare the printer device driver setup. I would compare Apples to Applies. If previously printing to a network printer then the setups on both servers should be compared. Likewise with local printing.
Everything is the same. I even have Epicor 10.1 and 10.2 on 1 Server, 1 Network and I can access the same Printer from the same PC – total apple to apple 
I run them side by side.
@ckrusen Ill test it on a smaller BAQRpt the one I tested it on was affected as well.
Here is where I see Epicor Customers being affected by this:
- Relying on Margins in RDL to come out as expected (on pre-printed forms)
- SSRS Labels (when doing labels in SSRS you tend to use a smaller margin) or cycle count tags
- You have Reports where you aligned the Address to fit a special envelope window – might be shifted now.
if 0 margin is no longer possible and 0 = 0.25 or 0.15 device dependent then that ruins things. or any margin receives additional margins – Ill have to check all my 0 margin RDLs to see if it truly honors the 0 margin stilll. If I set the RDL to 0 margin I Expect the text or box to be at the upmost corner if the Printer allows it.
What hit me was my previous post:
The only way I got the behavior to work like in 10.1 was to set the margins to 0, 0, 0, 0.
Well if 0 = 0.25 then what happens to the Reports whereI actually use Margin 0 in 10.1 lol SSRS doesnt allow a negative margin – time to do some more damage control and validation
I wonder if @JeffLeBert has more insights =)
2 Likes
Is the “image” in the PDF that is generated actually different? Or just how that PDF is printed when sent directly to a printer?
If you use the “email” destination for printing a report, is the attached PDF identical? Or does the space between the edge of the page and the page’s content vary?
Epicor does use PDFPrintingNet Library and They do have scaling capabilities. 10.1.500 vs 10.2.300 has a significant difference.
PdfPrint has 3 different scaling options in printing:
1. Actual Size - it leaves page as it is. If content of the page is larger than printer printable area, than part of the content will be truncated.
2. Fit to margin - if content of the page is bigger or smaller than the printable area, content will be re-sized so it fits printer printable area.
3. Shrink to margins - if content of the page is larger than printable area, content will be downsized. If it isn't bigger than printable area, content size will stay the same.
Different printers has different printable area.
Now I just have to Reflect on the Code that uses it and see where Epicor is setting the new flag or perhaps PDFPrintingNet Library given that we are now on the latest version which is 20mb in size compared to 7mb perhaps by default now sets a scale and you must explicitly change it.
1 Like
Epicor 10.1.500.46 = PDFPrintingNet 2.0
TBD
Epicor 10.2.300.13 = PDFPrintingNet 4.7.3
If set, it will scale the page according to the chosen scale type. If not set, it will use the Shrink scaling type
2 Likes
Let me try to sum this all up. Some of this is from memory so don’t throw anything if I make a mistake.
First, let’s talk about how PDFs are used in printing. E10 asks SSRS to render a PDF. That is 100% handled by SSRS. That seems to have stayed very stable across the versions of SSRS. Somewhere above in the thread it was asked to email the report so you could get the actual PDF. You could also save from System Monitor even after it is printed. These, as far as I know, would stay identical across the different versions of SQL Server and not be affected by the version of E10.
The next part is where all the trouble comes in. As @hkeric.wci just stole my thunder, we use PdfPrintingNet.dll from https://www.pdfprinting.net/. Here’s the versions I checked:
2.0.0.0 = 10.1.500 and before
3.0.6.3 = 10.1.600 - 10.2.200
4.7.3.0 = 10.2.300 - future!
In the version switch from 2.0.0.0 to 3.0.6.3, they changed how they were scaling by default. We did our best to get it to match what the previous version did. I didn’t directly deal with this issue, and don’t clearly remember all the conversations. It was decided that we would keep the newer version for a number of bugs it fixed.
As I mentioned, I didn’t directly deal with customers to solve the scaling issues. Most reports don’t matter since the difference is small. Preprinted forms are where the problem is. If anything moves or changes size, it won’t match the preprinted form. I think the solution was to modify the SSRS RDL so that it fits with the new scaling.
I think the size difference (7mb to 28mb) comes from them adding a PDF viewer. I wish that would have been in a separate DLL since we don’t use that functionality at all.
EMF vs PDF was brought up because E10 “owns” the previewing and printing parts. This is analogous to PdfPrintingNet.dll and whatever PDF viewer you use. The scaling, etc. should be the same for EMF through the different versions of E10. I haven’t heard any issues with it, but then the default is PDF so I don’t know how much it is being used.
I think that may cover most of the points in the thread. Let me know if I missed something and I might be able to fill in more information.
9 Likes
Awesome! I thought I was going insane. Yes we have adjusted our RDLs and Margins, still having some issues with Pre-Printed forms despite going to margin 0 because you can’t go negative in SSRS… But workable.
Do you have plans to set the Scaling in 10.2.500 back to NoScale, in other words, should we be keeping a backup of the “before tweak rdls” ? Or do you plan to continue leaving it as-is.
I agree EMF Works Great, only minor issue is fonts need to reside on client MICR, Barcodes, etc… to PDF Works great and like you said only when you start to go to the Printer it does something weird.
3 Likes
We want to make the scaling as correct as possible out of the box. If we change it again, it will mess everybody up. When PdfPrintingNet makes a change, we have to try to pick the best settings to match how it worked before. I don’t think we are bumping the PdfPrintingNet version, so 10.2.500 should be identical to 10.2.300 and 400.
2 Likes
Far enough! Thank you very much for chiming in. That helps definitely everyone as a heads-up. Like you said who cares if ARForm or PickList is scaled by 0.1% you can barely notice it. I just have to test some of the more special Reports like Cycle Count Tags, MICR of course, few custom BAQ Reports like Vehicle Titles, SSRS Labels etc…
@Bart_Elia give this man a raise!
4 Likes
@ckrusen @asmar @ERPSysAdmin check out Jeffs answer, if you are still on 10.1.400 or 10.1.500 and you plan to upgrade, make sure to Regression test your “Special Reports” by Printing them to a Printer such as MICR etc… #PhysicalPrinting
Also thank you to both of you as well, for attempts and thoughts
5 Likes
Thanks Jeff!
4 Likes
Yes, thank you @hkeric.wci for posting this topic, doing all of that investigation, asking the questions, and getting an answer! And thank you @JeffLeBert for providing that answer!
1 Like
I see that @JeffLeBert answered this one, but I am curious about the margins in the Printer settings:
1 Like
I don’t think the margins are used by PDF reports. The margins you would care about are the ones in the SSRS RDL.
4 Likes
Thank you.
@JeffLeBert May 1000 elephants fertilize your pumpkin patch with their droppings, that was the info we needed and we were able to resolve all our issues. 
2 Likes
Thanks, I think.
2 Likes