Keeping Web Page at Fixed Width

[Barry Pearson]

Re: Keeping Web Page at Fixed Width

Markus Ernst wrote:[color=blue]
> "kchayka" <kcha-un-yka@sihope.com> schrieb im Newsbeitrag
> news:3f72e448$1 @news.sihope.co m...[color=green]
>> Barry Pearson wrote:[color=darkred]
>> >
>> > The
>> > CSS standard actually treats "px" as relative, not absolute, and
>> > W3C recommend scaling based on the angle subtended at the eye.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

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]

Re: Keeping Web Page at Fixed Width

"Barry Pearson" <news@childsupp ortanalysis.co. uk> exclaimed in <YzAcb.398$Z46. 332@newsfep3-gui.server.ntli .net>:

[quoting EightNineThree (?)]
[color=blue]
> [snip][color=green]
>> Yeah, a 720 pixel fixed table looks great on my 1400 pixel wide
>> monitor.[/color][/color]

[color=blue]
> 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.[/color]

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.



[color=blue]
> 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[/color]

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
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[Daniel R. Tobias]

Re: Keeping Web Page at Fixed Width

kchayka <kcha-un-yka@sihope.com> wrote in message news:<3f73037a$ 1@news.sihope.c om>...[color=blue]
> 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.[/color]

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]

Re: Keeping Web Page at Fixed Width

Daniel R. Tobias wrote:
[color=blue]
> kchayka <kcha-un-yka@sihope.com> wrote in message news:<3f73037a$ 1@news.sihope.c om>...[color=green]
>> 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.[/color]
>
> 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.[/color]

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]

Re: Keeping Web Page at Fixed Width

On Thu, 25 Sep 2003 16:59:45 +0100, in comp.infosystem s.www.authoring.html,
Barry Pearson wrote:[color=blue]
> 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.[/color]

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]

Re: Keeping Web Page at Fixed Width

"Barry Pearson" <news@childsupp ortanalysis.co. uk> schrieb im Newsbeitrag
news:HkEcb.773$ Z46.445@newsfep 3-gui.server.ntli .net...
[color=blue]
> In effect, if the CSS specifies that something is (say) 1px, but the[/color]
display[color=blue]
> device displays significantly different from 90 "things" per inch, the
> recommendation is to map it onto a different number of those "things". If,[/color]
for[color=blue]
> example, you have a TFT display with 180 display units per inch (often[/color]
called[color=blue]
> pixels or dots), then the recommendation is for the user agent to map that[/color]
1px[color=blue]
> 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[/color]
a[color=blue]
> 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[/color]
of).[color=blue]
>
> I suspect relatively few people know that! And it appears (I'm not[/color]
surprised[color=blue]
> at all) that it hasn't been implemented.[/color]

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]

Re: Keeping Web Page at Fixed Width

Markus Ernst wrote:[color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> schrieb im[/color]
[snip][color=blue][color=green]
>> 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.[/color]
>
> 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).[/color]

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.digit al from me on the subject, and I don't want to
repeat it here. See:

http://groups.google.com/groups?as_q=ppi%20dpi&as_ugroup=rec.photo.digital&as_uauthors=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.
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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.[/color]

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]

Re: Keeping Web Page at Fixed Width

Salagir wrote:[color=blue]
> On Thu, 25 Sep 2003 16:59:45 +0100, in
> comp.infosystem s.www.authoring.html, Barry Pearson wrote:[color=green]
>> 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.[/color]
>
> Well, it should never be.
>
> Or let them call this a "thing" ( margin: 90tg; ^^), not a pixel!![/color]

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.
[color=blue]
> 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????[/color]

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][color=blue]
> 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!![/color]
[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]

Re: Keeping Web Page at Fixed Width

Tina Holmboe wrote:[color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> exclaimed in
> <YzAcb.398$Z46. 332@newsfep3-gui.server.ntli .net>:[/color]
[snip][color=blue]
> 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.[/color]
[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/photography/portfolios/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]

Re: Keeping Web Page at Fixed Width

In article <ctUcb.120$ly4. 96@newsfep1-gui.server.ntli .net>,
"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue][color=green]
> > 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).[/color]
>
> 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.[/color]

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]

Re: Keeping Web Page at Fixed Width

Walter Ian Kaye wrote:[color=blue]
> In article <ctUcb.120$ly4. 96@newsfep1-gui.server.ntli .net>,
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
>[color=green][color=darkred]
>> > 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).[/color]
>>
>> 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.[/color]
>
> 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).[/color]

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.
[color=blue]
> 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.[/color]

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?)
[color=blue]
> 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[/color]

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]

Re: Keeping Web Page at Fixed Width

In article <Xnydb.115$ft3. 119207@newsfep1-win.server.ntli .net>,
"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
> Walter Ian Kaye wrote:[color=green]
> > In article <ctUcb.120$ly4. 96@newsfep1-gui.server.ntli .net>,
> > "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
> >[color=darkred]
> >> > 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.[/color]
> >
> > 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).[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
> > My PowerBook *screen* is 91ppi (1152x768), but to the OS it is 72.[/color][/color]

[color=blue][color=green]
> > 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.[/color]
>
> 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?)[/color]

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.
[color=blue][color=green]
> > 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[/color]
>
> 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?[/color]

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]

Re: Keeping Web Page at Fixed Width

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

[color=blue]
> 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...[/color]

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]

Images, vectorials (WAS: Keeping Web Page at Fixed Width)

On Fri, 26 Sep 2003 11:41:46 +0100, in comp.infosystem s.www.authoring.html,
Barry Pearson wrote:[color=blue]
> Salagir wrote:[color=green]
> > 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????[/color]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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?
[color=blue]
> I think the answer for non-photos is SVG, and eventually all browsers will
> support it. Needing plugins is a transitional stage.[/color]

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]

Re: Images, vectorials (WAS: Keeping Web Page at Fixed Width)

Salagir wrote:[color=blue]
> On Fri, 26 Sep 2003 11:41:46 +0100, in
> comp.infosystem s.www.authoring.html, Barry Pearson wrote:[color=green]
>> Salagir wrote:[/color][/color]
[snip][color=blue][color=green][color=darkred]
>> > 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????[/color]
>> 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.[/color]
>
> 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.[/color]

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][color=blue]
> 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?[/color]
[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/