HTML formatting in a TextBox - preservation of leading whitespace
-
Friday, March 15, 2013 6:26 PM
I have a report - SSRS 2008 R2 SP1 X64 - that contains a textbox, in a tablix, connected to a dataset, from an XML datasource that invokes a SOAP web service. That web service is returning some pre-formatted text, one line per row in the dataset. That web service is also replacing all spaces in the returned text with (or Unicode 0xA0).
That was all working fine until I started experimenting with the HTML formatting supported by the TextBox. Once I enabled parsing of HTML tags in the textbox, all of the leading spaces on my returned data disappeared - even though they're and not simple spaces. Interestingly, some, but not all, excess embedded spaces in the lines are being removed as well - even though they're all as well.
Is there any way to get my whitespace back? It's important because I'm returning pre-formatted text that's displayed in a fixed-width font. If I can't get the leading whitespace back, the HTML formating support is useless to me.
-cd Mark the best replies as answers!
- Edited by Carl Daniel Friday, March 15, 2013 6:29 PM
- Changed Type Carl Daniel Tuesday, March 19, 2013 10:00 PM Not purusing answer any more
All Replies
-
Friday, March 15, 2013 8:00 PM
Have you viewed source on the report when rendered on the web to verify that is being used? The only guess I can make is that that somewhere in the process, is being converted to a plain old space so when rendered as HTML, they shrink down to a single space. You could set the value of the text box in question to something like:
=Replace(existing value," "," ")
If something is converting the to a space, this will convert it back. At the worst it should have no impact. At best it could fix your problem.
"You will find a fortune, though it will not be the one you seek." - Blind Seer, O Brother Where Art Thou
Please Mark posts as answers or helpful so that others may find the fortune they seek. -
Friday, March 15, 2013 8:06 PMI've examined the HTML using the F12 tools in IE9 and it looks like the have been stripped out before it got to IE. I *know* they're at the source, 'cause it's a hard-coded literal string in the web service implementation. In fact, it looks stunningly like the Replace expression that you have up there.
-cd Mark the best replies as answers!
-
Friday, March 15, 2013 9:15 PMHave you tried wrapping your current expression for that text box in the replace as I described? If it is getting converted after the expression is evaluated, it won't help. But if the conversion occurs before the expression is evaluated, the expression should restore your whitespace.
"You will find a fortune, though it will not be the one you seek." - Blind Seer, O Brother Where Art Thou
Please Mark posts as answers or helpful so that others may find the fortune they seek. -
Saturday, March 16, 2013 10:34 PM
It's easy enough to see that the spaces are not being converted elsewhere by simply turning off the HTML interpretation on the placeholder so that it's rendered as plaintext - which I have done, and all of the spaces appear as '
I have done exactly as you suggested also - not surprisingly, it too made no difference.
-cd Mark the best replies as answers!
-
Monday, March 18, 2013 10:07 PM
Hmmm... I don't know what is going on then. I did a quick test on an existing report. I added a textbox and set the value to:
=&"Inbsp; Test"
It displayed the exact text at first, as expected. I switched it to HTML and it displayed "I Test", as you would expect. I added 16 more " " and it added what I have to assume is 16 more spaces, as it should. I also am using 2008 R2, I am pretty sure it is SP1.
All I can suggest is troubleshoot to reduce the factors. Try the same experiment I describe above. What are the results. What if the same experiment is attempted using a textbox in your tablix? What if you try a separate textbox linked to the First(DataField, "YourDataset") where DataField is the field containing the " " and YourDataset is the dataset that returns the field? Try running the report in a different browser.
These tests can help eliminate some of the elements as the possible cause. Also can't ignore the possibility of an issue with the server or IIS.
"You will find a fortune, though it will not be the one you seek." - Blind Seer, O Brother Where Art Thou
Please Mark posts as answers or helpful so that others may find the fortune they seek. -
Tuesday, March 19, 2013 6:49 PMTim - Thanks for the research. If I decide I need the mixture of HTML markup and fixed-format text, I'll try some of those experiments. For now, I'm content with having one or the other - the textbox where I *really* need fixed formatting does not require inline markup, and where I'd really like inline markup, I don't want fixed formatting. I just hate it when two features don't play well together!
-cd Mark the best replies as answers!
-
Thursday, March 21, 2013 11:40 PM
That was all working fine until I started experimenting with the HTML formatting supported by the TextBox. Once I enabled parsing of HTML tags in the textbox, all of the leading spaces on my returned data disappeared - even though they're and not simple spaces. Interestingly, some, but not all, excess embedded spaces in the lines are being removed as well - even though they're all as well.
One correction - there is no change to embedded whitespace. Only leading whitespace is being removed. Simply adding a non-blank character to the start of each line results in all my formatting matching up. In your test, you used a leading non-blank character, which appears to be all that's necessary to have all the whitespace preserved.
An interesting case - adding a leading U+200C (zero-width non-joiner) with HTML formatting enabled has some interesting effects:
- The winforms Report Viewer renders the report perfectly
- The webforms Report Viewer renders the ZWNJ as a vertical bar | character
- Export to Word looks perfect
- Export to Excel looks perfect
- Export to PDF has spacing issues all over the page (it's a mess)
- Export to MHTML renders the ZWNJ as a vertical bar | character.
Using U+2060 (Word Joiner) is fun too:
- The winforms Report Viewer renders WJ as a small box
- The webforms Report Viewer renders the report perfectly.
- Export to Word shows the WJ as a small box
- Export to Excel shows the WJ as a small box
- Export to PDF shows the WJ as a small box, but the spacing issues are resolved
- Export to MHTML looks perfect.
Every other Unicode space character that I've tried (I haven't tried 'em all by a long shot) behaves just like a space - all leading whitespace is lost.
I reported this on connect - there's definitely at least a couple of things wrong here.
-cd Mark the best replies as answers!
- Edited by Carl Daniel Friday, March 22, 2013 2:05 PM

