Line spacing not working

On 2009-11-03, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnhet5hi.31q.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]
But if JK ever develops a browser, he can make the line-height a bit
bigger if he likes-- it wouldn't be wrong.


I was looking to nail this business of what he actually does to
implement his idea that browsers use too small an interpretation for
normal; in some of his web pages. It is a bit unclear exactly how he
implements the policy of overriding what browsers do. How can you know
in advance what font is being used. Whenever I mention the simple tactic
of element {line-height: 1.3} I get the feeling this runs up against the
problem that for some fonts this is fine but maybe for some others it is
too big!

If he were to develop a browser, he could look up the "normal" value in
the font and multiply it by 1.1, and/or have his own table of fonts to
default line heights built in. None of this would violate the CSS spec.

I think what he actually does is sets font-family and line-height
together, but this suffers from the problem you point out: you don't
know what fonts people have actually have, but they will still get the
line-heights you actually set.

[...]

If you can be confident folk have say Arial and you simply pick a line
height for it that is good (that is better than what *most* browsers
use), all well and good? But we regularly suggest a 'cascade' of fonts
in font-family rules and even end up with generic like ', sans-serif;'.
Is the idea that you say at this point something about line-height?

There is no "If Arial, then line-height: 1.3, but if Geneva, 1.25"

That is exactly the problem. I don't have Arial on any of my computers.

[...]

You will sleep like a baby after this. <g

Yes. Although when I tried suggesting exactly this to JK, he didn't
sleep like a baby, but had a quite different reaction.

Yes, so I noticed. <g

His reaction might still have been compared to that of a baby, just not
a sleeping one.

In article <slrnhf0olr.9fi.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-11-03, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <slrnhet5hi.31q.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]
But if JK ever develops a browser, he can make the line-height a bit
bigger if he likes-- it wouldn't be wrong.


I was looking to nail this business of what he actually does to
implement his idea that browsers use too small an interpretation for
normal; in some of his web pages. It is a bit unclear exactly how he
implements the policy of overriding what browsers do. How can you know
in advance what font is being used. Whenever I mention the simple tactic
of element {line-height: 1.3} I get the feeling this runs up against the
problem that for some fonts this is fine but maybe for some others it is
too big!

If he were to develop a browser, he could look up the "normal" value in
the font and multiply it by 1.1, and/or have his own table of fonts to
default line heights built in. None of this would violate the CSS spec.

Both these are interesting ideas for browser makers. As I am now seeing
it, I am imagining - because it is less time consuming than researching
- a history to all this.

Font makers perhaps have not caught up with the fact that their fonts
are used extensively these days on screens (even widescreens). The
tradition, maybe the craft of it, may still be in the print mentality
where paper is rarely bigger than A4, books quite less, newspaper
columns even lesser. Line height becomes quite an important way to help
readers of longer lines, less important when lines are short.

But maybe it would be too complicated for browser makers to provide for
anything but paper? As you are saying, the browser makers can do this.
Since CSS cannot be up to the task of covering for all users fonts, even
in a screen sheet, the browser makers should do either of the things you
suggest (I like both of them. But I imagine the table idea would be more
intelligent because perhaps many fonts have satisfactory 'inbuilt'
recommended line heights, the table would catch the screen miscreants).

The only other thing that might be done is in some future CSS, along the
lines of the conditionals I mentioned - effectively incorporating a
table of line heights for the likely screen miscreants.

Perhaps, in the meantime, for perfectionists, a scripting solution might
be possible? I better not develop this one in the same thread that I
introduced the semi-crazy Virtual Master CSS Sheet, one must always try
to stop just short of being shot! <g>

--
dorayme

On 2009-11-03, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnhf0olr.9fi.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-11-03, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <slrnhet5hi.31q.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]
But if JK ever develops a browser, he can make the line-height a bit
bigger if he likes-- it wouldn't be wrong.


I was looking to nail this business of what he actually does to
implement his idea that browsers use too small an interpretation for
normal; in some of his web pages. It is a bit unclear exactly how he
implements the policy of overriding what browsers do. How can you know
in advance what font is being used. Whenever I mention the simple tactic
of element {line-height: 1.3} I get the feeling this runs up against the
problem that for some fonts this is fine but maybe for some others it is
too big!

If he were to develop a browser, he could look up the "normal" value in
the font and multiply it by 1.1, and/or have his own table of fonts to
default line heights built in. None of this would violate the CSS spec.


Both these are interesting ideas for browser makers. As I am now seeing
it, I am imagining - because it is less time consuming than researching
- a history to all this.

Generally though most browser makers will just try to do what everyone
else is doing for anything that isn't exactly specified in the specs,
because you just know that some idiot out there has relied on these
things.

A few times I've seen lists of items with little icons and things but
where all that is in _one_ background image. Then the LIs are superposed
top, with font-size, but neither height nor line-height set. In other
words, the page designer assumes that everyone's line-height: normal for
the chosen font is exactly the same number of pixels.

If you don't have the font, tough, but if you do, it helps if your
browser does the same thing as everyone else's with line-height: normal.

You might be correct to do it differently, but nobody sees that. They
just think what's wrong with this browser, why doesn't it render this
page right, and switch back to IE (oh the irony).

Font makers perhaps have not caught up with the fact that their fonts
are used extensively these days on screens (even widescreens). The
tradition, maybe the craft of it, may still be in the print mentality
where paper is rarely bigger than A4, books quite less, newspaper
columns even lesser. Line height becomes quite an important way to help
readers of longer lines, less important when lines are short.

This is true, although most paper books I've seen recently have fairly
generous line heights.

But maybe it would be too complicated for browser makers to provide for
anything but paper? As you are saying, the browser makers can do this.
Since CSS cannot be up to the task of covering for all users fonts, even
in a screen sheet, the browser makers should do either of the things you
suggest (I like both of them. But I imagine the table idea would be more
intelligent because perhaps many fonts have satisfactory 'inbuilt'
recommended line heights, the table would catch the screen miscreants).

The only other thing that might be done is in some future CSS, along the
lines of the conditionals I mentioned - effectively incorporating a
table of line heights for the likely screen miscreants.

What would be quite useful would be to able to set multiples of
line-height: normal, rather than multiples of font-size.

Then line-height: normal * 1.1 (or so) would do the trick. So this would
be the font-size, plus the font's built-in recommended line-gap, all
multiplied by 1.1.

Something like that may be on the cards for CSS3 (you name it, it's
probably in CSS3). CSS 2.1 tends to shy away from fonts a bit, probably
wisely assuming that the browser in many cases just gets what it gets
from the OS.

Perhaps, in the meantime, for perfectionists, a scripting solution might
be possible?

I guess so, although any perfectionist who's doing web design is in the
wrong job.

On 2009-11-03, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnhf0olr.9fi.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-11-03, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <slrnhet5hi.31q.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]
But if JK ever develops a browser, he can make the line-height a bit
bigger if he likes-- it wouldn't be wrong.


I was looking to nail this business of what he actually does to
implement his idea that browsers use too small an interpretation for
normal; in some of his web pages. It is a bit unclear exactly how he
implements the policy of overriding what browsers do. How can you know
in advance what font is being used. Whenever I mention the simple tactic
of element {line-height: 1.3} I get the feeling this runs up against the
problem that for some fonts this is fine but maybe for some others it is
too big!
[...]

Perhaps, in the meantime, for perfectionists, a scripting solution might
be possible? I better not develop this one in the same thread that I
introduced the semi-crazy Virtual Master CSS Sheet, one must always try
to stop just short of being shot! <g

Another solution would for someone like Korpela to hack his own fonts on
his machine, using a font editor like fontforge. If he increases the
line-gap stored in the fonts, then most probably, anything with
line-height: normal on the web will get a bigger line-height in his
browsers.

Depending on how the fonts are licensed, he can release his own font
package of modified fonts for like-minded users.

dorayme wrote:

Ben C <spamspam (AT) spam (DOT) eggs> wrote:

[...]

If he were to develop a browser, he could look up the "normal" value
in the font and multiply it by 1.1, and/or have his own table of
fonts to default line heights built in. None of this would violate
the CSS spec.


[...]

Font makers perhaps have not caught up with the fact that their fonts
are used extensively these days on screens (even widescreens). The
tradition, maybe the craft of it, may still be in the print mentality
where paper is rarely bigger than A4, books quite less, newspaper
columns even lesser. Line height becomes quite an important way to
help readers of longer lines, less important when lines are short.

The underlying issue is quite a bit more complex than this. Fonts have

metrics that can be read by an application (browsers, word processors,
layout apps, etc.), and handled accordingly regardless of the medium (paper,
screen, etc.). Given that, the metrics of fonts are such that it would be
frustrating to establish a singluar line height that would be appropriate
for any two or more fonts. However, adding to the complexity is the reality
that rendering fonts to the screen is the task of the video card or
subsystem, and therein lies a lot of variability. With everything else being
held constant, a change in the video system can render fonts differently.

But maybe it would be too complicated for browser makers to provide
for anything but paper?

Browsers are completely independent of how something will print on paper

(which introduces another level of complexity at least matching the above).
Browsers render pages to the video system, period. So, as I see it, the task
for web designers is to be less concerned about the finess of fonts used for
web pages and more concerned about the legibility of the page, since there
is no way to predict how a particular font or its substitutes will be
rendered on any users' screen.

--
Best,

Neil

In article <hcs7vc$2qfu$1 (AT) adenine (DOT) netfront.net>,
"Neil Gould" <neil (AT) myplaceofwork (DOT) com> wrote:

dorayme wrote:
....

But maybe it would be too complicated for browser makers to provide
for anything but paper?

Browsers are completely independent of how something will print on paper..

My words in that sentence included a typo, sorry. I meant font makers,
not browser makers. When they design fonts, I assume the deepest
tradition is in looking at writing on paper. But I know there is
increasing attention to designing for computer monitors. Ideally, the
font-makers would examine the matter of how best to set a base (normal)
for line-height and the browsers would simply read this. But there could
be third parties do this work and make a few modifications. At least, it
seems quite difficult to get an ideal strategy *for the author* because
of the difficulties of not knowing what font will actually be used at
the other end.

--
dorayme

dorayme wrote:

In article <hcs7vc$2qfu$1 (AT) adenine (DOT) netfront.net>,
"Neil Gould" <neil (AT) myplaceofwork (DOT) com> wrote:

dorayme wrote:
...

But maybe it would be too complicated for browser makers to provide
for anything but paper?

Browsers are completely independent of how something will print on
paper..

My words in that sentence included a typo, sorry. I meant font makers,
not browser makers. When they design fonts, I assume the deepest
tradition is in looking at writing on paper. But I know there is
increasing attention to designing for computer monitors. Ideally, the
font-makers would examine the matter of how best to set a base
(normal) for line-height and the browsers would simply read this. But
there could be third parties do this work and make a few
modifications. At least, it seems quite difficult to get an ideal
strategy *for the author* because of the difficulties of not knowing
what font will actually be used at the other end.

Actually, the earliest electronic fonts were created for the screen, as they

were low resolution bitmapped versions of "the real things". Fonts commonly
shipped and with an OS and thus widely used in web designs, such as Arial,
Apple Chancery, Tahoma, et al were developed for that purpose, as true
typographic quality fonts were (and still are) quite expensive in
comparison. Most folks involved in serious typography would never use these
fonts in a document intended for print.

There are typographic formulae for setting "normal" line heights for fonts,
but they are pretty much unique to the font. The reason why it would be
impractical to derive a "generic" line height for different typefaces is
that the ascenders and descenders differ, sometimes dramatically.

One needs to consider many things in choosing such things as leading (the
space between lines in typographic terms) and kerning (the space between
letters), but the problem is that the web designer can have no idea which
fonts or what versions of fonts are installed on viewers' systems, what
video subsystem is used, what monitor is used, etc. It's not the fault of
browsers, that these aspects elude precise control.

--
Best,

Neil

In article <hct0er$193r$1 (AT) adenine (DOT) netfront.net>,
"Neil Gould" <neil (AT) myplaceofwork (DOT) com> wrote:

dorayme wrote:
In article <hcs7vc$2qfu$1 (AT) adenine (DOT) netfront.net>,
"Neil Gould" <neil (AT) myplaceofwork (DOT) com> wrote:

dorayme wrote:
...
...browser makers. When they design fonts, I assume the deepest
tradition is in looking at writing on paper. But I know there is
increasing attention to designing for computer monitors. Ideally, the
font-makers would examine the matter of how best to set a base
(normal) for line-height and the browsers would simply read this. But
there could be third parties do this work and make a few
modifications. At least, it seems quite difficult to get an ideal
strategy *for the author* because of the difficulties of not knowing
what font will actually be used at the other end.

Actually, the earliest electronic fonts were created for the screen, as they
were low resolution bitmapped versions of "the real things".

I remember having *screen fonts* on my old Mac SE on OS6! They would be
part of the packages that came with the OS and it was best to use the
foonts that had screen font components or they would look awful on the
9" (I think square pixeled) screen.

....

There are typographic formulae for setting "normal" line heights for fonts,
but they are pretty much unique to the font.

As has been established (or intelligently guessed at) in the thread, yes.

One needs to consider many things in choosing such things as leading (the
space between lines in typographic terms) and kerning (the space between
letters), but the problem is that the web designer can have no idea which
fonts or what versions of fonts are installed on viewers' systems, what
video subsystem is used, what monitor is used, etc. It's not the fault of
browsers, that these aspects elude precise control.

Indeed. We have been discussing in the thread possible ways to
ameliorate this, not sure you have read all of the fat being chewed in
the thread? <g>

--
dorayme

dorayme wrote:

In article <hct0er$193r$1 (AT) adenine (DOT) netfront.net>,
"Neil Gould" <neil (AT) myplaceofwork (DOT) com> wrote:

dorayme wrote:
In article <hcs7vc$2qfu$1 (AT) adenine (DOT) netfront.net>,
"Neil Gould" <neil (AT) myplaceofwork (DOT) com> wrote:

dorayme wrote:
...
...browser makers. When they design fonts, I assume the deepest
tradition is in looking at writing on paper. But I know there is
increasing attention to designing for computer monitors. Ideally,
the font-makers would examine the matter of how best to set a base
(normal) for line-height and the browsers would simply read this.
But there could be third parties do this work and make a few
modifications. At least, it seems quite difficult to get an ideal
strategy *for the author* because of the difficulties of not knowing
what font will actually be used at the other end.

Actually, the earliest electronic fonts were created for the screen,
as they were low resolution bitmapped versions of "the real things".

I remember having *screen fonts* on my old Mac SE on OS6! They would
be part of the packages that came with the OS and it was best to use
the foonts that had screen font components or they would look awful
on the 9" (I think square pixeled) screen.

Yes... screen fonts were the typical solution of that era on all platforms.

Now, the screen fonts rendered from the vector font data by the video
subsystem, and there is a lot of variance as to how that looks from one
computer to the next. I can't see any solution to this on the part of
browsers as they're too far "upstream".

One needs to consider many things in choosing such things as leading
(the space between lines in typographic terms) and kerning (the
space between letters), but the problem is that the web designer can
have no idea which fonts or what versions of fonts are installed on
viewers' systems, what video subsystem is used, what monitor is
used, etc. It's not the fault of browsers, that these aspects elude
precise control.

Indeed. We have been discussing in the thread possible ways to
ameliorate this, not sure you have read all of the fat being chewed in
the thread? <g

Yes, I read the posts on this topic. I chimed in because I don't think that

there will be a solution in the way browsers are written. It's just another
parameter that web designers need to take into consideration when creating
pages.

--
Best,

Neil

On Wed, 4 Nov 2009, Neil Gould wrote:

Browsers are completely independent of how something will print on paper
Browsers render pages to the video system, period.

View and print
http://www.user.uni-hannover.de/nhtcapri/temp-1.html
with both Ιnternet Εxplorer and Firefox (МЅ Windows).

--
In memoriam Alan J. Flavell
http://groups.google.co.uk/groups/search?q=author:Alan.J.Flavell