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.
Related
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?
I have a string that can potentially be empty, and in that case, I want to substitute it with a special character to maintain the ordinary text height while having zero width. In TeX, this would be called \strut. What is the counterpart for that in HTML? I came up with two candidates: and . Should I use one of these?
On modern browsers, any zero-width character will do the job, provided that the browser either knows that the character is zero-width or uses a font that contains an empty glyph for it. But some characters may have effects, depending on the context and on software used to process the HTML file.
U+2060 WORD JOINER has the effect of preventing line break.
U+FEFF ZERO WIDTH NO-BREAK SPACE has the same effect. It is formally deprecated for any use except as Byte Order Mark, but in reality it works more often than WORD JOINER (though there are exceptions).
U+200B ZERO WIDTH SPACE has the effect of allowing a line break even when it would otherwise not be permitted; it’s like SPACE, but with zero width.
Usually the worst-case scenario for characters like this is an old version of IE. Checking in IE 6 shows that U+FEFF and U+200B are OK, but U+2060 shows as a small rectangle (i.e., the browser tries to render the character but finds no glyph for it).
So I’d use or depending on whether I’d like to prevent or allow line break at that point. If it does not matter, is more logical to use.
I would suggest or if zero width is not essential or if it is essential you could try the Unicode character which is a zero width non-breaking space.
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 need to determine minimum width adequate for displaying a possibly wrapped dynamic HTML string. Without word-wrapping this is simple: create a span, set its innerHTML and read offsetWidth. However, I'm not sure how to force linebreaks... Easiest incomplete approach I see is to replace all spaces by <br/>, but lines can be wrapped not only on spaces but also e.g. on hyphens.
So, basically, I want a browser to lay out sth. like
Max.
word-
wrapped
string
<----->
somewhere off-screen to measure width of the longest contained word. Is there a generic way to do that?
EDIT
I.e., for no line wraps:
function computeWidth (str) { // code to make it off-screen and caching omitted
var span = document.createElement ('span');
document.body.appendChild (span);
span.innerHTML = str;
return span.offsetWidth;
}
How would I write a similar function which forces line breaks on str, presumably playing with span.style?
You can use CSS work-break / word-wrap and programmatically inserted soft-hyphens (, but I'd advise you to read up on cross browser problems regarding soft hyphens, as there are quite a few - I normally us the unicode for a soft hypen (U+00AD), but your mileage may vary), and then determine the width with javascript using the range object and measuring cursor offset from the left.
I'm suggesting the use of soft-hyphens, because even the same browser will normally break words differently depending on the OS / which dictionary (on OSX) is used. If that's not an issue for you, you can do it without soft hyphens.
Afaik there is no generic way to get what you want in html/js (it's different if you were using something like flash).
Range object:
https://developer.mozilla.org/en-US/docs/Web/API/range
A different approach would be using the canvas object, but you would probably not get exact results there, as there is just too much factors influencing text rendering in browsers nowadays (font, size, kerning, tracking, ...)
Again another approach would be using <pre> tags / whitespace: pre-wrap, setting the font to what you normally use, and then either emulate breaking words by inserting linebreaks or copying them from still another span/div/whatever set up with word wrap - I haven't tested this yet, but if it works, it might be easer than iterating with the range object.
Edit: Just so it's not only in the comments, still another solution:
Start your container with width 1px, then increase the width, checking the height every time ; when the height decreases, go back one step, and you got your width. Simplest implementation would use 1px increase/1px decrease, but you could of course optimize it to using something like a binary search algorithm, e.g. starting with 1px, then 2px, then 4px increases, then the same backwards, and forwards again and so on till you have a result at a 1px step. But that's only if the 1px inc/dec sollution is too slow ;)
Use the CSS word-break rule:
The word-break CSS property is used to specify how (or if) to break lines within words.
Normal
Use the default line break rule.
break-all
Word breaks may be inserted between any character for non-CJK (Chinese/Japanese/Korean) text.
keep-all
Don't allow word breaks for CJK text. Non-CJK text behavior is same as normal.
<p style="word-break:break-all;">
Max.word-wrapped string<----->
</p>
(source)
Try to play with the word-break Property.
More here: http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_word-break
You should try:
word-break: break-all;
Add it to the CSS like in this fiddle, or read here.
Such as this sentence:
عفواً يبدو أن النظام لا يستطيع تحديد أنك من عملاء STC أم لا، فإذا كنت عميل STC الرجاء الضغط على زر "إعادة المحاولة"، وإذا لم تكن من عملاء STC الرجاء الضغط على زر " لست عميل STC
Arabic is RTL and English is LTR. Sometimes after copy and paste the text goes disorder. When I move the cursor inside the sentence between English and Arabic characters it jumps in a very strange way. And I am also confused with how this stored in the memory. Can anyone help to explain this?
In memory this is all stored as a sequence of Unicode code points (hopefully; there were very werid things before that, but let's not go there) – that's the text itself, how it is represented in the computer. The text is independent from writing direction at first, it's just a sequence of characters.
This sequence goes through a rendering engine that knows the Unicode Bidi algorithm and thus can shape the text into glyphs to display at a particular position. Every character in Unicode has a Bidi property that controls how it behaves in such contexts. This specifies that a is a LTR character while א is an RTL character; it controls that parentheses are correctly mirrored in RTL contexts (an opening parenthesis is still ( in the text, even though you see )); and several characters can appear in both contexts. This is all very simplified, and there are quite a few things at work there. Finally, multiple glyphs can overlay each other (e.g. diacritics) or form ligatures; those are then graphemes which is essentially what we perceive as a “letter”.
Cursor movement is easy to do then, because the cursor can only be betweeen two graphemes (it gets more complicated at the start of a LTR or RTL segment, but let's leave it at that for now) and → moved it forwards through them while ← moves backwards. In RTL forwards means left, of course; it follows the text direction. What order the two graphemes have relative to each other doesn't really matter in positioning the cursor.
I admit though, that it can be confusing to see mixed RTL and LTR text, but I guess people in Arabic- or Hebrew-speaking countries are quite used to it.
Regarding the problem that the correct text layout is sometimes lost when you copy-paste text, I guess the most common problem is application or layout engine support for the respective script. If the layout engine does not know how to layout Arabic text all you get are the characters in their logical order from left to right. No ligatures are formed, no text direction applied. For example, browsers have quite good support by now for this kind of thing, but if I take the Arabic text and paste it into Word it will look wrong (was the case for Word 2007; PowerPoint did it fine, though). There is sadly no easy fix for that, but generally the text you copied is exactly the same, it's just the display that's wrong.
Disclaimer: I have lurked for a long time on the Unicode mailing list, but I'm by no means an expert on these things. I speak two languages and both are trivial what layout is concerned. This is a recollection of how I think it might work and might not be actual fact.
The letters are stored in logical order; meaning that a sentence such as "Hello! Salaam!" is in fact stored with the letters in precisely that order.
In addition to that, however, certain unicode flags are also added to the text that inform the text layout engine that the "Salaam" part of the sentence should be reversed when displayed; so the final text layout becomes "Hello! maalaS!", as well it should be.
These flags are either set through natural BIDI classification; e.g. غ; or through use of the Unicode RTL and LTR markers, U+200E and U+200F.
If you pay attention, the cursor doesn't in fact jump strangely, it always follows logical character order.