Keeping Web Page at Fixed Width

[SoloCDM]

How do I keep my entire web page at a fixed width?

************************************************** *******************
Signed,
SoloCDM

[Stan Brown]

In article <bk************@ID-114100.news.uni-berlin.de> in
comp.infosystems.www.authoring.html, Harlan Messinger
<h.*********@comcast.net> wrote:

Whatever I do, it's going to look ugly for somebody. Best to design, then,
for the greatest common denominator.

"None so blind as those who _will_ not see."

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[kchayka]

Harlan Messinger wrote:

"kchayka" <kc*********@sihope.com> wrote in message
news:3f********@news.sihope.com...

Please post an example that supports your
claims, preferably, a site that you've developed. If we see how a fixed
design makes it somehow better, you might even convince some of us that
it's true.
I don't need to give you a site that *I've* designed.

You've made such a big deal out of fixed-width being vital to (your)
800x600 designs, so I figured you already had the perfect test cases.
Perhaps not?
Take any three-column
layout where the left-hand column contains navigation links, the right-hand
column contains short bits of auxiliary information, and the main content is
in the center. Do I want to leave it up to the user's agent to decide which
of the three columns gets expanded or contracted at the expense of the
others?
Did anyone ever say you shouldn't suggest column widths? There is
absolutely nothing wrong with that. So set them in % units instead of
px units and they will scale with the window width. Piece of cake.
Do I want the nav column to wind up 6 inches wide while the content
column is reduced to half an inch?
Nobody will even consider taking you seriously if you don't quit making
silly statements like this.
What if I used fixed-width graphics in
the right-hand column? If that column gets much wider, it'll have ridiculous
looking gaps in it.
And what is the purpose of these fixed-width graphics? Navigation
buttons? Graphics used as text is a lousy way to make a web page. If
the graphics are for some other purpose, then I'd have to see them
before making any further assessment. The graphics may not be needed at
all, or might be done differently to better fit in a fluid layout.
http://www.4guysfromrolla.com/
I don't claim this is an attractive page design, but it illustrates what I
mean about three-column layout.
I think you chose a poor example. If you don't count the awful layout
tables, the layout has one real problem - failing to wrap the links in
the page footer can cause unnecessary horizontal scrolling. Other than
that, it does not prove your case at all, AFAICT. All 3 columns
expand/contract with window size, the center column remains the widest
in any case. This is as it should be. I fail to see the problem.
http://nces.ed.gov/nationsreportcard/
Here's a reasonably attractive page design. Not much leeway for
variable-width columns, though. I wouldn't trust a browser in a million
years to make the right decisions.

You chose another poor example. This would most definitely benefit from
a fluid layout. The text size is unreadably small, making it big enough
for me to read squishes the text up so there are only a couple of words
per line. Hardly an optimal browsing experience, methinks. Some of the
inner pages are tolerable as is, many are not.

You are a long way from convincing anyone, I'm afraid.

--
To email a reply, remove (dash)ns(dash). Mail sent to the ns
address is automatically deleted and will not be read.

[Tina Holmboe]

"Harlan Messinger" <h.*********@comcast.net> exclaimed in <bk************@id-114100.news.uni-berlin.de>:

I think you could benefit from studying some of that "decades of study
and research" yourself. In particular, study how traditional design, be
it print or otherwise, work *with* the medium.
But what is visually appealing doesn't suddenly disappear with each new
medium, requiring everyone to start from scratch.

* "Visually appealing" is, for the most part, a matter of highly
subjective taste.

* What is visually appealing when carved in stone is not necessarily
visually appealing when reproduced as a web design.

But feel free to disagree.

can or should be transferred unmodified to the web. I realize full well that
the Wall Street Journal's six-column design, with one web page corresponding
to one printed page and the jumps working the same way, wouldn't work. Also,

But you *don't* realize that fixed widths don't work either.

Not against it. Try looking
at the theories of why Futhark and Ogham are angular scripts.

I have trouble believing that Futhark and Ogham were the result of decades
of--or any--study!

Since my examples referred to a different part of what I wrote than what
you think they do, I'd say we are in agreement. However, both Futhark
and Ogham *are* the result of quite a few years of seeing what did and
what didn't work.

And what WORKS is accepting the nature of the medium you design for, or
find another job. TANSTAAFL applies here as everywhere: if you want to
work with the web, you are stuck with what it is, and what it is not.

Or, rather, you might feel stuck. I don't.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

[Harlan Messinger]

"kchayka" <kc*********@sihope.com> wrote in message
news:3f********@news.sihope.com...

Harlan Messinger wrote:

"kchayka" <kc*********@sihope.com> wrote in message
news:3f********@news.sihope.com...

Please post an example that supports your
claims, preferably, a site that you've developed. If we see how a fixed design makes it somehow better, you might even convince some of us that
it's true.
I don't need to give you a site that *I've* designed.

You've made such a big deal out of fixed-width being vital to (your)
800x600 designs, so I figured you already had the perfect test cases.
Perhaps not?

Take any three-column
layout where the left-hand column contains navigation links, the right-hand column contains short bits of auxiliary information, and the main content is in the center. Do I want to leave it up to the user's agent to decide which of the three columns gets expanded or contracted at the expense of the
others?

Did anyone ever say you shouldn't suggest column widths?

Isn't the sum of *n* fixed-width columns a fixed-width table?
There is
absolutely nothing wrong with that. So set them in % units instead of
px units and they will scale with the window width. Piece of cake.
Using percentages can still be no good. If the user is working with a
25-inch screen and chooses to maximize his browser at 1500 pixels width
while not bothering to do a thing about the typeface, then the same
ridiculous-looking result ensues.

Do I want the nav column to wind up 6 inches wide while the content
column is reduced to half an inch?
Nobody will even consider taking you seriously if you don't quit making
silly statements like this.

I won't take you seriously if you dismiss as "silly" examples I have
encountered in my experience.

What if I used fixed-width graphics in
the right-hand column? If that column gets much wider, it'll have ridiculous looking gaps in it.
And what is the purpose of these fixed-width graphics? Navigation
buttons? Graphics used as text is a lousy way to make a web page.

Why? As long as appropriate ALT text is used, of course. Anyway, you can
assume that I'm also talking about graphics for visual effect.
If
the graphics are for some other purpose, then I'd have to see them
before making any further assessment. The graphics may not be needed at
all, or might be done differently to better fit in a fluid layout.

http://www.4guysfromrolla.com/
I don't claim this is an attractive page design, but it illustrates what I mean about three-column layout.
I think you chose a poor example. If you don't count the awful layout
tables, the layout has one real problem - failing to wrap the links in
the page footer can cause unnecessary horizontal scrolling. Other than
that, it does not prove your case at all, AFAICT. All 3 columns
expand/contract with window size,

They do? What browser are you using? Wait--I had only tested shrinking the
window before--and below 800 pixels, the columns do *not* resize. I see now
that if I *expand* the browser above 800 pixels, they columns expand--with
the result being an unnecessary waste of horizontal white space in the
outside columns.
the center column remains the widest
in any case. This is as it should be. I fail to see the problem.
As I said, try shrinking your browser below 800 pixels.

http://nces.ed.gov/nationsreportcard/
Here's a reasonably attractive page design. Not much leeway for
variable-width columns, though. I wouldn't trust a browser in a million
years to make the right decisions.

You chose another poor example. This would most definitely benefit from
a fluid layout. The text size is unreadably small, making it big enough
for me to read squishes the text up so there are only a couple of words
per line. Hardly an optimal browsing experience, methinks. Some of the
inner pages are tolerable as is, many are not.

You are a long way from convincing anyone, I'm afraid.

--
To email a reply, remove (dash)ns(dash). Mail sent to the ns
address is automatically deleted and will not be read.

[Harlan Messinger]

"Stan Brown" <th************@fastmail.fm> wrote in message
news:MP************************@news.odyssey.net.. .

In article <bk************@ID-114100.news.uni-berlin.de> in
comp.infosystems.www.authoring.html, Harlan Messinger
<h.*********@comcast.net> wrote:

Whatever I do, it's going to look ugly for somebody. Best to design, then,for the greatest common denominator.

"None so blind as those who _will_ not see."

What do you expect, "Glory, I have seen the light"? I'm talking with a group
of die-hard proselytizers who have a lot of good information, but who expect
me to jettison things I know *from my own experience* out of sheer awe of
their enlightenment.

I should mention that I am not a technological obstructionist. I was the
first one in my office to see that word processing meant it had become more
efficient for me to just type my documents myself rather than writing them
by hand for a secretary to type (and I got *scolded* for that). I was the
first one to use proportional typefaces, to drop double spaces after
periods, and learn good layout techniques and read books on typography. I
was the second one my office to use Windows and the first to learn to
program for it. I tried unsuccessfully to drag my development team from C
and--ack--our own proprietary language to C++. I try to persuade clients to
support as few older browser versions as possible. And, to the extent that I
can within the confines of an assignment, I *do* try to separate web content
from layout, and I wish that Netscape 4.x would go away so I could start
using DIVs for layout. I love technology. But in each case, my push for
change was due deliberation. "You *can* do it this way, so you *should* do
it this way" is not a convincing argument for me, nor are some of the other
arguments I've seen here.

[Beauregard T. Shagnasty]

Harlan Messinger pounced upon this pigeonhole and pronounced:

"kchayka" <kc*********@sihope.com> wrote in message
news:3f********@news.sihope.com...

There is
absolutely nothing wrong with that. So set them in % units instead of
px units and they will scale with the window width. Piece of cake.

Using percentages can still be no good. If the user is working with a
25-inch screen and chooses to maximize his browser at 1500 pixels width
while not bothering to do a thing about the typeface, then the same
ridiculous-looking result ensues.

Using percentages and a 25 inch screen with a 1500px browser may be just
*perfect* for a conference room...

And you didn't have to do anything extra to make it so.

--
-bts
-This space intentionally left blank.

[kchayka]

Harlan Messinger wrote:

"kchayka" <kc*********@sihope.com> wrote in message
news:3f********@news.sihope.com...

Harlan Messinger wrote:

> "kchayka" <kc*********@sihope.com> wrote in message
> news:3f********@news.sihope.com...
Did anyone ever say you shouldn't suggest column widths?

Isn't the sum of *n* fixed-width columns a fixed-width table?

Yes, and the sum of *n* variable-width (table) columns is a
variable-width table. What point are you trying to make now?
Using percentages can still be no good. If the user is working with a
25-inch screen and chooses to maximize his browser at 1500 pixels width
while not bothering to do a thing about the typeface, then the same
ridiculous-looking result ensues.
Um, if the user deems this size is optimal for reading, then who are you
to say it's wrong?
I won't take you seriously if you dismiss as "silly" examples I have
encountered in my experience.
Bad design is not limited to fixed-width layouts, you know. ;) I doubt
anyone would intentionally scale columns for a 6-inch wide nav bar and
half-inch wide content area. That's a stoopid newbie kind of error.

Graphics used as text is a lousy way to make a web page.

Why? As long as appropriate ALT text is used, of course.

Assuming you are using alt text correctly (and that may be a rather bold
assumption), it doesn't help me read the text unless I disable images,
then all your visual effect goes down the toilet anyway.

BTW, if I have to go to the trouble of disabling images to use a site,
you can bet I won't bother and will go looking elsewhere instead. It's
probably a safe bet that most other users that normally browse with
images enabled would do likewise.
Anyway, you can
assume that I'm also talking about graphics for visual effect.

There weren't any "visual effect" graphics in the 2 URLs you posted.
Logos aside, I didn't see any graphics there at all that were remotely
indispensible, or couldn't be massaged to work better in more fluid layouts.

> http://www.4guysfromrolla.com/
> I don't claim this is an attractive page design, but it illustrates what
> I mean about three-column layout.

I think you chose a poor example.
the center column remains the widest
in any case. This is as it should be. I fail to see the problem.

As I said, try shrinking your browser below 800 pixels.

So I get a horizontal scrollbar and the center column is still widest.
I still don't see what you were trying to point out here. The site is
not a good example of either fluid or fixed design.

You haven't yet shown any benefits of a fixed layout. If the 2 URLs you
posted are the best you can come up with, you'll never convince anyone.

--
To email a reply, remove (dash)ns(dash). Mail sent to the ns
address is automatically deleted and will not be read.

[Eric Jarvis]

Harlan Messinger wrote:

But what is visually appealing doesn't suddenly disappear with each new
medium, requiring everyone to start from scratch.

yes it does...not everything...but few aesthetic concepts transfer across
more than two media

I've worked in several art forms, and designed for several media...I've
commissioned designs in just about every medium I can think of...you
ALWAYS have to start by getting a basic understanding of the medium

--
eric
www.ericjarvis.co.uk
"live fast, die only if strictly necessary"

[EightNineThree]

"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bk************@ID-114100.news.uni-berlin.de...

"I V" <iv*****@gmx.co.uk> wrote in message
news:pa****************************@gmx.co.uk...

On Fri, 19 Sep 2003 11:04:40 -0400, Harlan Messinger wrote:
And getting a poorer quality display. I don't think that's a very good
'solution', and besides it's a pseudo-problem, as you've yet to give any
good reason to attempt to fix the width of a web page.

Well, yeah, I have, but a bunch of people who think that good design
concepts that were arrived at through decades of study and research are
suddenly invalid don't want to acknowledge the possibility that they still
have even the smallest role to play.

Decades of study and research on the design of what?
Not web pages.
I'm not sure what group you think you're posting to, but this is
"comp.infosystems.www.authoring.html"
Simply put, the topic of conversation - and the topic this thread is based
on - is the practice of authoring HTML for the Worldwide Web.
So, best-case-scenerio, you're talking about 10 years of *possible* study
and research.

Wait. Lemme guess. You're still confused and think this is a print media
newsgroup.
--
Karl Core

Charles Sweeney says my sig is fine as it is.

[Kris]

In article <bk************@ID-114100.news.uni-berlin.de>,
"Harlan Messinger" <h.*********@comcast.net> wrote:

I *do* try to separate web content
from layout, and I wish that Netscape 4.x would go away so I could start
using DIVs for layout.

I wish you wouldn't.

--
Kris
kr*******@xs4all.netherlands (nl)
"We called him Tortoise because he taught us" said the Mock Turtle.

[Alan J. Flavell]

On Mon, 22 Sep 2003, EightNineThree wrote:

I'm not sure what group you think you're posting to, but this is
"comp.infosystems.www.authoring.html"
Simply put, the topic of conversation - and the topic this thread is based
on - is the practice of authoring HTML for the Worldwide Web.
So, best-case-scenerio, you're talking about 10 years of *possible* study
and research.

Ah, but based on principles that were already in everyday use at the
time in a different context. I was using what I now recognise to have
been a structural markup language, for text and graphical inserts,
that could readily be reconfigured for different output media by
twiddling some parameters external to the marked-up content, on an IBM
mainframe _years_ before the WWW was started. So that's logical
content structure and an external stylesheet, basically.

Word processors were also doing it.

Some things translate well to other media, some things don't. That
idea translated well (pity that the Mosaic-spawn gave us something we
didn't need, on the pretext that it was what many people could be
persuaded to want!)

[Barry Pearson]

EightNineThree wrote:
[snip]

Yeah, a 720 pixel fixed table looks great on my 1400 pixel wide
monitor.

2 of my web sites are based around 700-pixel tables. I had a reason for this,
and it is a genuine dilemma for which I don't know the answer.

The primary content of those 2 web sites are photographs. Take the one below.
I decided after a lot of research and experimentation to make my photographs
fit into a 700 x 500 box (snug in at least one dimension). It is about the
largest that someone with an 800 x 600 screen can handle satisfactorily. Ditto
that someone with dial-up is likely to tolerate.
http://www.birdsandanimals.info/

I then decided to make many of the other pages fit the same width. It could be
argued that the 2 types of page shouldn't be tied together like that, but
frankly if you object to articles fixed at 700, you are likely to object to
the photographs, and perhaps the site isn't for you.

The problem is that I share your view about large screens. My sole computer is
a 2 and a half year old laptop with a 1400 x 1050 screen, at about 117 pixels
per inch. (I normally run it at 1280 x 1024 to get 24 bit colour). I also use
broadband when at home. So I am dissatisfied with a 700 x 500 photograph. But
resizing in browsers isn't good enough quality for me to rely on, and a
photograph of that size may be up to about 100 KB which is a bit slow on
dial-up. It is a compromise.

Even worse, I don't actually know what the target is. We can see CSSs taking
over much of the presentation - a clear target. (All my pages have a CSS). The
CSS standard actually treats "px" as relative, not absolute, and W3C recommend
scaling based on the angle subtended at the eye. (So the baseline would be 1
at about 90 ppi, and at about 180 ppi a CSS "px" unit would be 2 pixels wide
on the screen. At least that is how I read it). But that begs a lot of
questions (such as "how does the use agent know the ppi?") It also doesn't
tell me whether the pixel value in the <img ..> tag should also be relative.

Neither do I know what the technology for resolving this is. SVG isn't good
for photographs. I wondered if the answer would be to have a large JPEG2000
photograph on the server, from which some lower resolution version could be
extracted according to something in the HTML or CSS, but I made that up myself
and it may not make sense.

My 2nd web site that uses similar formats is below. In that case, the "info"
pages about photographs - the techie stuff for photographers - just use 100%
width. (Click on "info" under the thumbnails in the galleries).
http://www.barry.pearson.name/index.htm

And a 3rd web site uses 100% width throughout. But that is a "utility" web
site - a pick-up truck, not pretty. (I don't do pretty).
http://www.childsupportanalysis.co.uk/

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[kchayka]

Barry Pearson wrote:

The
CSS standard actually treats "px" as relative, not absolute, and W3C recommend
scaling based on the angle subtended at the eye.

FYI, no browser that I know of has implemented px units per the W3C
specs, they all use screen pixels instead. Thus, px may be relative
units in theory, but in practice they are absolute.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Markus Ernst]

"kchayka" <kc*********@sihope.com> schrieb im Newsbeitrag
news:3f********@news.sihope.com...

Barry Pearson wrote:

The
CSS standard actually treats "px" as relative, not absolute, and W3C recommend scaling based on the angle subtended at the eye.

FYI, no browser that I know of has implemented px units per the W3C
specs, they all use screen pixels instead. Thus, px may be relative
units in theory, but in practice they are absolute.

AFAIK there are 2 different interpretations of px sized CSS:
- IE treats it as an absolute value and displays 1px = 1 screen pixel
- Mozilla treats it as relative to text zoom in font sizes, causing
different sizes when text zoom is on: At text zoom 150% a 12px font is
displayed in 18px size, a 12px line in 12px size.

--
Markus

[kchayka]

Markus Ernst wrote:

"kchayka" <kc*********@sihope.com> schrieb im Newsbeitrag
news:3f********@news.sihope.com...

Barry Pearson wrote:

>
> The
> CSS standard actually treats "px" as relative, not absolute, and W3C
> recommend scaling based on the angle subtended at the eye.

FYI, no browser that I know of has implemented px units per the W3C
specs, they all use screen pixels instead. Thus, px may be relative
units in theory, but in practice they are absolute.

AFAIK there are 2 different interpretations of px sized CSS:
- IE treats it as an absolute value and displays 1px = 1 screen pixel
- Mozilla treats it as relative to text zoom in font sizes, causing
different sizes when text zoom is on: At text zoom 150% a 12px font is
displayed in 18px size, a 12px line in 12px size.

Text zoom isn't really a factor where px units are concerned. If it
were, then any element sized in px units would be affected, not just text.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Barry Pearson]

Markus Ernst wrote:

"kchayka" <kc*********@sihope.com> schrieb im Newsbeitrag
news:3f********@news.sihope.com...

Barry Pearson wrote:

>
> The
> CSS standard actually treats "px" as relative, not absolute, and
> W3C recommend scaling based on the angle subtended at the eye.

FYI, no browser that I know of has implemented px units per the W3C
specs, they all use screen pixels instead. Thus, px may be relative
units in theory, but in practice they are absolute.

AFAIK there are 2 different interpretations of px sized CSS:
- IE treats it as an absolute value and displays 1px = 1 screen pixel
- Mozilla treats it as relative to text zoom in font sizes, causing
different sizes when text zoom is on: At text zoom 150% a 12px font is
displayed in 18px size, a 12px line in 12px size.

The discussion above isn't to do with such things as showing text at different
sizes depending on user options. Instead it is to do with what a user agent
should do with the "px" unit itself on "untypical" displays. See:

http://www.w3.org/TR/REC-CSS2/syndata.html#length-units

In effect, if the CSS specifies that something is (say) 1px, but the display
device displays significantly different from 90 "things" per inch, the
recommendation is to map it onto a different number of those "things". If, for
example, you have a TFT display with 180 display units per inch (often called
pixels or dots), then the recommendation is for the user agent to map that 1px
thing (a border, say) onto 2 display units (pixels or whatever) on the
display. So that it will occupy the same number of inches that it would on a
90 "things" per inch display. In other words, if you say that "margin-top:
90px", the recommendation is actually to treat this as request to make it
"about 1 inch", and treat this accordingly on other displays. (Well, sort of).

I suspect relatively few people know that! And it appears (I'm not surprised
at all) that it hasn't been implemented.

Just one more thing to confuse a poor photographer wanting to show pictures of
size X x Y on a screen, with text underneath a little bit narrower than X so
that it looks good!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Tina Holmboe]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in <Yz***************@newsfep3-gui.server.ntli.net>:

[quoting EightNineThree (?)]

[snip]

Yeah, a 720 pixel fixed table looks great on my 1400 pixel wide
monitor.

I then decided to make many of the other pages fit the same width. It could be
argued that the 2 types of page shouldn't be tied together like that, but
frankly if you object to articles fixed at 700, you are likely to object to
the photographs, and perhaps the site isn't for you.
Ah - but these two issues are unrelated. What _you_ have is content which
has an inherent width of, say, 700 by 462 (the the very nice photograph
of the Impala family). You can't wrap a photograph, nor enlarge it[1]

What started this debate was content which have an inherent width equal to
the length of the longest word, to be complicated about it. The content
with which the debate started *can* wrap, and more importantly: it can keep
wrapping as the font size is enlarged thereby avoiding horizontal scroll[2]

Personally I liked your site - and I'll be sure to send it on to a fellow
in the family who has a PhD in Ornithlog ... nornit ... orni - he's a bird-
watcher.

Neither do I know what the technology for resolving this is. SVG isn't good
for photographs. I wondered if the answer would be to have a large JPEG2000

Honestly ? Don't worry. In your case the content itself has an intrinsic
size. Can't be helped, really. I suggest using ... 250 by 250 thumbnails
linking to a full-sized PNG or something though. Or an even smaller
thumbnail linking to a 800 by something version which again has a link
to the real McCoy[3].

But I don't think you should worry. When the image itself is the content,
as opposed to just eye-candy, then the page will be as wide as the image
is. Nothing to be done about that. You could, of course, recode it as
Postscript - which IS good enough - but it won't magically turn into a
vector graphic. It is raster, and it'll remain raster.

Just create a set of thumbnails - can be done automatically - and include
them with the size in bytes of the full photograph. The page with the
thumbnails, on the other hand, should wrap nicely at around the maximum
width of one of'em.

[1]
In the sense that it'll scale.
[2]
Which, if ones motor control is not what it once was, or what it never
could be, is important.
[3]
I've done something like that with the 2272 by 1704 JPGs produced by
the Canon s40 - some of my friends want the full-sized thing for use
in various contexts, but most of the family are happy seeing the 800 by
600 version. With thumbnails they can select which one, and thereby choose
how much bandwith they're willing to spend.

We still pay for that, around these parts.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

[Daniel R. Tobias]

kchayka <kc*********@sihope.com> wrote in message news:<3f********@news.sihope.com>...

Text zoom isn't really a factor where px units are concerned. If it
were, then any element sized in px units would be affected, not just text.

This varies by browser. In Mozilla, as already stated, px-sized fonts
are zoomable just like any other sort of text, causing the text
possibly to differ from the actual pixel numbers specified by the
stylesheet. Other px-sized things such as images are unaffected. In
Opera, on the other hand, I believe there is a zoom feature that
resizes graphics as well as text. (I don't use that browser very
much, so I'm not greatly familiar with its features, but I seem to
recall that one.)

--
Dan

[kchayka]

Daniel R. Tobias wrote:

kchayka <kc*********@sihope.com> wrote in message news:<3f********@news.sihope.com>...

Text zoom isn't really a factor where px units are concerned. If it
were, then any element sized in px units would be affected, not just text.

This varies by browser. In Mozilla, as already stated, px-sized fonts
are zoomable just like any other sort of text, causing the text
possibly to differ from the actual pixel numbers specified by the
stylesheet. Other px-sized things such as images are unaffected. In
Opera, on the other hand, I believe there is a zoom feature that
resizes graphics as well as text.

Opera uses a page zoom, not just text zoom, so all elements are
affected, including images, Flash, or whatever else is on the page.

KHTML browsers (Konqueror, Safari, OmniWeb) and Mac browsers in general
(MacIE, iCab, older OmniWeb) behave like mozilla and only zoom text,
regardless of the units.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Salagir]

On Thu, 25 Sep 2003 16:59:45 +0100, in comp.infosystems.www.authoring.html,
Barry Pearson wrote:

Markus Ernst wrote:
90 "things" per inch display. In other words, if you say that "margin-top:
90px", the recommendation is actually to treat this as request to make it
"about 1 inch", and treat this accordingly on other displays. (Well, sort of).
I suspect relatively few people know that! And it appears (I'm not surprised
at all) that it hasn't been implemented.

Well, it should never be.

Or let them call this a "thing" ( margin: 90tg; ^^), not a pixel!!

This recomendation is very nice, it's true that everything on a website
should be resized and no size should be static...

But there is a big problem with that: images!

Jpeg, gifs, pngs, are in _pixel_, in real pixels, not
your-screen-def-divided-by-the-distance-between-the-eye-n-the-screen-
plus-the-age-of-the-USA's-president-less-42

And resize them with the browser usually sucks, even with anti-aliasing and
other stuff (and more: in some images, you *don't* want it to be resized,
like a supernintendo screenshot: no blur, please, arg!).

There is one thing that could have helped us much, I've wanted it from
the day I made my 1st website (so about 1997) and I still want it and it
still doesn't exist: a standart image vectorial format.

An image, like jpeg or gif: with no size, only a ratio, and with polygons and
lines in it. And that would be opened by any browser.
It's very, very easy, and lots of logos and web images could be as good
in vectorial format.
How come no one thought about that????

And no, it's still doesnt exists: flash and svg are not vectorial
images: they are big animations.
Of course you can do only a non-animated image, but still, no browser
can handle them like jpeg.

Most of the time, a plugin is necessary. For SVG: I just can't make it
work on browsers other that ie (and even not all them).
For flash: well, to begin with, it costs much to get the software to do
it. And still, it's so full of possibilities that people are afraid of
it and can't use it for a simple logo.
And still, "you need to get the plugin"...
If there *is* a standart vectorial image format that almost all
browsers[1] handle (without plugin), that I've never heard of, I'll be
very pleased to know!!
[1] IE4->6, Mozilla (& galeon, firebird, netscape, etc), Opera, and
others that are quite used.
--
++++++++ Zelda, Dragon Ball, Mana and my (art)work at www.salagir.com ++++++++
The art of conversation is to disagree without being disagreeable.

[Markus Ernst]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> schrieb im Newsbeitrag
news:Hk***************@newsfep3-gui.server.ntli.net...

In effect, if the CSS specifies that something is (say) 1px, but the display device displays significantly different from 90 "things" per inch, the
recommendation is to map it onto a different number of those "things". If, for example, you have a TFT display with 180 display units per inch (often called pixels or dots), then the recommendation is for the user agent to map that 1px thing (a border, say) onto 2 display units (pixels or whatever) on the
display. So that it will occupy the same number of inches that it would on a 90 "things" per inch display. In other words, if you say that "margin-top:
90px", the recommendation is actually to treat this as request to make it
"about 1 inch", and treat this accordingly on other displays. (Well, sort of).
I suspect relatively few people know that! And it appears (I'm not surprised at all) that it hasn't been implemented.

Well actually it _has been_ implemented: If you print out your page on a
1200 dpi printer, a 2 px line will have a dimension of about 2 points, and
not 2 printer dots (for convenience I call the input units pixels, the
output units dots).

This spec actually says to implement things in a reasonable way. A
conventional Mac screen has a standard resolution of 72 dpi, a Windows
screen one of 96 dpi. And it would not be reasonable to enlarge images on
Mac screens by 96/72. They both show a CSS value of 1px as 1 screen dot, but
the display of point defined sizes differs (as 1 point is 1/72 of an inch,
and an inch has not the same amount of dots on each side).

But of course it is reasonable to scale the display at very different
resolutions of 180 or 1200 or whatever dpi, as long as the scale factor is
an integer value (otherwise graphics are distorted). Which IMO is
implemented in all visual browsers I know.

--
Markus

[Barry Pearson]

Markus Ernst wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> schrieb im [snip]

In effect, if the CSS specifies that something is (say) 1px, but the
display device displays significantly different from 90 "things" per
inch, the recommendation is to map it onto a different number of
those "things". If, for example, you have a TFT display with 180
display units per inch (often called pixels or dots), then the
recommendation is for the user agent to map that 1px thing (a
border, say) onto 2 display units (pixels or whatever) on the
display. So that it will occupy the same number of inches that it
would on a 90 "things" per inch display. In other words, if you say
that "margin-top: 90px", the recommendation is actually to treat
this as request to make it "about 1 inch", and treat this
accordingly on other displays. (Well, sort of).

I suspect relatively few people know that! And it appears (I'm not
surprised at all) that it hasn't been implemented.

Well actually it _has been_ implemented: If you print out your page
on a 1200 dpi printer, a 2 px line will have a dimension of about 2
points, and not 2 printer dots (for convenience I call the input
units pixels, the output units dots).

I have written in NGs elsewhere about the relationship between pixels in
digital images and their mapping onto display screens and printers. There is
lots more in rec.photo.digital from me on the subject, and I don't want to
repeat it here. See:
http://groups.google.com/groups?as_q...uthors=Pearson

The following Google searches will find a little of it that has made its way
out of NGs. (I have been meaning to write an article on the topic for one of
my web sites, and perhaps it is time I did).
http://www.google.com/search?q=%22barry+pearson%22+ppi
http://www.google.com/search?q=%22barry+pearson%22+dpi

I have a rule of thumb. When I am working on photographs, wherever possible, I
use just pixels & centimetres (but it could be inches). It makes life much
easier. It is far better to avoid "dots" completely - avoid the term, avoid
calculations based on it. Also it is typically best to avoid dpi & ppi - they
tend to cause a lot of confusion. Lots of people think that you need to make
photographs into 72 ppi to put them on the web! And I've been asked to supply
photographs at "300 dpi" without either being told whether that really means
ppi (obviously it does for "300"), or how many inches it is to occupy! (But
this conversation needs to drop into dirty ppi/dpi talk!)

I agree that the W3C recommendation was trying to do something sensible.
Unfortunately, I believe they have in effect hijacked a standard term and put
a new spin on it. (They've "sexed it up"!)

For example, the implication (perhaps you or someone can correct me if I'm
wrong) is that if I have an <img width="700" ...> in the HTML and put some
text under it with a CSS declaration { width: 700px; } I may not get the same
width for both if the display has an "untypical" resolution and the
recommendation is followed. In fact, how would you get the same width for
both?

I believe that we need a unit in CSS that has the meaning "treat one of these
in precisely the same way that the user agent renders each pixel of
pixel-oriented content in the parent document". (A bit clumsy!) In other
words, if the UA maps the above width="700" image onto (say) 700 display
units, some text with { width: 700zzz; } would be the same width. (Where zzz
is this unit I'm talking about). Or if it mapped that image onto (say) 1050
display units, it would do the same with the text. AND I believe that CSS unit
SHOULD be called pixel or px, not zzz!

Perhaps that is actually how UAs will eventually treat the px unit. Perhaps
they will find out somehow how to map pixel-oriented material onto the
particular display, then treat the px unit exactly the same way. If so - good.
But surely it ought to be in the CSS specification? Perhaps it is and I
haven't spotted it.
This spec actually says to implement things in a reasonable way. A
conventional Mac screen has a standard resolution of 72 dpi, a Windows
screen one of 96 dpi. And it would not be reasonable to enlarge
images on Mac screens by 96/72. They both show a CSS value of 1px as
1 screen dot, but the display of point defined sizes differs (as 1
point is 1/72 of an inch, and an inch has not the same amount of dots
on each side).
72 is a blast from the past. Only a small proportion have that resolution
nowadays. 96 may be closer to the Windows average, but as I type this it is
appearing on a 117 ppi screen and a 90 ppi screen at the same time.

But think about that 72 ppi display. The W3C CSS recommendation would map 90
px units onto an inch on the screen, yet for reasons you state the UA might
map 72 image pixels per inch. Somehow they really ought to be locked together.
But of course it is reasonable to scale the display at very different
resolutions of 180 or 1200 or whatever dpi, as long as the scale
factor is an integer value (otherwise graphics are distorted). Which
IMO is implemented in all visual browsers I know.

Whereas IE6 and Mozilla Firebird and perhaps others have "display text larger"
options, Opera 7.2 can display the whole page larger including images. All I
can say is - yeuk! It makes sense in one way to scale all the content in step,
but sometimes I feel that scaling the text but not the photograph would still
make sense some of the time.

I agree that integral mapping like that is more likely to be OK than
intermediate values. But it is actually not nearly a good as supplying more
pixels that have been prepared for the purpose. I've been trying to find out
what the target is for scaling photographs for different display resolutions,
and I can't find a proposal / recommendation / standard. It is almost as
though the problem is being ignored. (I keep hoping there is an answer
somewhere in JPEG2000).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Salagir wrote:

On Thu, 25 Sep 2003 16:59:45 +0100, in
comp.infosystems.www.authoring.html, Barry Pearson wrote:

Markus Ernst wrote:
90 "things" per inch display. In other words, if you say that
"margin-top: 90px", the recommendation is actually to treat this as
request to make it "about 1 inch", and treat this accordingly on
other displays. (Well, sort of). I suspect relatively few people
know that! And it appears (I'm not surprised at all) that it hasn't
been implemented.
Well, it should never be.

Or let them call this a "thing" ( margin: 90tg; ^^), not a pixel!!

I've just responded elsewhere about this. In effect, I said that the CSS px
unit should be locked to the way the user agent handles a pixel in
pixel-oriented content. If it scales the latter, it should scale to px unit in
precisely the same way. I hope browsers will keep the 2 things in step if they
ever do consider scaling the px unit.
This recomendation is very nice, it's true that everything on a
website should be resized and no size should be static...

But there is a big problem with that: images!

Jpeg, gifs, pngs, are in _pixel_, in real pixels, not
your-screen-def-divided-by-the-distance-between-the-eye-n-the-screen-
plus-the-age-of-the-USA's-president-less-42

And resize them with the browser usually sucks, even with
anti-aliasing and other stuff (and more: in some images, you *don't*
want it to be resized, like a supernintendo screenshot: no blur,
please, arg!).

There is one thing that could have helped us much, I've wanted it from
the day I made my 1st website (so about 1997) and I still want it and
it still doesn't exist: a standart image vectorial format.

An image, like jpeg or gif: with no size, only a ratio, and with
polygons and lines in it. And that would be opened by any browser.
It's very, very easy, and lots of logos and web images could be as
good
in vectorial format.
How come no one thought about that????
Chuckle! Now think how big such an image file would have to be! Surely it
would be mind-blowingly, awesomely, galactically, enormous? At least for a
photograph, which is what I am talking about. In fact, of course, photograph
is firmly locked onto pixels, not vectors. Converting to vectors is "an
interesting exercise".

It is worth keeping an eye on JPEG2000, because a JP2 file, I understand, can
have a lower resolution image extracted from it without reprocessing the whole
lot. But what I don't know is whether these have to be prepacked within it.
(Eg. you put a photograph and its thumbnail into the file, then you can get
just the thumbnail out). I suspect that it would be hard to extract any
abitrary resolution from it.

[snip] If there *is* a standart vectorial image format that almost all
browsers[1] handle (without plugin), that I've never heard of, I'll be
very pleased to know!!

[snip]

I think the answer for non-photos is SVG, and eventually all browsers will
support it. Needing plugins is a transitional stage. But it isn't for
photographs.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Tina Holmboe wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in
<Yz***************@newsfep3-gui.server.ntli.net>: [snip] Just create a set of thumbnails - can be done automatically - and
include them with the size in bytes of the full photograph. The
page with the thumbnails, on the other hand, should wrap nicely at
around the maximum width of one of'em.

[snip]

Ah! I have a site standard (at least on my photography site) of rows of 5
thumbnails. In fact, my thumbail size (they can fit in a 125 x 125 box) was
dictated by having such a row take up about the same width as a 700 pixel
photograph.

For the reason why I've standardised on 5, see the following page:

http://www.barry.pearson.name/photog...olios/lrps.htm

I've continued the theme since then through all my galleries. I don't put
photographs into galleries until I can build balanced rows of 5.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Walter Ian Kaye]

In article <ct**************@newsfep1-gui.server.ntli.net>,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

This spec actually says to implement things in a reasonable way. A
conventional Mac screen has a standard resolution of 72 dpi, a Windows
screen one of 96 dpi. And it would not be reasonable to enlarge
images on Mac screens by 96/72. They both show a CSS value of 1px as
1 screen dot, but the display of point defined sizes differs (as 1
point is 1/72 of an inch, and an inch has not the same amount of dots
on each side).

72 is a blast from the past. Only a small proportion have that resolution
nowadays. 96 may be closer to the Windows average, but as I type this it is
appearing on a 117 ppi screen and a 90 ppi screen at the same time.

Not exactly a blast from the past. The Mac OS (including OS X) is STILL
hard-wired to 72 -- it does not "know" how a video display is configured
(and even if it did, it wouldn't scale anything to match).

My PowerBook *screen* is 91ppi (1152x768), but to the OS it is 72.

And back to the subject line, my browser window is 512px wide on the
outside, as I prefer an imaging width of 480px (80 columns of Monaco 9).
If a page don't fit, it ain't worth readin'. Period.

As for thumbnails, I just stack 'em vertically:
http://www.natural-innovations.com/ds/dsf2002/
-boo
who stopped resizing his browser windows ten years ago

[Barry Pearson]

Walter Ian Kaye wrote:

In article <ct**************@newsfep1-gui.server.ntli.net>,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

> This spec actually says to implement things in a reasonable way. A
> conventional Mac screen has a standard resolution of 72 dpi, a
> Windows screen one of 96 dpi. And it would not be reasonable to
> enlarge images on Mac screens by 96/72. They both show a CSS value
> of 1px as 1 screen dot, but the display of point defined sizes
> differs (as 1 point is 1/72 of an inch, and an inch has not the
> same amount of dots on each side).
72 is a blast from the past. Only a small proportion have that
resolution nowadays. 96 may be closer to the Windows average, but as
I type this it is appearing on a 117 ppi screen and a 90 ppi screen
at the same time.

Not exactly a blast from the past. The Mac OS (including OS X) is
STILL hard-wired to 72 -- it does not "know" how a video display is
configured (and even if it did, it wouldn't scale anything to match).

This discussion is really about the physical screen, not what the OS says.
(Although it is hard to see how the W3C recommendations can be followed if the
OS lies).

It is worth having a look at the W3C recommendation to clarify this:
http://www.w3.org/TR/REC-CSS2/syndata.html#length-units

It talks about viewing distances, angles seen by the eye, etc.
My PowerBook *screen* is 91ppi (1152x768), but to the OS it is 72.

And back to the subject line, my browser window is 512px wide on the
outside, as I prefer an imaging width of 480px (80 columns of Monaco
9). If a page don't fit, it ain't worth readin'. Period.
Then you are perhaps not part of my target audience. My photographs can be up
to 700 pixels wide. (You probably don't like horizontal scrolling - who does?)
As for thumbnails, I just stack 'em vertically:
http://www.natural-innovations.com/ds/dsf2002/

-boo
who stopped resizing his browser windows ten years ago

An interesting approach.

Fascinating to see 800 x 600 pixel photographs coming from someone with an
imaging width of 480 pixels. Do you use browser resizing, or horizontal
scrolling, or live with the fact that you can't view your own pictures on the
web?

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Walter Ian Kaye]

In article <Xn******************@newsfep1-win.server.ntli.net>,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

Walter Ian Kaye wrote:

In article <ct**************@newsfep1-gui.server.ntli.net>,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

> This spec actually says to implement things in a reasonable way. A
> conventional Mac screen has a standard resolution of 72 dpi, a
> Windows screen one of 96 dpi. And it would not be reasonable to
> enlarge images on Mac screens by 96/72. They both show a CSS value
> of 1px as 1 screen dot, but the display of point defined sizes
> differs (as 1 point is 1/72 of an inch, and an inch has not the
> same amount of dots on each side).

72 is a blast from the past. Only a small proportion have that
resolution nowadays. 96 may be closer to the Windows average, but as
I type this it is appearing on a 117 ppi screen and a 90 ppi screen
at the same time.

Not exactly a blast from the past. The Mac OS (including OS X) is
STILL hard-wired to 72 -- it does not "know" how a video display is
configured (and even if it did, it wouldn't scale anything to match).

This discussion is really about the physical screen, not what the OS says.
(Although it is hard to see how the W3C recommendations can be followed if the
OS lies).

It is worth having a look at the W3C recommendation to clarify this:
http://www.w3.org/TR/REC-CSS2/syndata.html#length-units

It talks about viewing distances, angles seen by the eye, etc.

If I could change the ppi of my LCD screen from 91 to 72, I would.
That's why I prefer CRT screens -- so that the physical and electronic
will match. I actually like the black border on my CRT screen after I
adjust the geometry to 72. On my PowerBook, I have to "pretend" that the
screen is farther away to account for the smaller size on the LCD.

My PowerBook *screen* is 91ppi (1152x768), but to the OS it is 72.
And back to the subject line, my browser window is 512px wide on the
outside, as I prefer an imaging width of 480px (80 columns of Monaco
9). If a page don't fit, it ain't worth readin'. Period.

Then you are perhaps not part of my target audience. My photographs can be up
to 700 pixels wide. (You probably don't like horizontal scrolling - who does?)

Well I don't like it on *text*. You don't "read" a photograph (unless
it's a photo of a document). There is no need to match up a point on the
right edge to a point on the left edge as there is with a run of text,
so there's no cognitive impairment or predetermined flow. An image
doesn't wrap, because that's not applicable.

As for thumbnails, I just stack 'em vertically:
http://www.natural-innovations.com/ds/dsf2002/

-boo
who stopped resizing his browser windows ten years ago

An interesting approach.

Fascinating to see 800 x 600 pixel photographs coming from someone with an
imaging width of 480 pixels. Do you use browser resizing, or horizontal
scrolling, or live with the fact that you can't view your own pictures on the
web?

I live with the fact that the user's viewing app and its own
functionalities and preferences determine the presentation of the image,
rather than some arbitrary decision of mine how to present it. The link
from the thumbnail is not to a Web page, but to the image itself.

I only wish Safari had the zoom features that MacIE ha(s|d). Point is, I
as Web author am not dictating the presentation.

As for me personally, since I no longer use IE, I just scroll.

Hmm... I wonder if it would be worth it to give the user some size
options with the View Image button. It's certainly doable...
-Walter

[Markus Ernst]

----- Original Message -----
From: "Walter Ian Kaye" <bo*@natural-innovations.spam-deflector.com>
Newsgroups: comp.infosystems.www.authoring.html
Sent: Sunday, September 28, 2003 10:14 PM
Subject: Re: Keeping Web Page at Fixed Width

Hmm... I wonder if it would be worth it to give the user some size
options with the View Image button. It's certainly doable...

That would be a nice thing. Anyway it would imply a server-side image
scaling. This is actually doable, but scaling an image is always an
interpretation of the image, as pixel values are changed. If you edit your
pictures with Photoshop you know that different subjects need different
amounts of unsharp masking after scaling, or that graphical elements like
lines should not be blurred and so on.

So this server-side scaling would need more than just scaling. Maybe Adobe
or whoever will deliver an engine for this in the future...

(This would also give the above discussion of page zoom a new dimension: Let
the UA calculate the page zoom value and demand the appropriate picture size
from the server...)

--
Markus

[Salagir]

On Fri, 26 Sep 2003 11:41:46 +0100, in comp.infosystems.www.authoring.html,
Barry Pearson wrote:

Salagir wrote:

There is one thing that could have helped us much, I've wanted it from
the day I made my 1st website (so about 1997) and I still want it and
it still doesn't exist: a standart image vectorial format.

An image, like jpeg or gif: with no size, only a ratio, and with
polygons and lines in it. And that would be opened by any browser.
It's very, very easy, and lots of logos and web images could be as
good in vectorial format.
How come no one thought about that???? Chuckle! Now think how big such an image file would have to be! Surely it
would be mind-blowingly, awesomely, galactically, enormous? At least for a
photograph, which is what I am talking about.

Sorry I missed the beginning of the thread :)
Of course, photos are the type of image that must stay in jpeg.

But almost all gifs and png would come out well as vectors.
It is worth keeping an eye on JPEG2000, because a JP2 file, I understand, can
have a lower resolution image extracted from it without reprocessing the whole
lot. But what I don't know is whether these have to be prepacked within it.
(Eg. you put a photograph and its thumbnail into the file, then you can get
just the thumbnail out). I suspect that it would be hard to extract any
abitrary resolution from it.
I don't really know either. Maybe you can extract resolutions that are
two -or a multiple of two- time less -or/and more- than the initial
resolution.

Shouldn't these kind of image take years to encode and seconds to decode?
I think the answer for non-photos is SVG, and eventually all browsers will
support it. Needing plugins is a transitional stage.

When will this transitionnal stage end ? I mean, even 32-bits pngs
aren't supported by the most used (and most stu***) browser in the
world.

-_-

--
++++++++ Zelda, Dragon Ball, Mana and my (art)work at www.salagir.com ++++++++
Moi tous les matins je casse le vent, ca me purifie c'est important !

[Barry Pearson]

Salagir wrote:

On Fri, 26 Sep 2003 11:41:46 +0100, in
comp.infosystems.www.authoring.html, Barry Pearson wrote:

Salagir wrote: [snip]

> An image, like jpeg or gif: with no size, only a ratio, and with
> polygons and lines in it. And that would be opened by any browser.
> It's very, very easy, and lots of logos and web images could be as
> good in vectorial format.
> How come no one thought about that???? Chuckle! Now think how big such an image file would have to be!
Surely it would be mind-blowingly, awesomely, galactically,
enormous? At least for a photograph, which is what I am talking
about.

Sorry I missed the beginning of the thread :)
Of course, photos are the type of image that must stay in jpeg.

But almost all gifs and png would come out well as vectors.

Yes, I think we agree. In fact, you have triggered a possible (longer term)
solution to something where I don't know what the "proper" answer is:

Sometimes, I want to put into text an in-line "readable logo". For example,
the UK's Child Support Agency has a GIF logo with their name in a particular
font, colour, etc. So I wanted to be able to use the logo in a sentence
instead of just plain words. (With "alt" text, of course). But the logo isn't
scalable in the way the text is. What I have actually done is used a CSS to
embellish the text with an approximation of the true logo. An example can be
seen near the top of:
http://www.childsupportanalysis.co.uk/

Perhaps we could have in-line scalable logos. (Or perhaps it could be argued
that I shouldn't be trying to do what I am doing! That is a question of
design, rather than proper mark-up).

[snip] I don't really know either. Maybe you can extract resolutions that are
two -or a multiple of two- time less -or/and more- than the initial
resolution.

Shouldn't these kind of image take years to encode and seconds to
decode?

[snip]

I think there is an aspect of that in JPEG2000. (But not "years", please! And
less than "seconds" too. Life's too short).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/