I've got textbox in SSRS report. Textbox consists of 2 placeholders. Second one is long enough for line to be split several times. I want text to be wrapped on spaces, but it's wrapped on plus and minus signs instead. I need "a-b+" and "Ss-+" to be kept together.
Text is fetched from database, I have full control but can't predict exact length or particular order.
My guess is that engineers who've implemented wrapping thought of plus and minus signs as a part of math formula. That's wrong in my case.
So far I've tried to add HTML tags: makes each block occupy whole line and makes no effect. I need something like display: inline-block
I've tried creating several placeholders for each non-breaking value - no effect.
If I replace plus and minus signs with letters, placeholder wraps text just fine:
One obvious solution would be to calculate required character length to add manual line breaks (vbcrlf). But it can't be done easily since it's not a monospaced font.
Is it possible to prevent word wrapping on plus and minus signs?
Related
See the description before Example 6 in the CommonMark spec at: http://spec.commonmark.org/0.27/#example-5
I am trying to understand how the following code leads to a code-block starting with two spaces.
>→→foo
Example 6 shows that this would translate to the following.
<blockquote>
<pre><code> foo
</code></pre>
</blockquote>
But Section 2.2 clearly states:
However, in contexts where whitespace helps to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters.
So as per my understanding, the above Markdown behaves like the following (I denote a space with a dot).
>........foo
Since, one optional space is allowed after >, and 4 spaces are used to indent code block, we are left with,
>...foo
That's a code-block starting with three spaces. How does CommonMark claim then that it should lead to a code-block starting with two spaces? What am I missing?
The key is in the very first paragraph of the Tabs section (emphasis added):
Tabs in lines are not expanded to spaces. However, in contexts where whitespace helps to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters.
Notice that is says "4 characters" not 4 spaces.
If you configure your text editor to use a tab stop of length four and to replace tabs with spaces (any good text editor should offer this setting), the text editor will use columns that are four characters wide. When you press the tab key, it will forward the cursor to the next column, which will only every be four characters wide. If the column already contains any characters, then only as many spaces are added to total four characters, which, in this case would be less than four spaces.
For example, if you type an angle bracket (>) character in your editor and then press tab, you will get the following (when configured to replace tabs with spaces):
>···
Therefore the angle bracket plus the tab moves forward to the end of the column (four characters) for a total of three spaces. As we are now at the beginning of the next column, pressing tab a second time would move us to the next column (4 more spaces) for a total of 7 spaces:
>·······
We can confirm this is the correct interpretation with a more recent change to the spec committed in 3bc01c5dc (which apparently hasn't made it it to a release yet). As the commit comment suggests, the clarification helps the math make more sense (emphasis added):
Normally the > that begins a block quote may be followed
optionally by a space, which is not considered part of the
content. In the following case > is followed by a tab,
which is treated as if it were expanded into three spaces.
Since one of these spaces is considered part of the
delimiter, foo is considered to be indented six spaces
inside the block quote context, so we get an indented
code block starting with two spaces.
Notice the added sentence (in bold) which confirms that the first tab only adds "three spaces".
Therefore, as we have now established, we start with an angle bracket plus seven spaces. So first we break off the blockquote deliminator, which consists of the angle bracket and the first space (in the following examples the | is used to indicate where the parser breaks the string and should not be counted as characters):
>·|······
The text contained in the blockquote is now indented six spaces. Four of them are the code block deliminator:
>·|····|··
Which leaves two spaces at the start of the code block.
Of course, as stated back at the beginning (of the section in the spec), the tabs aren't actually replaced with spaces, it just behaves as if they were. And that can be confusing at times. It may help to configure your text editor to always replace tabs with spaces and then you can avoid this confusion.
My HTML page contain tables with many negative numbers, like –0.25 . 8211 is the n-dash. Because my document is supposed to become epub2 eventually, javascript is not allowed. only xhtml+css.
Unfortunately, both ebook readers and the print function in Chrome think that it is a reasonable idea to line-break a negative number between the en-dash and the zero, even when there is a space before and/or after, e.g., in a table.
I need a "non-breaking" en-dash? there are non-breakable spaces, after all, too. Or is there a way to instruct css never to break such negative numbers anywhere throughout the entire document? (I doubt this one, but just had to ask.)
of course, I can wrap each negative number into a span to prevent breaking, but this is quite painful. literally, by the time I am all done, my number --0.25 would have to become <span class="nobreak">–0.25</span>. (joke: it's almost like a DOS 10x amplification attack, with 4 chars becoming 40 characters, all because I want to have negative numbers.)
advice appreciated.
/iaw
You can prevent negative numbers from breaking by using the proper MINUS SIGN “−” (U+2212). In
text rendering, browsers, ebook readers, and other software often treat EN DASH as well as HYPHEN-MINUS (the common Ascii hyphen) as allowing a line break after it, even when immediately followed by a digit. No such behavior has been observed for MINUS SIGN.
In HTML, you can write MINUS SIGN as − if you have difficulties in typing the character or if you wish to make it clear to anyone reading the HTML source that MINUS SIGN is used.
In HTML5, how do you skip 5 spaces in a <div>? For example, how do you do this:
"Drumroll... [5 spaces] Something!"
<div>Drumroll... [5 spaces] Something!</div> just outputs "Drumroll... Something!"
There does not seem to be any tags such as <indent> that I have found to indent in the middle of a sentence.
      works, but is there a more efficient way? Such as...
<skip 10px></skip>
Specifically, I am looking for the solution to insert exactly 1,000 spaces easily, for example.
This is not perfectly five spaces, and I'm not sure if there's a way to do it without using five consecutive s, but this will allow you to add a specifiable amount of space inline.
<p>Drumroll...<span style="margin-left:50px;"></span>something</p>
http://jsfiddle.net/5drHj/1/
Another option might be to use the <pre> tag...
<pre>Drumroll... something</pre>
http://jsfiddle.net/5drHj/2/
If you do decide to use consecutive you could use a javascript loop (or php loop for server side construction) to add the 1000 s
Edit: At the risk of losing my tick, I'd like to point out that the answer given by #vals is a third option, and perhaps the most elegant of the three.
No, there is no such element in HTML. Long ago, there was the nonstandard <spacer> tag, but it was abandoned. You are supposed to use CSS for things like this. Wrap some preceding text in a <span> element and set padding-left: 1.25em on it. Tune the value as needed. The width of a space depends on font but is on the average around 0.25em.
The question that you pose in the first half of the question (How to insert spaces easily), is achieved with the property:
white-space: pre;
It means that your text is pre-formatted, and the white spaces should stay as they are. Then just insert those spaces.
fiddle
If you want to insert 1000 spaces, then we are talking probably about alignment, and there is a huge amount of posibilities. (padding specified in em being the most obvious), but you should then give more details of your situation.
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.
I have a comment box, if they enter long one word, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
the box will break(text out of div), i have used overflow:hidden but my friend want it to break like normal text.
Any idea how to fix ?
In order for overflow to hide content that is larger than it's containers' dimensions, the container must have a set width. But even so, CSS doesn't break long words. (Except for IE, which has the word-wrap: break-word instruction. Further reading.)
If you're using some sort of server side processing (I assume you are), you could manipulate text content by breaking up long words at a preset length and thus avoid overflowing.
You need to use whatever server language you have to devise some way to break the string up. You could use a combination of regex (to check for long unbroken strings) and then combine it with some string split function in order to insert some newlines or something.