adding white space in &lt;p&gt;

In article <11**********************@g44g2000cwa.googlegroups .com>,
Xah Lee favored us with...

ah,   is it! I always thought it just prevent linebreak...

btw, is there a unicode equivalent?

That _is_ Unicode; but if you're going to use more than one, use a
style instead.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

Sep 1 '05 #7

Xah Lee wrote:

ah,   is it!
No it isn't. (P.S. The usual way on Usenet to tell that you failed to
understand a message in its entirety is to quote it in its entirety
after your own comments. This time, there wasn't much to be understood,
though, and although you understood the message correctly, the message
was wrong.)

If you check the HTML specification (as people should do at least before
offering advice on HTML in public), you will see that explicitly says
that the rendering effect of no-break space is undefined.

On the practical side, although most browsers render no-break space as
"noncollapsible space" of some fixed font-dependent width, this gives
you horribly poor "control" over layout, as compared with the nice tools
of CSS. Besides, using   (or the no-break space character itself)
unnecessarily obfuscates your HTML source. It's not meant to be part of
the content but just affect visual rendering.
I always thought it just prevent linebreak...

Keep thinking that way, for the most of it.

Sep 1 '05 #8

Pierre Goiffon

Jukka K. Korpela wrote:

If you check the HTML specification (as people should do at least before
offering advice on HTML in public), you will see that explicitly says
that the rendering effect of no-break space is undefined.
Do you have any URL ? I just checked the HTML 4.01 recommandation and
didn't find nothing :/
using   (or the no-break space character itself)
unnecessarily obfuscates your HTML source. It's not meant to be part of
the content but just affect visual rendering.

But you must add a non breakable space before characters such as ":",
"(" or ";"... It's not just all about an entire phrase that you want to
stay on the same line.

Sep 1 '05 #9

Pierre Goiffon wrote:

Jukka K. Korpela wrote:
If you check the HTML specification (as people should do at least
before offering advice on HTML in public), you will see that
explicitly says that the rendering effect of no-break space is undefined.
Do you have any URL ?

Of course.
I just checked the HTML 4.01 recommandation and
didn't find nothing :/

Well, if you did not find anything explicit about the rendering effect
being defined or undefined, then you should regard it as undefined,
right? So revealing the URL will just make this explicit:
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1

Oh well, I might quote the relevant bits:

"In HTML, only the following characters are defined as white space
characters:

ASCII space ( )
ASCII tab (	)
ASCII form feed ()
Zero-width space ()

Line breaks are also white space characters."

and somewhat later

"This specification does not indicate the behavior, rendering or
otherwise, of space characters other than those explicitly identified
here as white space characters. For this reason, authors should use
appropriate elements and styles to achieve visual formatting effects
that involve white space, rather than space characters."

(Taken literally, this also means that the effect of no-break space on
line breaking is undefined, too. But they hardly meant that.)

using   (or the no-break space character itself)
unnecessarily obfuscates your HTML source. It's not meant to be part
of the content but just affect visual rendering.

But you must add a non breakable space before characters such as ":",
"(" or ";"... It's not just all about an entire phrase that you want to
stay on the same line.

I have no idea of what you are talking about here and how it relates to
the piece of my text you quoted, or to the original question (which was
fairly vague, since there are so many ways to add white space to a
paragraph).

Sep 1 '05 #10

Benjamin Niemann

Jukka K. Korpela wrote:

Pierre Goiffon wrote:
Jukka K. Korpela wrote:
If you check the HTML specification (as people should do at least
before offering advice on HTML in public), you will see that
explicitly says that the rendering effect of no-break space is
undefined.

Do you have any URL ?

Of course.
I just checked the HTML 4.01 recommandation and
didn't find nothing :/

Well, if you did not find anything explicit about the rendering effect
being defined or undefined, then you should regard it as undefined,
right? So revealing the URL will just make this explicit:
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1

Oh well, I might quote the relevant bits:

"In HTML, only the following characters are defined as white space
characters:

ASCII space ( )
ASCII tab (	)
ASCII form feed ()
Zero-width space ()

Line breaks are also white space characters."

and somewhat later

"This specification does not indicate the behavior, rendering or
otherwise, of space characters other than those explicitly identified
here as white space characters. For this reason, authors should use
appropriate elements and styles to achieve visual formatting effects
that involve white space, rather than space characters."

(Taken literally, this also means that the effect of no-break space on
line breaking is undefined, too. But they hardly meant that.)

My interpretation of the spec: the behaviour of the listed whitespace
characters is explicitly defined by the HTML spec, because it is different
from the 'normal' behaviour (consecutive whitespace collapsed to one,
linebreak completly ignore after start tags/before end tags, etc.). That
'this specification' does not define the behaviour of certain characters,
does not imply that their behaviour is undefined - it just means that the
'default' behaviour applies (in this case from unicode).
--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

Sep 1 '05 #11

On Thu, 1 Sep 2005, Jukka K. Korpela wrote:

Pierre Goiffon wrote:
But you must add a non breakable space before characters such as
":", "(" or ";"...

I have no idea of what you are talking about here and how it relates
to the piece of my text you quoted, or to the original question

In some languages (not English), it is conventional typography to
include white space before certain punctuation characters, and I
suspect that Pierre is referring to this (I guess French is such a
language?).

I honestly don't know how this is meant to be handled in HTML. By
rights, the *rendering* agent should apply the correct rules of
typography for the language in question, so there should be no need
for anything extra in the HTML. But, practical issues might indicate
in another direction.

h t h

Sep 1 '05 #12

Benjamin Niemann wrote:

[ comprehensively quoting my message, i.e. using the usual convention
to indicate lack of comprehensive reading ]

My interpretation of the spec: the behaviour of the listed whitespace
characters is explicitly defined by the HTML spec, because it is different
from the 'normal' behaviour (consecutive whitespace collapsed to one,
linebreak completly ignore after start tags/before end tags, etc.).
You are referring to some undefined "'normal' behaviour". What is normal
in HTML is an HTML matter, and what is normal for rendering plain text
is something completely different.
That
'this specification' does not define the behaviour of certain characters,
does not imply that their behaviour is undefined - it just means that the
'default' behaviour applies (in this case from unicode).

There is absolutely no statement in HTML specifications that makes any
claim or requirement on conformance to Unicode. The specifications
_only_ define the meanings of character references in terms of Unicode
(actually, the equivalent ISO 10646).

Sep 1 '05 #13

Henri Sivonen

In article <Pi*******************************@ppepc56.ph.gla. ac.uk>,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

On Thu, 1 Sep 2005, Jukka K. Korpela wrote:
Pierre Goiffon wrote:
But you must add a non breakable space before characters such as
":", "(" or ";"...
I have no idea of what you are talking about here and how it relates
to the piece of my text you quoted, or to the original question

In some languages (not English), it is conventional typography to
include white space before certain punctuation characters, and I
suspect that Pierre is referring to this (I guess French is such a
language?).

French indeed is. See
http://lists.w3.org/Archives/Public/...4Aug/0073.html

Are there others?
I honestly don't know how this is meant to be handled in HTML.
In practice the NO-BREAK SPACE works.
By rights, the *rendering* agent should apply the correct rules of
typography for the language in question, so there should be no need
for anything extra in the HTML.

I think it would be quite unreasonable to expect the UA to know enough
about every language to implement comprehensive DWIM. Case study: <q>
with language-specific generated quotation marks. I think the author
should put a character there.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

Sep 1 '05 #14

On Thu, 1 Sep 2005, Henri Sivonen wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
In some languages (not English), it is conventional typography to
include white space before certain punctuation characters, and I
suspect that Pierre is referring to this (I guess French is such a
language?).
French indeed is. See
http://lists.w3.org/Archives/Public/...4Aug/0073.html

Thanks!

By rights, the *rendering* agent should apply the correct rules of
typography for the language in question, so there should be no
need for anything extra in the HTML.

I think it would be quite unreasonable to expect the UA to know
enough about every language

Something of the kind is essential for some writing systems, e.g
Arabic. HTML specs don't really make it too clear how far that
should go, however.
Case study: <q> with language-specific generated quotation marks.

Well, that attempt was problematic on two levels, IMHO.

1. it wasn't implemented widely enough (and has no graceful fallback
behaviour)

2. the HTML specification is unclear about how its language
sensitivity should behave. Under the <q> element it's not defined, it
merely says:

User agents should render quotation marks in a language-sensitive
manner (see the lang attribute).

and the example has been carefully chosen to avoid illustrating the
issue!

Neither here nor under the "lang=" attribute can I find it made
clear whether the quotes should be rendered in the language of the
quotation, or of the enclosing text, or the base language.

Books on typography which I have consulted require the *latter*, so it
would seem that in this kind of pattern:

<sometag lang="A">blah blah <q lang="B">twas brillig</q> blah blah

the <q lang="B"> mark should be rendered according to the
quotation mark convention of language "A", which some might find
counter-intuitive.

The only (English-language) publishing style guide which I found where
the issue was addressed of a quote inside a quote inside regular
(English) text, where all three languages were different, firmly
required *all* the quotation marks to conform to English[1]
conventions, i.e "double" quotes on the inner quote and 'single'
quotes on the outer one. I.e NOT using the quotation mark convention
of the outer quote's language to delimit the inner quote!

best regards

[1] That's the opposite of the American rule, btw.

Sep 1 '05 #15

Pierre Goiffon

Henri Sivonen wrote:

But you must add a non breakable space before characters such as
":", "(" or ";"...

I have no idea of what you are talking about here and how it relates
to the piece of my text you quoted, or to the original question
In some languages (not English), it is conventional typography to
include white space before certain punctuation characters, and I
suspect that Pierre is referring to this (I guess French is such a
language?).

French indeed is. See
http://lists.w3.org/Archives/Public/...4Aug/0073.html

Yes, thanks Alan and Henri, and sorry I thought it was a very common
typographic use (I mean, practiced for many languages)
So yes, in french there are precise rules to follow with punctuations
marks and spaces. And when you have a space before a punctuation sign,
then it must be a non breakable space, in order to avoid something like :

Bonjour et bienvenue<wrap to new line>
<space>!

ie keep the exclamation mark on the same line as the text.
In practice the NO-BREAK SPACE works.

We discussed about that point a lot in fr.comp.infosystemes.www.auteurs,
and the point is that   as the equivalent character is widely
supported - in fact, no one has never reported that this wasn't behaving
as expected (display as a normal space but prevents a line break) in any
browser (which isn't enough to think any brower will behave exactly the
same, but you know what can be said : curious coincidence :) ).

Maybe the assumption made by Benjamin Niemman (see
<df**********@online.de>) is a good explanation.

Sep 2 '05 #16

Tim

"Alan J. Flavell":

By rights, the *rendering* agent should apply the correct rules of
typography for the language in question, so there should be no need for
anything extra in the HTML.

Henri Sivonen:
I think it would be quite unreasonable to expect the UA to know enough
about every language to implement comprehensive DWIM.
Hmm, I dunno. Browsers already have a lot of options about what language
you prefer, how to handle various types of data content, etc. I don't
think it's too much for a browser that has a French release, for instance,
to use French methods of typology by default. I don't think that should
extend to putting in extra spaces where the author ought to have put them
in themselves, but perhaps the line wrapping should be aware of where it's
*not* a good place to break lines, following the language's general rules,
for instance.
Case study: <q> with language-specific generated quotation marks. I
think the author should put a character there.

I agree about this. I think a document ought to be typed as you'd
normally *type* it, just add markup around content to give more/specific
meanings to things.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

Sep 2 '05 #17

Under Subject: Re: adding white space in 
Pierre Goiffon <pg******@free.fr.invalid> wrote:

So yes, in french there are precise rules to follow with punctuations
marks and spaces. And when you have a space before a punctuation sign,
then it must be a non breakable space, in order to avoid something like :

Bonjour et bienvenue<wrap to new line>
<space>!

Actually if you wrote just
Bonjour et bienvenue !
and a nasty line break occurred, it would appear between the space and the
exclamation mark, leaving just the latter and not the space on the next
line.

In practice the NO-BREAK SPACE works.

We discussed about that point a lot in fr.comp.infosystemes.www.auteurs,
and the point is that   as the equivalent character is widely
supported - in fact, no one has never reported that this wasn't behaving
as expected (display as a normal space but prevents a line break) in any
browser

That's right, but HTML specifications do not _require_ such behavior.

Moreover, the actual browser behavior does _not_ produce typographically
(or orthographically, depending on your definitions) correct results for
French punctuation. The no-break space is treated as having the width of a
normal space, which is too much - the spacing should be "espace fine",
which is considerably narrower. Moreover, in justification (which
admittedly should be avoided on Web pages) a no-break space acts as a
fixed-width space, i.e. it is neither shrunk nor expanded according to
justification needs.

The problem is that we would need a suitably narrow space, but there is no
such character in Unicode. (There is narrow no-break space, but it is
both theoretically questionable here and practically almost useless
due to lack of browser support.) There's no good solution at present, and
the no-break space is probably the least of evils in most cases. On special
occasions, where typography really matters, you might take the extra
trouble of adding some relatively unnatural markup in order to be able to
use CSS to reduce the spacing, as outlined at
http://www.cs.tut.fi/~jkorpela/html/french.html#spacing
(old document, partly dated, sorry).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Sep 2 '05 #18

Henri Sivonen

In article <pa****************************@mail.localhost.inv alid>,
Tim <ti*@mail.localhost.invalid> wrote:

"Alan J. Flavell":
By rights, the *rendering* agent should apply the correct rules of
typography for the language in question, so there should be no need for
anything extra in the HTML.

Henri Sivonen:
I think it would be quite unreasonable to expect the UA to know enough
about every language to implement comprehensive DWIM.

Hmm, I dunno. Browsers already have a lot of options about what language
you prefer, how to handle various types of data content, etc. I don't
think it's too much for a browser that has a French release, for instance,
to use French methods of typology by default.

I think the rendering should not depend on the UI language of the
browser release. The approach might work for French, but there are many
more languages in the world and no one is going to build special
releases with different layout rules for all of them. (Arabic [writing
system--not just one language] was mentioned in the thread, but to the
extent Arabic is supported, it is supported regardless of the language
of the browser release.)

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

Sep 3 '05 #19

On Sat, 3 Sep 2005, Henri Sivonen wrote:

Tim <ti*@mail.localhost.invalid> wrote:
Hmm, I dunno. Browsers already have a lot of options about what
language you prefer, how to handle various types of data content,
etc. I don't think it's too much for a browser that has a French
release, for instance, to use French methods of typology by
default.

I think the rendering should not depend on the UI language of the
browser release. The approach might work for French, but there are
many more languages in the world and no one is going to build
special releases with different layout rules for all of them.
(Arabic [writing system--not just one language] was mentioned in the
thread, but to the extent Arabic is supported, it is supported
regardless of the language of the browser release.)

I agree with you. Supporting the document rendering conventions for a
particular language or writing system might be an optionally-
installable extra[1], but if the support is present then I'd prefer
that it should be used dependent on the /document being rendered/, and
not on the current /user interface language/ selection.

all the best

[1] in the sense that the browser designer might want to keep a "lean
and mean" browser installation for users who don't grok other writing
systems.

Sep 3 '05 #20

RobG

Jukka K. Korpela wrote:
[...]

Moreover, the actual browser behavior does _not_ produce typographically
(or orthographically, depending on your definitions) correct results for
French punctuation. The no-break space is treated as having the width of a
normal space, which is too much - the spacing should be "espace fine",
which is considerably narrower. Moreover, in justification (which
admittedly should be avoided on Web pages) a no-break space acts as a
fixed-width space, i.e. it is neither shrunk nor expanded according to
justification needs.

Amen to that.

An "espace fine" (also called a half-space?) should be placed between
values and units, e.g. 25 m (25 metres) should have only half a space
between the '5' and 'm'. It is nearly always written as 25m because of
either ignorance of proper spacing or because a full space is thought to
look worse than no space. If variable size dashes (hyphen, 'n' and 'm'
dash) can be widely supported, why not variable-size spaces?

[...]

--
Rob

Sep 5 '05 #21

Zif

Tim wrote:
[...]

to use French methods of typology by default.

'Typology' is the study of type, I think the word you are after is
'typography', which is the arrangement and appearance of printed matter.

<URL:http://dictionary.reference.com/search?q=typology>
<URL:http://dictionary.reference.com/search?q=typography>

[...]

--
Zif

Sep 5 '05 #22

RobG

RobG wrote:

Jukka K. Korpela wrote:
[...]
Moreover, the actual browser behavior does _not_ produce
typographically (or orthographically, depending on your definitions)
correct results for French punctuation. The no-break space is treated
as having the width of a normal space, which is too much - the spacing
should be "espace fine", which is considerably narrower. Moreover, in
justification (which admittedly should be avoided on Web pages) a
no-break space acts as a fixed-width space, i.e. it is neither shrunk
nor expanded according to justification needs.

Amen to that.

An "espace fine" (also called a half-space?) should be placed between
values and units, e.g. 25 m (25 metres) should have only half a space
between the '5' and 'm'. It is nearly always written as 25m because of
either ignorance of proper spacing or because a full space is thought to
look worse than no space. If variable size dashes (hyphen, 'n' and 'm'
dash) can be widely supported, why not variable-size spaces?

Should have added that variable size spaces are available:

ensp U+2002 (8194) HTML 4.0 EN SPACE
emsp U+2003 (8195) HTML 4.0 EM SPACE
thinsp U+2009 (8201) HTML 4.0 THIN SPACE

Firefox supports them (though in some fonts the thin space is barely
distinguishable from an ordinary space) - IE doesn't support any of them.

[...]

--
Rob

Sep 5 '05 #23

On Mon, 05 Sep 2005 01:01:20 GMT in
comp.infosystems.www.authoring.html, RobG favored us with...

Should have added that variable size spaces are available:

ensp U+2002 (8194) HTML 4.0 EN SPACE
emsp U+2003 (8195) HTML 4.0 EM SPACE
thinsp U+2009 (8201) HTML 4.0 THIN SPACE

Firefox supports them (though in some fonts the thin space is barely
distinguishable from an ordinary space)

In Georgia (under Moz 1.7), is _wider_ than   !

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

Sep 5 '05 #24

RobG <rg***@iinet.net.au> wrote:

RobG wrote: - -
An "espace fine" (also called a half-space?) should be placed between
values and units, e.g. 25 m (25 metres) should have only half a space
between the '5' and 'm'.
That's quite different from the issue of French spacing, which is part of
French orthography (or typography). The width of a space between a value
and a unit is not specified in standards or specifications, which normally
mention just space in this context.
It is nearly always written as 25m
Hardly. Such presentation might be common in the US as well as among
engineers elsewhere, but in quality texts, the correct spelling is used.
(It is the correct spelling according to the SI, the international system
of units, as well as according to many other standards and specifications.)
because
of either ignorance of proper spacing or because a full space is
thought to look worse than no space.
Ignorance explains most of what people do, but here we can see some reasons
that make sense, at least in superficial analysis:
- people don't want to have a line break between "25" and "m"
- people don't want the spacing between them expand on justification.
In HTML authoring, we can and should use a no-break space to prevent a line
break, and we should not justify text. But many people don't know this.
If variable size dashes (hyphen,
'n' and 'm' dash) can be widely supported, why not variable-size
spaces?

Because they are not part of windows-1252. Moreover, in Unicode, they are
compatibility characters, i.e. introduced only for compatibility with other
standards and round-trip convertibility, and they are commented with notes
that say thay fixed-widh spaces (_this_ is the term) are normally not used
in modern typography.
Should have added that variable size spaces are available:

ensp U+2002 (8194) HTML 4.0 EN SPACE
emsp U+2003 (8195) HTML 4.0 EM SPACE
thinsp U+2009 (8201) HTML 4.0 THIN SPACE
There are several other space characters, see
http://www.cs.tut.fi/~jkorpela/chars/spaces.html
Contrary to popular belief, entities (&ensp; etc.) are irrelevant to the
question which characters we can use in HTML.
Firefox supports them (though in some fonts the thin space is barely
distinguishable from an ordinary space) - IE doesn't support any of
them.

That's a wrong analysis. Neither browser has any support to the fixed-width
spaces beyond the simplistic implementation of rendering a glyph for a
character, if available in the font(s) that the browser is using.
Firefox knows how to pick up a character from a font where it can find a
glyph for it, whereas IE uses just its default font or the list of fonts
suggested in HTML markup ( tag) or in CSS.

What Firefox does is not always a good thing. The reason why you might see,
for example, Firefox use a thin space that is equal to a normal space or
even wider is that it picks up a thin space from a font where it is that
wide. Although the thin space there is narrower than a normal space in that
font, it does not look good when the rest of the text is in another font.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Sep 5 '05 #25

Stan Brown <th************@fastmail.fm> wrote:

In Georgia (under Moz 1.7), is _wider_ than   !

It seems to me - based on a look at my page on spaces,
http://www.cs.tut.fi/~jkorpela/chars/spaces.html
on IE with font set to Georgia - that Georgia is really odd:
it seems to contain en space, em space, and thin space, but they are all of
the same width, which is considerably larger than the width of a space and
a no-break space.

Too bad - Georgia has nice features, and it's one of the few commonly
available fonts that has old-style lowercase digits. But apparently there's
no point in using it when you need thin spaces.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Sep 6 '05 #26

Jan Roland Eriksson

On Tue, 6 Sep 2005 21:39:42 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

Stan Brown <th************@fastmail.fm> wrote:
In Georgia (under Moz 1.7), is _wider_ than   !

Possible browser character replacement due to some older version of the
"Georgia" font that lacks the glyphs required?
It seems to me - based on a look at my page on spaces,
http://www.cs.tut.fi/~jkorpela/chars/spaces.html
on IE with font set to Georgia - that Georgia is really odd:
Not in my Firefox set to use Georgia (and displayed on a claibrated
VDU).
it seems to contain en space, em space, and thin space, but they
are all of the same width...

Nope; on my VDU your illustrations comes out correct and I have checked
several of those entries down to the pixel level.

There is a mathematical round-off error going one pixel up/down every
here and there but otherwise I do see the spaces as I think they should
be visualized.

Exception made for U+205F which comes out as a questionmark '?'

--
Rex

Sep 7 '05 #27

On Wed, 7 Sep 2005, Jan Roland Eriksson wrote:

On Tue, 6 Sep 2005 21:39:42 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Stan Brown <th************@fastmail.fm> wrote:
In Georgia (under Moz 1.7), is _wider_ than   !

Possible browser character replacement due to some older version of the
"Georgia" font that lacks the glyphs required?

I've just used SIL ViewGlyph to examine the Georgia font on this
Win/2000 Pro installation, and, if I'm not very much mistaken, there
are no characters listed between y-acute (U+1EF3) and en dash
(U+2013).

"Lucida Sans Unicode", on the other hand, shows a fair selection of
the various spaces starting at U+2000. With this tool I think I can
only tell you that they are there, I can't tell you much about them
(dimensions etc).
Nope; on my VDU your illustrations comes out correct and I have checked
several of those entries down to the pixel level.

As usual, it seems we have to conclude there are different versions
of the font floating around, with different character repertoires.

Sep 7 '05 #28

Jan Roland Eriksson wrote:

It seems to me - based on a look at my page on spaces,
http://www.cs.tut.fi/~jkorpela/chars/spaces.html
on IE with font set to Georgia - that Georgia is really odd:

Not in my Firefox set to use Georgia (and displayed on a claibrated
VDU).

Firefox and IE work differently with fonts. Normally IE does not pick up
substitute glyphs from the fonts it could use; if you tell it to use a
font, it uses that font, and shows missing glyphs as small rectangles.
Firefox picks up glyphs from different fonts as needed - and this is not
always useful.

What puzzles me here is that if I try to insert e.g. thin space in MS
Word, or change the font of text containing thin space in MS Word, there
does not seem to be such a character in Georgia. Yet my IE shows a wide
space there, _not_ a rectangle signalling a missing glyph. (Tested on
both under Win98 and under WinXP.)

it seems to contain en space, em space, and thin space, but they
are all of the same width...

Nope; on my VDU your illustrations comes out correct and I have checked
several of those entries down to the pixel level.

Then, apparently, you have a better Georgia font _or_ you are using a
browser that knows that your Georgia lacks those spaces and picks up the
spaces from another font. In the latter case, you were lucky: in
generaö, if you use substitute glyphs for fixed-width spaces, things can
go all wrong if their widths in the substitute font differ too much from
the widths of spaces in the normal font. The relative widths might be
OK, but when compared with spaces of another font...

Sep 7 '05 #29

Andreas Prilop

On Wed, 7 Sep 2005, Jukka K. Korpela wrote:

Firefox and IE work differently with fonts. Normally IE does not pick up
substitute glyphs from the fonts it could use; if you tell it to use a
font, it uses that font, and shows missing glyphs as small rectangles.
Firefox picks up glyphs from different fonts as needed - and this is not
always useful.
When and why not?
Then, apparently, you have a better Georgia font

Typefaces - like browsers or other programs - have version numbers.
http://www.microsoft.com/typography/...&FNAME=Georgia
Apparently it makes no sense to speak of "Netscape" without a version
number. Perhaps we should always add the version number to the name
of a typeface. For example, Georgia 1.0 did not contain Central
European Latin letters, nor Greek or Cyrillic.

Sep 7 '05 #30

On Wed, 7 Sep 2005, Andreas Prilop wrote:

Typefaces - like browsers or other programs - have version numbers.
Which, it seems, Windows helpfully does not display by default
when one queries the Properties of a font. :-(

Looks better after their Font Properties Extension has been downloaded
and installed. :-)

Btw, the place to find this information in SIL ViewGlyph is the
"Options> View Names" window. Which shows (modulo linewraps) this
sort of thing, including the Version:

0 1 (Macintosh) 0 (Roman) x0000 (0 English) Copyright "Typeface and data copyright 1996 Microsoft Corporation. All Rights Reserved."
1 1 (Macintosh) 0 (Roman) x0000 (0 English) Family "Georgia"
2 1 (Macintosh) 0 (Roman) x0000 (0 English) Subfamily "Regular"
3 1 (Macintosh) 0 (Roman) x0000 (0 English) Unique identifier "Microsoft Georgia Regular"
4 1 (Macintosh) 0 (Roman) x0000 (0 English) Full name "Georgia"
5 1 (Macintosh) 0 (Roman) x0000 (0 English) Version "Version 2.12"
6 1 (Macintosh) 0 (Roman) x0000 (0 English) Postscript name "Georgia"
7 1 (Macintosh) 0 (Roman) x0000 (0 English) Trademark "Georgia is a trademark of Microsoft Corporation."
8 3 (Windows) 1 (Unicode) x0403 (1027 Catalan) Subfamily "Normal"
9 3 (Windows) 1 (Unicode) x0405 (1029 Czech) Subfamily "obycejné"
10 3 (Windows) 1 (Unicode) x0406 (1030 Danish) Subfamily "normal"
11 3 (Windows) 1 (Unicode) x0407 (1031 German) Subfamily "Standard"
[...]
Perhaps we should always add the version number to the name
of a typeface. For example, Georgia 1.0 did not contain Central
European Latin letters, nor Greek or Cyrillic.

I'm just checking Georgia on the office peecee (the version which was
installed with XP Pro), and it claims to be Version 2.12.

According to your cited ref at MS, it seems the version in Win/2K
(what I was looking at earlier) would have been the same.

In XP, as I had seen it in 2K, Georgia (viewed in the main window of
SIL ViewGlyph, with the View set to "Windows Unicode" the only
plausible option) has y-acute and en-dash as adjacent characters:
no room for spaces in there!

And similarly if I view the Cmap table. It sure seemt that the spaces
aren't there.

These spaces are definitely there in Lucida Sans Unicode (when I say
that I can "see" them, this isn't strictly true with SIL ViewGlyph: I
can only see the empty display area where they must be if only they
could be seen :-} and the pop-up details as I mouse over them. )

Oh, alright, you want a "version" with that:

Unique identifier "Lucida Sans Unicode Regular; B&H; April 15, 1993;"
Full name "Lucida Sans Unicode"
Version "Version 2.00"
Postscript name "LucidaSansUnicode"
Trademark "Lucida is a registered trademark of Bigelow & Holmes Inc."

regards

Sep 7 '05 #31

Jan Roland Eriksson

On Wed, 07 Sep 2005 13:05:28 +0300, "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

Jan Roland Eriksson wrote:
It seems to me - based on a look at my page on spaces,
http://www.cs.tut.fi/~jkorpela/chars/spaces.html
on IE with font set to Georgia - that Georgia is really odd:
Not in my Firefox set to use Georgia (and displayed on a claibrated
VDU).

Firefox and IE work differently with fonts. Normally IE does not pick up
substitute glyphs from the fonts it could use; if you tell it to use a
font, it uses that font, and shows missing glyphs as small rectangles.
Firefox picks up glyphs from different fonts as needed - and this is not
always useful.

I don't know much about how the Firefox (gecko?) algorithms has been set
up but for sure if I had written the character spacing routines I would
not bother to pick up (invisible) glyphs from a font file for most
spaces.

Basically all spacing that is based on the 'em' unit can be easily
calculated and rendered directly from the current font height.

That would be for U+2000 -> U+2006, U+2009, U+205F.

Even U+2007 & U+2008 could be calculated from the current font.

Even the rest of the space characters could be easily rendered at some
reasonable width without resorting to find corresponding glyphs for them
in a font table.

[...]

on my VDU your illustrations comes out correct...

Then, apparently, you have a better Georgia font...
Last version available AFAIK, 2.12
..._or_ you are using a browser that knows that your Georgia
lacks those spaces...
Firefox v1.0.1
...and picks up the spaces from another font.
Or generates them mathematically from the current font in use?
Any gecko programmer around that can shed some light on this?
In the latter case, you were lucky: in
general, if you use substitute glyphs for fixed-width spaces, things can
go all wrong if their widths in the substitute font differ too much from
the widths of spaces in the normal font. The relative widths might be
OK, but when compared with spaces of another font...

Not really, at least not for the 'em' based spaces. They should have the
same width in all fonts at the same font size, otherwise there is
something very wrong with the design of the font that differs.

--
Rex

Sep 7 '05 #32

On Wed, 7 Sep 2005, Alan J. Flavell wrote:

I'm just checking Georgia on the office peecee (the version which was
installed with XP Pro), and it claims to be Version 2.12.

According to your cited ref at MS, it seems the version in Win/2K
(what I was looking at earlier) would have been the same.

Yeah, well - that just goes to show, doesn't it?

The version of Georgia on this Win/2K laptop is, in fact, reported to
be 2.05.

Be that as it may, SIL ViewGlyph's display is missing the U+200x
spaces in both versions of the font, as I said in earlier f'ups. I
don't know what Mozilla is showing, or what Rex is seeing, but on the
basis of what I'm being shown here, I don't see how it can be coming
out of the Georgia font.

ttfn

Sep 7 '05 #33

On Wed, 7 Sep 2005 15:14:45 +0100 in
comp.infosystems.www.authoring.html, Alan J. Flavell favored us
with...

Looks better after their Font Properties Extension has been downloaded
and installed. :-)

I'm just checking Georgia on the office peecee (the version which was
installed with XP Pro), and it claims to be Version 2.12.

Mine is 2.12 also -- created 1996, modified 2001 according to F.P.
Extension. (I'm the one who started this subthread with the remark
about the wide "thin space".)

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

Sep 8 '05 #34

On Wed, 7 Sep 2005 22:22:30 -0400 in
comp.infosystems.www.authoring.html, Stan Brown favored us with...

On Wed, 7 Sep 2005 15:14:45 +0100 in
comp.infosystems.www.authoring.html, Alan J. Flavell favored us
with...
Looks better after their Font Properties Extension has been downloaded
and installed. :-)

I'm just checking Georgia on the office peecee (the version which was
installed with XP Pro), and it claims to be Version 2.12.

Mine is 2.12 also -- created 1996, modified 2001 according to F.P.
Extension. (I'm the one who started this subthread with the remark
about the wide "thin space".)

Sorry -- I hit "send" too soon. The en space and such (hex 2000
series Unicode) are absent from my copy of Georgia, which confirms
someone's hypothesis that Mozilla happened to pick them up from some
font where they're wider than a in Georgia.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

Sep 8 '05 #35

Jan Roland Eriksson

On Wed, 7 Sep 2005 22:26:14 -0400, Stan Brown
<th************@fastmail.fm> wrote:

On Wed, 7 Sep 2005 22:22:30 -0400 in
comp.infosystems.www.authoring.html, Stan Brown favored us with...
[... about the Georgia font ...]

Mine is 2.12 also

Sorry -- I hit "send" too soon. The en space and such (hex 2000
series Unicode) are absent from my copy of Georgia, which confirms
someone's hypothesis that Mozilla happened to pick them up from some
font where they're wider than a in Georgia.

No, please wake up :-)
All spacing that is based on the 'em' unit does not really need a
specific glyph in a font table to be rendered correctly.

The math involved to come up with the proper width of white space is
trivial and if, otoh, a rendering engine resolves 'em' based whitespace
from font tables it does not matter which font table it is looking into.

One 12(something) font will allways have an em-space equal to
12(something) regardless of the name of the typeface.

--
Rex

Sep 8 '05 #36

Srikanth

Use <pre> </pre>tag and type down normally with white spaces.

eg.
<td><pre>Hi, How do you do. ? </pre></td>

Type as much white spaces you want in between the words...
I hope this will work...

:)

Sep 8 '05 #37

On Thu, 8 Sep 2005, Jan Roland Eriksson wrote:

On Wed, 7 Sep 2005 22:26:14 -0400, Stan Brown
<th************@fastmail.fm> wrote:
...absent from my copy of Georgia, which confirms
someone's hypothesis that Mozilla happened to pick them up from some
font where they're wider than a in Georgia.
No, please wake up :-)

Have a care!
All spacing that is based on the 'em' unit does not really need a
specific glyph in a font table to be rendered correctly.

I don't think anyone disagrees with that in theory - but -is- that how
the browser really works? There's enough evidence that MSIE is
picking up glyphs from the font (or at least trying to, when they are
missing). What is known about other browsers?

Sep 8 '05 #38