RDLC Invoice Report : Cut Numbers

gtrgtr Member Posts: 131
edited 2015-05-21 in NAV Three Tier
Hello,

On Dynamics Nav 2013, I have created a new Sales Invoice Report (by using the 206 standard report as a model)

I have a problem with all decimal fields (I suppose because they are aligned on the right) :
The number the most at the right side is slightly cut
Have a look at the picture joined to this post as an example
I do not have any idea where it does come from - I tried to keep the same properties as in the standard report, but I changed the font.

I'm just beginning with RDLC - Can anybody bive me some hints ?
Thanks

Comments

  • postsauravpostsaurav Member Posts: 708
    Hi,

    check by putting say 10pt on Right padding for the field.

    Thanks & Regards,
    Saurav Dhyani

    Do you Know this About NAV?


    Connect - Twitter | Facebook | Google + | YouTube

    Follow - Blog | Facebook Page | Google + Page
  • gtrgtr Member Posts: 131
    Hello,

    The padding properties were 5pt;5pt;0pt;0pt

    So I changed for 10pt on the right (5pt;10pt;0pt;0pt)

    No change !
  • MarijnMarijn Member Posts: 69
    To me it looks like your control box is just a little bit too small for the chosen font, fontsize and padding. Try setting the padding to 0 or 2pt maximum, and decrease the font size or increase the (vertical?) size of the text box.
  • gtrgtr Member Posts: 131
    hello, Nice Try

    I modified padding to 0 and decreased font size to 5pt - and this worked, ... But ... :
    Since my last post I tried out some standard reports and the probleme happens on all of them - so this might come from the way I print ?
    Just now I'm in my dev environnement and all is local. I will try as soon as possible to print in another environnement.
  • MarijnMarijn Member Posts: 69
    It's hard to tell. But you might want to remember these rules of thumb while debugging: Padding is the space between the content of a cell and the outer borders of that cell. It is used to give characters some space to breath which usually is only needed when borders are visible. In general, a padding of 2pt should be all you need for important elements like captions. For simple unbordered tabular data, 0pt padding is usually perfectly fine. 5pt already is very large and if you need this then chances are you're masking some other problem. Large paddings will also lead to allignment oddities. The minimum size of a font should be no less than 8pt for the smallest textual elements. That is very small and a reader definitely needs glasses to read fonts which are smaller, if the printer is even able to output that. If these values don't work for you, then you might have a very different problem. Make sure you try normal fonts like Arial and Helvetica first which everybody has installed before anything else. Also, take into account the aspect ratio of a font and be aware of any auto-grid settings and the fact that unlike the classic client, RDLC layouts have one setting for both horizontal and vertical grid. I can't imagine that your local printers have anything to do with this but when in doubt, try printing to a PDF printer. If the problem persists, I think it really has to be solved in your RDLC layout.
  • gtrgtr Member Posts: 131
    Thanks for this long answer
    In a first time I began with padding of 2pt (I print borders) and only when I saw the problem I began to test different values.

    Thanks for all the other hints - I will have a look.

    Printing on pdf gives the same problem. So you say it comes from rdlc, But I don't really know what to think because all right aligned data in the standard reports I tried are slightly cut.
  • MarijnMarijn Member Posts: 69
    Ok, I ran into a very similar problem. It seems it does not have anything to do with inproper values for padding etc.

    Question: The font which is visible in your screenshot, where did it come from? Did you set it on purpose? Or dit it somehow came from nowhere? I do have some weird rendering problems in 2013 RDLC and one of the symptons is that my default Arial is replaced by a font which looks a lot like yours. I have no idea why but I noticed this on other 2013 installations as well.
  • ppavukppavuk Member Posts: 334
    It looks like you got a problem with your fonts. Does output looks the same if you print on different computer? The default font must be arial, but on screenshot it does not looks like arial.
  • generaljimgeneraljim Member Posts: 8
    I know it's been a couple of years since this post happened, and MS hasn't solved the issue yet, but this has been bothering one of my clients quite a bit, so I bit the bullet and came up with a solution that works for me. In Visual Studio, go to the Properties of the textbox in question, find the Format property, click the right arrow at the end of that, click on <Expression...>, and put in the following:

    =iif([expression_value] = 0,"#","#,##0.00 ;#,##0.00-")

    Replace the [expression_value] with the actual expression for the text box, (like Fields!Amount.Value or whatever the Expression is). Of course I used "#" as the format if the value being printed is 0, but you can make it anything you like. The real important thing is what happens if it's NOT 0. You will see a custom format there with 2 values separated by a semicolon. The first value is for a positive number, and the second is for a negative number. Make sure you put a space at the end of the positive number's format if you're going to be using a trailing minus sign for the negatives. If you will be using a leading minus sign, then make sure that BOTH formats have a trailing space. That will allow decimal points to line up for both positive and negative numbers. I hope this does the trick for anyone else out there that's been beat up by this. I know my forehead is bloody from beating it against the wall! :)
  • rmpatel22rmpatel22 Member Posts: 80
    Replying to old post because we faced similar issue recently.

    If users are printing from terminal server than it will be resolved after applying below hot fix on server.

    https://blogs.msdn.microsoft.com/nav/2013/02/25/nav-2013-reports-may-be-difficult-to-read-when-printing-over-terminal-services/
    Rakesh Patel
    Navision Developer
Sign In or Register to comment.