&ensp in a monospaced font

Toby A Inkster wrote:

In my stylesheets, I'm now specifying:

font-family: "Consolas", "Bitstream Vera Sans Mono", "Andale Mono",
"Monaco", "Lucida Console", monospace;

Why bother?

for monospaced fonts. Virtually all Mac OS 9/X machines will have Andale
Mono or Monoco.

If you just used font-family:monospace what do you suppose they'll see?
Even if their default is Courier [New], if they hated it don't you think
they would have changed it by now?

Ditto for every other OS/font combination you listed.

Each of those fonts are very readable, smart-looking

But beauty is in the eye of the beholder. I have both Bitstream Vera
Sans Mono and Lucida Console, but your order will force Vera Sans on me
while Lucida Console is my default.

Why don't you just let the user decide what's most readable in a
monospace font?

--
Berg

Bergamot wrote:

Toby A Inkster wrote:

Each of those fonts are very readable, smart-looking

But beauty is in the eye of the beholder. I have both Bitstream Vera
Sans Mono and Lucida Console, but your order will force Vera Sans on me
while Lucida Console is my default.

Why don't you just let the user decide what's most readable in a
monospace font?

By your logic, we shouldn't add any background or text colour either,
as the user can set that themselves too - what if your webpage is
black on white, while they would have preferred red on blue?

--
Els http://locusmeus.com/

Els wrote:

Bergamot wrote:

Why don't you just let the user decide what's most readable in a
monospace font?

By your logic, we shouldn't add any background or text colour either,

By your logic, we should set absolute font sizes to go with those fonts.

as the user can set that themselves too - what if your webpage is
black on white, while they would have preferred red on blue?

Now we're getting carried away.

Don't you get tired of every other web page insisting you use Arial or
Verdana or whatever? Why don't more authors just use the generic
families instead of over specifying everything?

We all make such a big deal about user controlled font sizes, but
default fonts are pretty much totally ignored.

--
Berg

Bergamot wrote:

Els wrote:
Bergamot wrote:

Why don't you just let the user decide what's most readable in a
monospace font?

By your logic, we shouldn't add any background or text colour either,

By your logic, we should set absolute font sizes to go with those fonts.

Nope, I'd set relative font-sizes that I think go with the rest of the
page and the purpose, and the user can still resize them, *and* force
their own user stylesheet over mine :-)

as the user can set that themselves too - what if your webpage is
black on white, while they would have preferred red on blue?

Now we're getting carried away.

Really :-)

Don't you get tired of every other web page insisting you use Arial or
Verdana or whatever? Why don't more authors just use the generic
families instead of over specifying everything?

No, I don't get tired of that at all.
Have a look at these pages. Each of them please:
http://www.jasonsantamaria.com/
http://mezzoblue.com/
http://molly.com/
http://mappingtheweb.com/

See how each has a different font?
If you have them on your system, you should have seen Georgia, Lucida
Grande, Verdana and Trebuchet MS.

I'd get tired of seeing my own preferred font on every webpage while I
could be looking at diversity in typography.

And I don't get your "insisting we use Arial or Verdana or whatever".
They don't insist, they suggest. If you really want to have your
internet pages all in Verdana, just write your own stylesheet.

We all make such a big deal about user controlled font sizes, but
default fonts are pretty much totally ignored.

Which is a good thing :-)

--
Els http://locusmeus.com/

Els wrote:

Bergamot wrote:

Don't you get tired of every other web page insisting you use Arial

No, I don't get tired of that at all.
Have a look at these pages. Each of them please:

Seems we don't hang out at the same types of web sites. No matter. For
every 1 site you name that *doesn't* use Arial as a first-choice font,
there are thousands that do.

I uninstalled Verdana, Comic Sans and a few other fonts long ago so I
wouldn't have to look at them. I don't like Arial, but can't get rid of
that one. Wish I could.

If you really want to have your
internet pages all in Verdana, just write your own stylesheet.

I don't necessarily want the same font on every page either. Sometimes a
serif goes better with a design, sometimes sans. The 2 together can be
quite nice, too, when used properly.

default fonts are pretty much totally ignored.

Which is a good thing :-)

Matter of opinion.

--
Berg

ok maybe I didn't make myself clear

i am using a monospaced font. on one line of the output i have
'abcde'; on the next line I have 'a' followed by 3 spaces followed by
'e'

I want the 'e' in the second line to appear underneath the 'e' in the
first line

if I use a normal space, the 3 spaces are collapsed into one; if I use
an m-width or n-width space, the spaces aren't the same width as
letters; if I use a non-breaking space, this stops the line breaking
(which is not the behaviour I want)

however, you (ant other posters) are right - I didn't realise you can
put other html codes inside a <pre> block - so that looks like the
best option to me

Andy


On 29 Feb, 17:36, "Jukka K. Korpela" <jkorp... (AT) cs (DOT) tut.fi> wrote:

Scripsit Andy Fish:

I am trying to output some html in monospaced font,

Do you mean you wish to present HTML markup visibly or audibly on the
page? Then a monospace font would normally be a good idea. I would
suggest using <code> markup together with a style sheet like
code { font-family: Consolas, "Courier New"; }
to reduce the risk that some poor default monospace font is used.

and I want spaces
to take up the same width as any other character.

A normal space, as well as a no-break space, has the same width as other
characters, when the font is monospace

i thought this
would be easy for monospaced fonts - surely &ensp; and &emsp; would
both be the same width?

What? Why would you use specific-width space characters (which are
poorly supported in fonts) _and_ ask them to have the same width as
other characters? Why would you use them at all?

so how do i generate a sequence of normal width spaces?

By using the SPACE character U+0020 as everyone else.

I can't use the <pre> tag because there is HTML markup in the output
- it's not only plain text

You have misunderstood the meaning of <pre>, and what else?

The real problem is probably very different from the picture we've got
so far. To avoid wasting more of everyone's time, post the URL.

--
Jukka K. Korpela ("Yucca")http://www.cs.tut.fi/~jkorpela/

ajfish (AT) blueyonder (DOT) co.uk wrote:

[using a different name but presumably as OP Andy Fish]

ok maybe I didn't make myself clear

No. But it's worse than that; you top-posted as a reply to Mr. Korpela.
:-O This shows a level of daring (some may assume rudeness) that might
draw a few high-temperature flames. Better to avoid top-posting.

Maybe you're all flustered because you're using GG in the office, when
you're supposed to be working? ;-)

i am using a monospaced font. on one line of the output i have
'abcde'; on the next line I have 'a' followed by 3 spaces followed by
'e'

I want the 'e' in the second line to appear underneath the 'e' in the
first line

Much clearer.

if I use a normal space, the 3 spaces are collapsed into one; if I use
an m-width or n-width space, the spaces aren't the same width as
letters; if I use a non-breaking space, this stops the line breaking
(which is not the behaviour I want)

Even clearer. Then how about: <p>abcde</p><p>a&nbsp; &nbsp;e</p> ?

That should give you both the spacing and a possible break. I believe
you'd get the same effect (but with two break possibilities) if you did:
<p>abcde</p><p>a &nbsp; e</p> . (Not tested in all browsers.)

It's only consecutive spaces that get collapsed.

Programmatically (or algorithmically), you'd add a regular space for the
first space between chars, then a &nbsp; for the second one, then a
space, then a &nbsp; etc. until you'd replaced all the missing positions
with spaces of either kind.

Andy

(Sign-off left deliberately, normally I'd snip it.)

The stuff below is what you should have either trimmed completely or
selectively commented on in-line.

On 29 Feb, 17:36, "Jukka K. Korpela" wrote:
Scripsit Andy Fish:

[actual exchange snipped]
--
Jukka K. Korpela ("Yucca")http://www.cs.tut.fi/~jkorpela/

HTH

--
John

Scripsit John Hosking:

ajfish (AT) blueyonder (DOT) co.uk wrote:
- -
i am using a monospaced font. on one line of the output i have
'abcde'; on the next line I have 'a' followed by 3 spaces followed by
'e'

I want the 'e' in the second line to appear underneath the 'e' in the
first line

Much clearer.

It's still not evident what the problem is. As usual, a URL would
have...

if I use a normal space, the 3 spaces are collapsed into one; if I
use an m-width or n-width space, the spaces aren't the same width as
letters; if I use a non-breaking space, this stops the line breaking
(which is not the behaviour I want)

Even clearer.

Not to me, really. A few clarifications:

1) There is no "m-width" and "n-width" space. The width of an EM SPACE
equals the font size, by definition, and the width of an EN SPACE is
half of that. Their relationship to the widths of the letters "m" and
"n" is unspecified.

2) Normal spaces do collapse. This can be prevented in different ways,
but not in any evident way in inline text. (white-space: pre-wrap in CSS
would do this, but regarding browser support, "D'Oh!")

3) Whether em spaces, en spaces, or no-break spaces collapse is
explicitly declared unspecified in HTML specifications. In practice they
don't, but if IE 8 or Firefox 4 starts collapsing them, you can only
blame yourself if you relied on their not being collapsed.

4) The no-break space should prevent line breaks before and after. There
are some flaws in this area in browsers when a no-break space is
preceded or followed by a normal space.

But why would it be a _problem_ that line breaks are prevented, if you
want a specific placement of characters? To me, it seems like a
necessary part of a _solution_.

Then how about: <p>abcde</p><p>a&nbsp; &nbsp;e</p> ?

Since this was said to be computer output, markup like

<pre><samp>abcde
a e</samp></pre>

would appear to be adequate. If this won't do, the OP should explain why
not.

That should give you both the spacing and a possible break. I believe
you'd get the same effect (but with two break possibilities) if you
did: <p>abcde</p><p>a &nbsp; e</p> . (Not tested in all browsers.)

By the specifications, "a &nbsp; e" should have one break possibility
only, after the second space. Some browsers get this wrong. But I don't
see a reason for using such an approach.

It's only consecutive spaces that get collapsed.

As I mentioned above, no-break spaces may or may participate in the
collapse party. Currently they don't, but you have been warned:

"This specification does not indicate the behavior, rendering or
otherwise, of space characters other than those explicitly identified
here as white space characters [i.e. space, tab, form feed, zero-width
space]. For this reason, authors should use appropriate elements and
styles to achieve visual formatting effects that involve white space,
rather than space characters."
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Just out of interest, what is the logic behind collapsing spaces in text?
I'd love to be able to display a document I'd written with the conventional
2 spaces after a full stop.

+mrcakey

Jukka K. Korpela wrote:

3) Whether em spaces, en spaces, or no-break spaces collapse is
explicitly declared unspecified in HTML specifications. In practice they
don't, but if IE 8 or Firefox 4 starts collapsing them, you can only
blame yourself if you relied on their not being collapsed.

Except for the few white space characters for which collapsing is
specifically required, whether *any* character collapses is unspecified.
Yet I'm not going to worry that some day a new browser version will
display "bookkeeper" as "bokeper". I think it's taken for granted that
characters not arbitrarily collapsing with each other is the norm, and
only situations where they do collapse need to be articulated explicitly.