Solved: "Can Grow" Fields cutting Text on right Margin if ...

Dear Community,

i found out, that in our Report's (about 500) "Can Grow" Fields cut the Text on the right margin.

It seems the Word Wrap dosn't work....After all, i tried to reproduce it. First i can't.

But then I found out, that you must set have in Page Setup "No Printer (optimize for screen display)" to get the same issue.

We have Crystal 2008 with all SP's and using VS2010 SP2 to view our Reports. The most Fields are comming from Database.

here some picture:

[http://knw-610.com/tmps/CutText.JPG]

Hope you can help me.

Best regards

Steven

Edited by: vissers on Dec 21, 2011 10:13 AM

SAP Managed Tags:
SAP Crystal Reports, version for Visual Studio

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (1)

I set NO PRINTER alread.....because that i will get the error....

If i set to my current printer, then the error is fixed,

BUT I want to set NO PRINTER...

So what I can do?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Sorry - i do not understand your shorthand

- Ludek

I set the NO Printer option because, i got errors from some customers, that the page is to large for the paper, they use all different printers...

So i read somewhere that is it better to set the NO PRINTER option.

But if I use this option I have the problem with the margin on "Can Grow" Fields....

I think the original error; "the page is to large for the paper", is possible to get even when using MS Word. As a matter of fact, I got that same error opening a word doc somebody emailed me via hotmail.

How you'd resolve that I have no idea.

The cutting off of word on the right side of the page of a report when using "No Printer" option may be a bug on our part. I can duplicate it using CRVS2010 SP2. I'll try it using original CRVS2010 also, then report it to QA for a fix. If they accept it as a bug, we'd be looking at SP3 at the earliest (mid 2012).

- Ludek

That sounds good,

Would be nice if keep us up to date.

Thank you in advance

Best Regards

Steven

Hello Steven

The Technical Escalation is #5000395295. I do not have the facility to follow these threads in detail. Thus it will be best if you check back once SP 3 has released (we will blog this, tweet and other so you will know).

- Ludek

ADAPT01606290

ETA; SP3 for Crystal Reports for Visual Studio 2010 (Mid 2012?)

- Ludek

Hi Steven,

Update on the Adapt. R&D has replicated the issue and determined it's a problem in Micorsofts GDI+ dll, nothing we can do to fix it.

"The caused is a product limitation – Winform Viewer uses GDI+ to render report, it is unable to be render the report as the same as the CR Designer which uses the GDI to format and render the report."

Please escalate to Microsoft.

This reminds me of another issue we had with GDIPlus also and some user found a copy of it that did work. Search here, you may be able to find that reference.

Thank you

Don

Hi Don,

we ran across the same problem. Our old print-interface used RDC and worked like a charm. The new one is using RAS with CR for VS SP9 and get sometimes the same problem as described above.

Still 2 years later, it seems that Microsoft didn't changed anything in GDI. I tried it on Windows 7 and Window 8.1 without success: the text is incorrectly wrapped, some characters on the right side of the field are cut across.

Do you have some news? Did your dev-department contacted Microsoft?

Patrick

There are some fixes for character spacing when zooming in SP 10. Other than that it does take a long time to get MS to do anything.

I can ping DEV to see if they push any bugs to MS but usually we simply code around the bug. It's easier to do that way...

Try adjusting the field width, or a different font etc. If you want to attach your report with data I can give it a test and see what happens on my PC? Rename the report file to *.txt and then attach using the Advanced Editor.

Don

Thanks

I attached two files: one report and a screenshot.

As described above, the behavior only occurs in the CRVS-Viewer, not in the CR 2011 Designer. Changing the field width is not an option, because it depends also of the content of the field, if I enlarge the field or change the font, another string-content could produce the behavior again.

It would be great if your Dev-department could implement a workaround for SP10.

Patrick

Hi Patrick,

Thanks for the report. I don't see the same thing with this report so need more details about your environment:

This is using your report with No Printer checked on and IE 9 on Windows 7 64 bit.

Are you loading everything in the Page_Init?

Don

I don't have a WebApp for this case, so no Page_Init.

We use a VB6-App with a COM-Wrapper to use the your CrystalDecisions.Windows.Forms.CrystalReportViewer; same behavior without the COM-wrapper in a normal WinForm-app (VS 2012).

Patrick

Patrick, Absolutely Not supported, others have tried to make this work, sometimes does but most often it does not. COM interop is one of the problems, problem with passing info from object to object back and forth between those layers.... We have never supported it and never will. Convert to full .NET.

Framework printing is different than CR Designer/RDC Native WIN32 and DEVMODE. .NET uses the System.Printer collection. Lots of info convertion and works differently.

Ryan, No Printer is for WEB app's, Uncheck that option and check on Dissociate, if it is not already. This way it uses the standard paper sizes but is not dependent on that specific printer. As long as you don't use Custom Papers Sizes this will work. If you sue Custom or User Defined then it's going to a problem and too long to explain here unless you are using them.

If using Standard paper sizes simply use No Printer unchecked and Dissocaite Checked on.

Thanks

Don

Thanks Don.

We not only have this problem with the COM-wrapper but also with full .Net.

Did you get some news from your DEV-department concerning Microsofts GDI+? Workaround?

Patrick

Hi Patrick,

Problem is I dont' have the same as you, looks fine for me so it must be environment related.

Need more details on your test system, can you log a new post and refer to this one?

Even better log a case in SMP and we can get more details and work directly on this.

Also, SP 10 is due out very soon so possibly that may have fixed it.

Did you uncheck No Printer and resice the field object slightly to see if that works?

I talked to the previous SDK PM ( local ) and he did say we do log issues with Microsoft, not sure if the current SDK owner did or not though, I haven't heard back from him but it is close to patch release cycle so he's likely too busy to respond right now.

The problem is the same, if the fix introduces potential regression problems MS won't change GDI+. So nothing more we can do about it.

But I will followup with Donald once the rush is over...

Thanks again

Don

I just tried the new SP10 - same behavior.

If the "no Printer"-flag is not set, the text is correctly wrapped.

If we uncheck the flag, resize slightly the object, check the flag again, the text remains incorrectly wrapped, but now some pixels to the left or right.

What I don't understand is when the DEV-department had a contact to MS, they had reproduced the behavior two years ago?

If the "No Printer"-flag is checked, the report should be printer independent? So the environment should not play a role. Did you use a WinForm-App with your viewer to test the case?

Patrick

Hi Patrick,

How much did you resize the object?

I don't think this one is the same issue as GDIPlus issue. This is core to crpe32.dll and a zooming recalculation. But related to No Printer.

Try a new Report and set your default printer to a standard Printer, don't sue the MS XPS printer, it has bugs in it.

Set the No Printer checked on and then test again.

Yes I tested in both a WinForm App and also a WEBForm app.

Don

Hi Don,

We draw a new report from scratch with CR 2011 without a datasource; we only put a text object with our specific text sample on it.

I also added a little .Net TestApp to reproduce it (the attachments should be renamed in Zip-Files).

We also testet your suggestion with the standard printer without success (HP LJ P2015).

Patrick

Hi Patrick,

Ludek and I are putting together a Doc on what happens when various options are checked on and/or off and even OK buttons affect the output.

I see the same issue but here's why. When you design a report it uses your DEFAULT printer properties to layout the page. If you Don't click on Page || Setup then the page is optimized for the screen.

Because you click the No Printer option this now removed the dependency on your default printer but because Dissociate is on it has a dependency on your default printer properties. And because you selected No Printer I can't tell, through the SDK what that printer was. So now when previewed it uses the Users PC's Default Printer properties.

That's the issue and why you don't want to use No Printer. In CR 2008 and above there is a 4th state, Dissociate, that uses the basic Printer setting when designing the report but does not have a specific dependency on that printer.

So what you need to do is set your default printer to a standard printer, something like an HP printer, although we do have issues with their drivers also because sometimes they release drivers with bug in it. The Windows XPS driver is buggy also so you'll have to try different ones and use one that works. Just install the printer driver, set the port to LPT1 and pause it. I have a bunch of printers installed and I don't have the printers.

Now you need to adjust the field size and Font so it fits and then test in the viewer to confirm the font does fit. Use Courier, it is a fixed font, every character takes up the exact same amount of space..

To show my default printer is HP Laser 8000, when I open the report in CRD it looks fine with the no printer option checked on:

If I uncheck that option you'll see it uses my default paper size and reformats the page:

Now I see it's changed:

You need to be aware of how these reports are created, Defualt printer being used and Fonts as well. Then leave enough space in the objects to handle the fine details of Font and Printer driver spacing.

Try various settings and you'll see how it's affected...

Hope that's clear

Don

Thanks Don for these long explanations (for me and Ryan).

I made some further tests....

We have a few ERP-Apps and these apps have hundreds of generic reports (like Ryan). During the last years we found out that checking the "No Printer"-Flag on helped us to correct some worse conditions (black/white vs. color printing, A4 against A5 printing...) - so all our reports have now "No Printer" checked on (reports designed with CR XI R2).

Now when migrating these reports to CR 2011 (CRVS2010) we don't want to check each report to adjust the object sizes here and there (...terrible costs). Also setting the fonts to Courrier would not be an option, there would be an insurgence from the customers...

So when I take the text from my previous samples "TÜRDRÜCKER EDELSTAHL ROSETTEN GARNITUR METRO PZ 8MM - ART.50.03.0430", the correct behavior should be, that the word "METRO" would be wrapped to the second line.

This is the case :

in the old RDC-Viewer (CR XI R2) with "No Printer" checked on.
in the CRVS2010-Viewer with "No Printer" checked off (cf. my test-program).
in the CR 2011 designer with "No Printer" checked off.

It would be acceptable, if the word "METRO" remains correctly written at the end of the first line. This is the case :

in the CR 2011 designer with "No Printer" checked on.

The incorrect case is when the word "METRO" is incompletely written at the end of the first line (letter "R" only half drawn) :

in the CRVS2010-Viewer with "No Printer" checked on (cf. my test-program).

The Dissociate-flag does not change this behavior!

I also tried it with different printers (f.ex. your HP LJ 8000), no difference - same behavior.

So there should be nevertheless something buggy over there...

When do you expect to have finished the doc with Ludek?

Thanks again,

Patrick

Hi Patrick,

In all of your test cases you are using the GDI video driver. CR Designers using it as well as the ActiveX viewer in Visual Studio, Previewing the report in the IDE itself. It's the old embeddable Designer and ActiveX viewer.

Also note that the embedded Designer in VS IDE is only to be used as a general layout test in Preview mode, it does not produce the same results as the WEB or Windows viewers do.

When previewing with the CR.Windows.Form viewer it is using GDIPlus.dll. There are known issue with that driver for .NET applications and we can't fix them. It's a MS issue and they are very hesitant at changing it's behaviour because of backward compatibilities.

So you are comparing Apples to Oranges, the ActiveX components in the RDC and VS IDE Embedded Report Designer use the old legacy viewers as well as CR Designer which uses GDI.dll and Native Win32 API's in C++.

When using the CR .NET runtime you are now using the Framework and GDI+ to render the reports and we can't "fix" the formatting issue in GDIPlus.dll

CR is hardware and software reliant so it could be an upgrade to your Video card driver may "fix" the layout or possibly changing the DPI settings can help also. They all affect how the report viewer will render the page, this includes the printer Driver and Dissociate option.

Best option is to adjust the field width and fonts, maybe the size will make the report look better also.

I'll remind R&D about the known issues they have close Adapts for due to limitations within GDIPlus and see if they can open a ticket with Microsoft to get them resolved. But I don't see it happening quickly.

There have also been a few cases logged and Escalated for these exact issues, text being chopped off or spacing no consistent, and they have all been rejected as either "Not our Issue" or work arounds by simply adjusting the text object size slightly can "resolve" the spacing and truncation and word wrap performance.

Bottom line is nothing we can do to fix the issue at this time, Try SP 10, it may help, they are "tweaking" the code to adjust things so it may help.

Don

Hi Don,

PS. I'm already using the viewer from CRVS2010 SP10.

@Ludek: BTW: what about the wiki of the fixed issues in SP10?

So my problem is finally caused by a MS bug in GDI+, thanks for your in-depth explanation.

Some thoughts:

if your .Net-Viewer uses GDI+, why is wrapping different when "No Printer" is not checked?
do you have another new .Net-Viewer which uses the "old" GDI?
it would be great that your R&D could provide a workaround. Our customers won't understand if we state "This is a problem of SAP and they say it's a problem of Microsoft", they need a solution.
playing with the object size is not an option. If we change it 1 mm to the left, perhaps then is another string-compilation that produce a wrong wrapping again...

Thanks,

Patrick

Hi Patrick,

No Printer sets the Page to "Display" mode but it still needs simulated printer properties to format the layout, Height, Wide and Left, Right, Top, Bottom margins. It uses some internal predefined paper sizes according to the Standard ENUM's for them. You can see this if you select No Printer, there are about 13 predefined paper sizes the engine uses to format the page. So when using No Printer the page size still interacts with Fonts, GDI+ and the Framework to layout the page.

No, Microsoft has a dependency on GDI+ in a .NET application.

Workaround is to try adjusting the object slightly...

Even if it causes an issue in another object then adjust that object.

Try adjusting the object to see if this works, its a combination of the print driver, Font and object size and location. If it does fix the issue them we know for sure the cause, if it doesn't then we can possibly have another look at the issue.

Don

As you can see, adjusting is not a workaround, it's like playing in Las Vegas - no chance:

One field width works for one string, but not for another string !!! Please show this screenshot to R&D.

If Microsoft won't correct the bug in GDI+, it's up to CR to write their own rendering...

Thanks again,

Patrick

Good analogy...

Can you attach that report?

So if you uncheck ( off ) the No Printer what does it do?

I can send it to R&D and see if there is anything we can do.

Writing our own GDI+ driver is not practical since it's MS's GDI+ that in the end is still going to have to render the page in a .NET Windows Form.

I did some more testing in SP 11 and I see it's still the same, possibly even worse now but it is consistent.

I found the original ADAPT01606291 where I tracked this issue and why R&D rejected it as not being a CR issue.

I'm going to re-open it and ask DEV to contact Microsoft to see if we can work together to resolve this issue.

No idea if or when any kind of fix will come out of this request. MS is slow when changing things if they agree to. For Regression issues they don't like to change behaviour even if it's bad...

For now your only option is to NOT use No Printer.

Thanks again

Don

Hi Patrick,

Good news, maybe, R&D has agreed to submit this issue to Microsoft and see if we can find some solution when using No Printer. No idea if or when a fix and if or when one will or will not be provided.

In the mean time the only way to make the result relatively consistent is to not use No Printer option.

Thanks again

Don

Hereby the test-report.

So we hope that MS will change something...

Thanks for your efforts,

Patrick

Hi Don,

do you have some news from R&D or from Microsoft?

Patrick

Hi Patrick,

There was no need to purchase a single case - Incident 940105 / 2014 / Fields cutting Text with No Printer

Please contact CIC and get a refund, no charge for logging bugs.

This issue was reported by a large OEM partner of ours so I added it to the original Adapt I had reopened so now it has a higher priority and should be resolved by SP 12, if we can....

So R&D will not be contacting you directly and they will update this forum post if they have new info.

We do not provide Fix Packs for this product, SP 11 was just released and the next one should be out in December/January time frame...

Thanks again

Don

I purchased this case because I got no answer on my last question.

It's good to hear that priority raised.

Do you have the Adapt-number yet?

BTW. on your page the SP 10 fixed issues link does not work. And do you have somewhere the fixed issues list for SP 11?

Thanks,

Patrick

Hi Patrick,

Like I said, Forums is bottom of the list of things to do... With SP 11 just out lots of things to do...

We are moving away from Adapt to Work Bench and those numbers are not available to us.

So it's still off the original Adapt but it will be ported into WB by DEV.

For CR for VS we are maintaining an internal WIKI with all of the fixed issues which Ludek or I will have to manually copy the info over into a wiki with KBA links.

Don

Hi Patrick,

R&D had another look at this cutting off of characters and the problem lies not specifically in GDI+ but in USP10.dll. We use the older version 1.4 and we cannot upgrade this version.

The impact on all of our products is huge and would be the same as a complete rewrite, we would need to adjust all of the object orientation to be WYSIWYG and that would be a huge code change.

Printing/exporting shows exactly the same results when using No Printer option.

So here is why as described in this Blog from MS on the whole DPI setting and adjusting ( which is what usp10 is for ) CR uses the "Display Driver" to generate the output which is all based on the DPI settings.

Where does 96 DPI come from in Windows? - fontblog - Site Home - MSDN Blogs

So bottom line is we cannot "fix" this issue when No Printer is used. The simplest way to resolve the problem is to simply use any printer driver, you don't need the printer, just need to have the printer driver installed. So for consistency everyone needs the printer driver installed and set the reports to use that printer and adjust the report accordingly.

One other work around is to adjust the right margin of the text object and add a .1 inch offset. This allows the formatting to limit the edge and auto-wrap the test to the next line.

No other option now other than don't use No Printer. Adapt has been rejected once again as By Design with the work around of using a Printer Driver.

Understand there are 2 factors when designing reports, Display Based or Printer Based. No Printer is Display based.

For more details see these new Printer Doc's Ludek and I put together:

Thank you once again

Don

So these are bad news.

I've read Ludek's wikis. The problem is that we have generic reports, over 1000 customers with each let's say 10 PC's. So R&D want us to instal 10,000 times the same printer driver? This is - sorry, pitiful.

What did your large OEM-partner reply?

So what are the recommendations for designing and deploying generic reports (we have WinForms- not WebForms-applications)? To use "No Printer" checked on to be printer independent? 99% of our reports work on A4 paper.

Thanks,

Patrick

Hi Patrick,

I agree with you completely.... When I heard other Rep's recommending and sometimes it was the only way to make them work, to check on No Printer I cringed....

Unfortunately there is no way around this issue other than using a printer. Once you set No Printer in the report when exporting or using SaveAs() it does not update the printer info.

I tried a few different ways:

rptClientDoc.PrintOutputController.ModifyPrintOptions(newOpts);

This has always bugged me and I've needed a business case to ask R&D if we could update the printer info using the SDK for this very reason so I'll discuss with the SDK PM and see if he can add this ER.

There is this article on how to set a report to No Printer:

http://scn.sap.com/community/crystal-reports-for-visual-studio/blog/2010/09/15/how-to-check-no-print...

But it doesn't seem to work in the opposite way...

I'll keep testing to see if I can find a way programmatically to update the printer info and ask R&D if we can through an ER if there is no other way to do this.

At least then you can update the reports to a specific printer and enable Dissociate.

I'll update you when I hear back from them

Don

A colleague found another workaround: setting the right indentation of the field f.ex. to 0.5 cm, forces the content to be wrapped earlier.

The result (you can compare it with the screenshot above):

So I think the right indentation give a tolerance zone to the wrong calculation in USP10, as you can see in the 3rd row, where "ER" is in the indentation zone.

What do you think?

Patrick

Hi Patrick,

Yes, adding .7 to the right indentation is one work around R&D came up with.

It does move the test around but no clipping then.

Don

Answers (3)

I am experiencing a similar issue with text being cut off in the right margin on a field that has "Can Grow" set to true when "No Printer (optimize for screen display)" is set to on.

The issue is resolved if I turn "No Printer (optimize for screen display)" off. However since we are deploying these reports to systems where we do not know which printers will be available, this cannot be set to on.

Is there anything that can be done to fix this or work around it?

Ryan

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Ryan

CR has a big dependency on printer drivers. There is an article that explains this in boring detail here:

Crystal Reports: Printer Driver Dependency | SCN

I am working on getting the doc updated and organized into smaller chunks, but for the most part, the info contained there is quite applicable.

- Ludek

Senior Support Engineer AGS Product Support, Global Support Center Canada

Hi Ludek,

Thank you for replying to my message so quickly.

I skimmed through the referenced Crystal Reports: Printer Driver Dependency document looking for content applicable to the issue that I am experiencing.

I understand that different printers will output the report differently because of printer drivers.

How does the CrystalReportViewer control in Visual Studio layout the content when 'No Printer (Optimize for screen)' is selected? And how come it can't layout the text correctly? If I de-select 'No Printer (Optimize for screen)' and select 'Microsoft XPS Printer' as the printer, the CrystalReportViewer control is able to layout the report content correctly. (as demonstrated in my screenshot) The Crystal Reports: Printer Driver Dependency document makes no reference to the 'No Printer (Optimize for screen)' setting so I have no reference as to why it is experiencing an issue.

Regarding the report creating checklist for distributed reports:

- This field has multi-line line content so I cannot simply extend the width to account for the 5% of likely growth.

- This multi-line field is already at the bottom of it's section

- The report already uses a TrueType font (Arial)

- The field in question is not a video

- Setting the report margins to 0.25 (and turning off Adjust Automatically) did not change the symptoms. If I apply a .49 inch right indentation to the field, it will layout the text correctly. However, chopping off 0.5 of an inch off of every field on all of our reports that has multi-line content is not an ideal solution.

- The point to 'Do not choose a specific printer' is already being followed by selecting 'No Printer (Optimize for screen)'

- I cannot find any controls that reference 'Free Form Placement'. Is this legacy from Crystal Reports 8? I am not sure how to 'format every section to have Free Form Placement selected'

- I did not use any guidelines for this report. I just added the text field and manually added the content that gets cut-off when viewed in the CrystalReportViewer control

Is it possible to control through code which driver the CrystalReportViewer control uses to preview the report at runtime?

Thanks,

Ryan

Hello,

Don, thanks for your above comment; I admit that I was not aware that 'No Printer' was intended for use by WEB apps only:

"Ryan, No Printer is for WEB app's, Uncheck that option and check on Dissociate, if it is not already. This way it uses the standard paper sizes but is not dependent on that specific printer. As long as you don't use Custom Papers Sizes this will work. If you sue Custom or User Defined then it's going to a problem and too long to explain here unless you are using them."

We experienced printer layout issues back in 2011 while using Crystal Reports for VS 2005 (10.2.3600.0) where the solution was to check on 'No Printer'. Also, the following MSDN link recommends checking on 'No Printer' to increase scalability:

http://msdn.microsoft.com/en-us/library/ms225523(VS.80).aspx

We are now using Crystal Reports for VS 2008 (13.0.2000.0) and I am assuming that there have been changes to the Crystal Libraries since then that may affect this issue; it sounds like the 'Dissociate Formatting Page Size and Printer Paper Size' option was not available in the 10.2.3600 libraries.

I am wondering if that mentioned document is available or will be available soon:

"Ludek and I are putting together a Doc on what happens when various options are checked on and/or off and even OK buttons affect the output."

I am interested in reading it and learning what the best practices are for designing reports where the actual printer that will be used to print the report is unknown at design time. From this thread it sounds like the best practice for this scenario is to:

1) Check Off 'No Printer'

2) Select any standard printer (do not use Microsoft XPS Writer)

3) Check On 'Dissociate Formatting page Size and Printer Pager Size'

4) Manually set the Page format to one of the standard Page Sizes (i.e. Letter which defaults the page sizes to 11.001 x 8.501); do not select User Defined

We have a few hundred .rpt files that would need to have the above best practice applied, so before I go back to our team with a recommendation I would like to read that document and use it as a reference.

Thanks,

Ryan Cassell

Hi Ryan,

Depending on the version of CR depended on if using No Printer was recommended or not. Supported tends to recommend what ever works at the time... So many versions of CR Designer now sometimes what used to work may not now...

We are still working on it and we've asked R&D for a few enhancements as well as a few logic explanations. Requires updating the reports using 2013 SP 11. Not sure what patch it will be in for CR 2011.

So to clarify, setting No Printer is not just for WEB setups, if your reports are generic paper sizes then it should work for you also. And FYI, when no Printer is selected CR uses one of 13 predefined paper sizes, you can see them by checking on NO Printer with dissociate check on. The papers size will be one of the generic sizes.

And yes, Dissociate is new feature added to CR 2008 and above. The Enhancement is CR will now save the User Defined Paper Size to the RPT file so at runtime you can get the name and the horizontal and vertical values and try to match the local PC's print drivers. But for standard paper sizes this is of no use.

So in your case if these reports are standard letter size then No Printer can be used but also make sure the Dissociate option is checked on. It's off in older reports but on for new reports so this is one thing you should change/update in your legacy reports.

What this will do is not have a dependency on your specific printer but it will require a default printer be installed on the users PC and it supports 8 1/2 by 11 paper size ( for example )

For your issue there are a few things that also control the spacing:

USP10.dll version 1.4 is what CR uses, In CR Designer clicking on Help, About... More Info button you may see 2 versions loaded, one from CR's folder and one from \windows\system32 folder. Runtime need the one from our folder so make sure it's being loaded.

The other issue is with GDI+, it's part of the rendering engine when previewing and printing reports. Some issue we can't fix but due to the nature of the font selected and the Printer being used and GDIPlus.dll it can affect character positioning.

So the next step. The print button in the CR Windows Form viewer using PrintToPrinter API and is about as basic as it gets. It's a left over from the CR Basic report Designer and there is no changes being added to this printer API. It use the system.Printer .NET Framework printer values.

For better control using the PrintOutputController to do the printing. You can replace our print button with your own and handle the printer and settings yourself.

All I can suggest is to try a few variations and find one that works best for your and your app and stick with it. Use the latest CR 2011/2013 and CR for VS SP 10 or above and the printing should be consistent.

And on that note try using Courier as the font, it's spacing is exact, every character uses the same amount of space so a lot easier to format the page.

finally, CR is hardware dependent, meaning we use the hardware drivers, Video and Printers, to format the pages, this way we are WYSIWYG so passing reports around to uncontrolled platforms can be hit and miss at rare times...

Try a few changes and settings and find ones that work for you and go with that... but see how it affects the out. Test on PC's that do not have the Design Printer installed and see what the options are, they should be true for all printer types. Except DotMatrix printers, those are mostly legacy drivers so they don't always work "nice" with .NET Framework.

Don

Hi Ludek,

you understood me wrong.

I am using CR for 2010 already, (SP2 already too)...

I just use CR2008 just for Report Design.

Even if I design the Report in VS2010 (with CR for VS2010) i will get this issue.

If you want I sent a example project. It's very simple to reproduce.

Thank you in advance

Steven

Edited by: vissers on Dec 22, 2011 12:15 AM

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

I suspect this may depend on printer driver and not easily reproducible from computer to computer. See if enabling the "No Printer" option and enabling the "Dissociate Formatting Page Size and Printer Paper Size" option will help.

- Ludek

Hello Steven

Unfortunately, CR 2008 is not supported in VS2010. Only [Crystal Reports for Visual Studio 2010|http://www.sdn.sap.com/irj/sdn/crystalreports-dotnet] (CRVS2010) is supported with VS2010. Please download CRVS2010, ensure you are referencing CR assemblies of version 13.x and try again.

Ludek

Got Enhancement ideas? Try the [SAP Idea Place|https://ideas.sap.com/community/products_and_solutions/crystalreports]

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Ask a Question

Top Q&A Solution Author

User

Count

"Can Grow" Fields cutting Text on right Margin if Page Setup has no Printer

Accepted Solutions (1)

Accepted Solutions (1)

Answers (3)

Answers (3)

Iterating through JSONModel with multiple nested a...

Re: Connecting SAP CAP with SAP Cloud ALM

How to use CopyProvider on Table created by TypeSc...

How to execute/fire onPost when user press enter o...

Re: Connecting SAP CAP with SAP Cloud ALM