2

There are several horizontal white space characters in the Unicode standard beyond the usual space & non-breaking space. I tried using some of them with text-align: justify and it appears to my eye that the result is uneven: the «usual» spaces seem to stretch too easily while other spaces hardly stretch at all. For example: in left-aligned passages I can easily spot an odd en-space, in justified — not so, depending on the amount of stretch a line requires.

Hence the question: how do web engines distribute the «justification stretch» across the white space characters of various kinds? What do the algorithms think of, say, «ideographic space», «medium mathematical space», and so on?

Ignat Insarov
  • 4,660
  • 18
  • 37

3 Answers3

3

Not really an answer, but some grist for your mill.

Text justification style (text-justify) in web browsers is erratic. To find the details, you need to look at the code. As of January 2020 my Chrome browser doesn't seem to implement any but auto using the 'play' feature at https://www.w3schools.com/cssref/css3_pr_text-justify.asp

If you want to check spacing, try superimposing a 1 em grid on a text sample. Standard word spacing is 1/3 em. Knuth's algolrithm tries for 2/9 to 1/2 em. Computer screens are harder to read, and you aren't paying for paper. Even ragged right text is set wider than 1/3 em. At a guess checking a few pages, it seems to be 1/2 em

Good justification uses both inter-character and inter-word spacing.(Note: Knuth avoids inter-character spacing) The algorithms to do it well aren't trivial. In the bad old days when a '486 was a fast processor, and desktop publishing (NOT MS word...) was coming into it's own, reflowing a large block of text when you made a change at the beginning was reason to go for coffee. Word, for years, just added extra whole spaces. I'm not a word user now, so can't say if they have upped their game.

My personal experience: Screen text with 25% leading (12pt on 15, 16 on 20) in a serif font, with a minimum line length of 35 characters, and auto-hyphenation looks tolerable, and MUCH better than ragged right.

Further reading:

https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380111102 -- abstact only unless you pay. Donald E. Knuth and Michael F. Plass, Software - Practice and Experience 11 (1981) 1119-1184 DOI: 10.1002/spe.4380111102, also available in Digital Typography, Ch. 3, pp. 67–155. Try your local University library.

Donald E. Knuth and Michael F. Plass, Software - Practice and Experience 11 (1981) 1119-1184 DOI: 10.1002/spe.4380111102, also available in Digital Typography, Ch. 3, pp. 67–155.

See this too: http://defoe.sourceforge.net/folio/knuth-plass.html

Sherwood Botsford
  • 1,889
  • 5
  • 20
  • 35
0

As a knowledgeable person explained to me on Reddit:

I only have easy access to the blink code base and in that it justifies on kSpaceCharacter, kTabulationCharacter, kNewlineCharacter, and kNoBreakSpaceCharacter (0x0020, 0x0009, 0x000A, 0x00A0). The function is called NGInlineLayoutAlgorithm::ApplyJustify.

As far as I can tell from some very brief tests it looks like it is the same in Firefox as well.

Further:

I found how it works in gecko as well and it is quite complicated. There is a long list of "breaking" characters that depend on if the page is rendered in Japanese, Chinese, or a different language. For non-jp/zh languages it works almost exactly as blink.

You can find it here. aLangIsCJ basically means if it is a Chinese or Japanese document.

Ignat Insarov
  • 4,660
  • 18
  • 37
-1

@Ignat Insarov you have use text-align: justify; i think this-> solution will help you. here i have given multiple type of text-align-last you can try on your content i think text-align-last: center; can be helpful,

text-align: justify;
text-align-last: center;
/*OR*/
text-align-last: end;
/*OR*/
text-align-last: left;
/*OR*/
text-align-last: right;
/*OR*/
text-align-last: start;
Hiren
  • 115
  • 4