Does anyone know of any PDF Rendering Changes in 10.2.300.
Example:
MICR RDL Untouched, Unchanged - Prints misaligned in 10.2.300
Prints Spot on in 10.1
Almost as if in 10.2.300 when you select Output PDF and you Print to a Printer it doubles margins. If I change the Margins on RDL to 0,0,0,0 it no-longer whacks out of alignment but then I just have to adjust all the positions.
Almost as if the 10.2.300 PDF Rednering Engine sets it to “Scale to Fit” while 10.1 sets it “Scale to 100%”.
Nothing has changed hardware wise, server wise. I can still go back to 10.1 and Print, no problem. Something must have changed how the Client or Agent Requests the Rendering from SSRS.
Sure, but I still want to know what changed in Epicor without me touching a single setting in the world, nothing changed absolutely nothing but 10.2.300.13…
On the same server, the same printer I can go back to 10.1.500.46 and no problem.
@Mark_Wonsil@Rich@josecgomez I am not even just talking about MICR - lets put MICR aside, lets print a basic SSRS Packing Slip to a normal Paper Printer.
10.1.500 vs 10.2.300
Little hard to notice on the picture, much more visual in person… But 10.1.500 has a smaller margin and the font is larger overall by .2pt – the 10.2.300 version has a larger margin and is “Scaled to Fit” causing other issues, but here is the exact same RDL.
Yes, all reports have this differente between 10.1 v 10.2. There is no difference between RDLs when compared via WinMerge
Quote, ARForm, Out of the Box SSRS, Custom SSRS… I also have 3 other servers, same issue. So I think it is a Epicor Architecture Change, but id like to know how it works or if we can disable it.
If you are printing ARForm or any other form, who really cares it scales or shrinks or adjusts. But when you are printing content on Pre-Printed Forms then its important to not have a mind of its own.
EMF is great, but if you are using various fonts, each computer who prints it needs all the fonts. When dealing with 1000 PCs and people being hired and fired and laid off on a daily basis managing another layer is just more complexity.
However, you have no control of the Rendering micro-options, unless you Print Preview and then send from Adobe or FoxIt to the Printer.
Right now my assumption is, that Epicor sends an additional flag to SSRS in 10.2.300 to indicate “Render as OUTPUT Format with … Scale/Page-Sizing: Fit or whatever” I figured I ask first if anyone heard anything before I trace and debug.
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%”
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
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.
without me touching a single setting in the world, nothing changed absolutely nothing but 10.2.300.13…
I run them side by side.