Table word warp not breaking onto new line - html

Having a strange issue when in jquery datatables where a column will resize and wrap contence when it contains a url like "http://foo.bar.co.uk?test=true&derp=reallyLongParam12345678901234578" it breaks it onto 2 lines at the ? however when it contains a link like "http%3A%2F%2Fdirectproducts.go2cloud.org%2Faff_c%3Foffer_id%3D149&aff_id=1041&aff_sub=white_bluepreland"
It doesn't know how to split this.
Is there anyway to specify more characters that it can split to the next line with as it is causing my table to be wider than the screen.
Note
The badly formated url has been fixed and is just an example

Related

SSRS - Adding empty cells under a tablix to fill empty spaces on the page (if any)

I work with ssrs with a dynamic row data in matrix/tablix. There is possibility when I have more than one page (say it two pages) where the data just fill half of the second page and leave a blank space below (half page blank space on the second page). How is the way to fill this blank space with empty rows? (whether rendering empty rows in the tablix, or inserting background image, or anything. I don't have any solution yet as it is dynamic data with many possibilities of the blank space size on the page)
Unfortunately there aren't any settings in the reporter that support this behavior. There are however several workarounds you could use to get the wanted result.
[1]
You could determine the amount of rows that fit on the first page and on the second page, just in case you have items above the
table on the first page. Before you send the datasource to the
reporter count the total rows and check if it exceeds the first page.
Then calculate the number of rows missing to fill an entire second
page (or third/fourth... if you ever get more data). Finally you add
empty rows/objects at the end of your datasource, which will of cource
cause the pages to be filled to the end.
As was pointed out before, this solution is only possible when working
with fixed row heights. If certain columns can have multi-line cells
then these could be checked as well and taken in account when
calculating the number of rows being displayed on the page. This makes
it slightly more complicated but is still a valid solution if you can
predict which columns might be troublesome.
[2]
A second solution would be to hide the table borders and place the table inside a rectangle that spans the maximum size of the
page. The borders of this rectangle can be used to display the table
outer borders and columns can be displayed by adding lines inside the
rectangle. This will cause the columns to fill the last page of the
report automatically. Unfortunately this isn't a solution to display
horizontal grid lines.
[3]
A third approach is adding an extra table directly below your table
with the same size of columns. Using the same method as from the first
solution you could fill the second table to represent the empty rows.
You'll probably have the same issue as with the first solution when
dealing with multi-line rows though.
I believe solution [1] and [3] will offer the most exact solution, if you're willing to do the math. If you don't want any horizontal lines then I suggest using approach [2].
Using an image to overlay the borders is of course another option but then you'll have the same issues when dealing with the multi-line rows. If you plan on working with fixed row heights, where you leave space for multi-line cells then this is becomes a valid approach but so does solutions [1] and [3].
Update:
If you only need the filled pages for printing you could make sure you add enough empty rows to fill at least the entire last page, these may go to a new page (1 new page, not 2... you can use a simple calculated guess for this) and exclude the last page when printing.

How to break label in ssrs

I have one label which is taking value from database.And the value of label is more than 20 lines.
While displaying that label in pdf ,if label is very big then it is rendering on second page and my first page is half blank.
so I want to break that label on two pages so it will start on first page only and then it will break and then it will render on second page.What can i do for that?
Unfortunately, determining where to put page breaks on the fly is a weak point of SSRS.
Perhaps you could break up the long text into multiple rows in the data source (splitting on spaces between words). This would result in funny looking breaks in the output as you won't know for sure where the break will appear in a line on the printed report.
If the text has reasonably sized paragraphs, you could parse it out that way instead using line breaks.

SSIS: Fixed Width Columns Aren't Displaying Correctly

I am trying to create a fixed width flat file import spec in SSIS. When I set up all of the columns with the correct widths and preview them, the first row is correct but all of the other rows are off.
example:
Row 1: Text
Row 2: [space]Text
Row 3: [space][space]Text
What am I doing wrong?
Thanks in advance!
I have experienced something similar to this whenever I first sat up a fixed width column and did not properly adjust for the data between the end of text (or delimiter) to the next line. The data in this area is usually spacing and the carriage return/line feed. To adjust properly, I created one extra column that handled the data from the end of text (or delimiter) to the next line. This fixed my spacing issue.

How to resolve issue where table column is too narrow?

I'm new on this particular project, and I've been tasked with resolving an issue that's appearing in IE8.
If you check http://funds.ft.com/ETFHomepage.aspx, There's a section called "News". In that section, there's a column called "Most Popular ETFs". This should be the same width as the "Recently Viewed ETFs" column.
For reference, this page is appearing correctly in Firefox. Can somebody please point out what I can do with CSS or (some other means)* to resolve this?
*I know the best way to resolve this issue is to scrap the terrible design and implement it correctly!! :-) -- we're actually doing that right now. It's a big job, so it's taking a long time. In the mean time however, we have to fix the bugs as they appear. Thanks
Update: just to note what I've said to Hristo, "I think the problem is with the table (rather, nested tables) on the left. The table in the center has its width defined by the image, and the table on the right doesn't have an image so it gets crushed"
Well the reason this is happening is because of the url you have under the "Alphaville: Overcoming the Volcker rule, with ETFs" header. Since the url has no whitespace in it, the table tries to give it space. So there are a couple of ways to fix this problem:
Plain text urls aren't very becoming on a webpage (especially when they're not in anchor tags so you can click on them.) Could you update the content so that you don't have a raw url in your content?
If you must be able to handle long lines of text with no whitespace then you need to figure out how to change the layout of the page so it forces the text to either wrap or clip to fit the container. Try playing around with putting "table-layout: fixed" on your tables to force the column widths to be sized based on the table's specifications only (instead of content). Firefox seems to be wrapping on dashes and slashes in the url whereas IE only wants to wrap on the dashes in the url.
I would say your layout is fine, and you just need to fix the content generation so it doesn't include any long plain text urls (option 1 above)
EDIT: If you do decide to go with option 2 above, then look into the css rule "word-break: break-all". It is IE only and it forces the text to break as soon as it reaches the end of the container. Not good for words, but it works for url's. So you couldn't apply this to the whole news table, but you could to just the cell that contains the url.

Dealing with very tall textboxes and pagination in SSRS 2005

I have a report in SQL Server Reporting Services 2005. It makes use of a page header and footer and has no subreports. The body portion contains a few smaller elements and then a simple single column table. The table has a single header row and a single detail row. The header is just a label, basically. The detail row is a single textbox with a simple Fields!FieldName.Value as its output.
The problem is that FieldName, in this case, is a highly variable length string. It can be a sentence up to 8000 characters (usually no more than 2 pages worth). The text can contain line/paragraph breaks (returns) but no other special formatting. Everything is fine so long as the content fits on one page. Once the text exceeds a single page (8.5x11), the text is very nastily cut off abruptly. Since this is a pagination problem, it is only visible when exporting to PDF or when viewing the report in Print Layout.
It seems as though there is a maximum size the row can grow to on the first page and then it chops it off and starts it up on the second. But this cutoff is not carefully managed in relation to the text. It can occur right in the middle of a line, causing it to show the top halves of the letters on the first page and the bottom halves at the top of the second page.
Obviously, this is unacceptable, as it looks very unprofessional and can impair the readability of the line that was so messily split. I also can never be sure it'll split badly, as sometimes it more or less ends the page evenly, though usually I can still see the hanging tails of certain letters on the next page (g and p for instance).
The secondary problem is that I'd really like the table row header to repeat on each page. Setting the obvious property, "RepeatOnNewPage" has no effect. I suspect this is because it's still trying to show the single really vertically tall row. It seems like it's okay repeating headers and splitting pages nicely between detail rows. But because this is basically just a big block of text, and thus just one really tall row, it doesn't split it nicely.
What can I do or use to solve this problem? I can live without the repeating header so long as it just doesn't cut off text in the middle of a line.
Unfortunately, page break fine tuning is one of the biggest weak points of SSRS.
I can only suggest that you break up the long text into multiple rows before SSRS ever gets it. You'd want to parse the text to look for word breaks. The result will be odd looking breaks in the output since you won't know where the break will come on a line in the printed report. However, it'd be much more readable than cutting text in half.
If the text is comprised of reasonably sized paragraphs, you could parse it out that way instead.
You might even go so far as to measure the text using SQLCLR and the System.Drawing.Graphics.MeasureString method to fine tune the output but I wouldn't recommend that route for the feint of heart.
In SSRS 2008 R2 and Visual Studio 2008:
Click (not-right click) a textbox and go to the properties window (lower right side of VS) -> KeepTogether = false.
The text will cleanly cut between a line and continue on the next page.
Just thought to add here as searching for this doesn't return many results.
I have done what JC has suggested in the past where I've broken down the text into paragraphs and each paragraph would in effect be its own row. Works pretty well given the limitations of SSRS.
One thing to be careful about is that you would need to make sure that your paragraphs sort properly. In most cases it would display them in the correct order, but adding in a column with sortID to give some sorting hints to the table would probably be a good idea.
In the end, the cut-off-text problem was due to non-standard padding on the textbox in question.
For whatever reason, having padding any greater than the defaults (2pt all around) seemed to cause its pagination to go sour. I imagine it is due to the algorithm not taking padding into consideration when deciding where to break the paragraph. With default padding, the line always ends cleanly and nicely on each page.
As a workaround (since I liked the extra white space the padding gave to the layout), I used a rectangle to achieve the border and made the textbox inside it smaller than the rectangle by about an eighth of an inch. This gave the box some inner padding while still apparently allowing the pagination to correctly determine when to break up lines.
Still, a lot of unnecessary headache.