By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,869 Members | 1,756 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,869 IT Pros & Developers. It's quick & easy.

<div> expands dramatically due to change in font-size property

P: n/a
please see

http://www.geocities.com/operationsengineer1/test.htm

for an idea of how i want my logo header div to be layed out.

when i went to resize "Test" to 2em (from 1em), this is what
happened...

http://www.geocities.com/operationsengineer1/test1.htm

the div expanded to twice the size, too!

this was totally unexpected to me, however, it displays this way in
both ie6 and ff1 so i think it is rendering correctly and i've coded
something incorrectly.

any guidance would be appreciated.

Jul 21 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a
i should say the div expands proportionally to an increase in the
font-size declaration of that div.

at font-size: 1em; everything is great.

at font-size: 2em; there is a double - even outside my "container" div
which houses the logo header div..

Jul 21 '05 #2

P: n/a
"skeeterbug" <js******@san.rr.com> wrote:
http://www.geocities.com/operationsengineer1/test.htm

for an idea of how i want my logo header div to be layed out.

when i went to resize "Test" to 2em (from 1em), this is what
happened...

http://www.geocities.com/operationsengineer1/test1.htm

the div expanded to twice the size, too!


Makes sense. You've told the div to be 6 times the font-size and then
you've doubled the font size.

When a length is defined in em the value of 1em varies on the property
being defined:
For font-size 1em = the font-size of the parent element.
For all other properties 1em = the font size of the current element.

Steve

Jul 21 '05 #3

P: n/a
On 11 Jan 2005 13:26:28 -0800, "skeeterbug" <js******@san.rr.com> wrote:
please see
http://www.geocities.com/operationsengineer1/test.htm
for an idea of how i want my logo header div to be layed out.
when i went to resize "Test" to 2em (from 1em), this is what
happened...
http://www.geocities.com/operationsengineer1/test1.htm
the div expanded to twice the size, too!


Hard to tell really.

Your "strict" doctype declaration will not be picked up by the doctype
sniffers when you serve a page from geocities, so anything that comes
out of that place will be rendered in "quirks" mode regardless of what
you do to try to get it right.

There is no such thing as a free lunch
(or a _free_ www server for that matter :-)

--
Rex
Jul 21 '05 #4

P: n/a

"skeeterbug" <js******@san.rr.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
please see

http://www.geocities.com/operationsengineer1/test.htm

for an idea of how i want my logo header div to be layed out.

when i went to resize "Test" to 2em (from 1em), this is what
happened...

http://www.geocities.com/operationsengineer1/test1.htm

the div expanded to twice the size, too!

this was totally unexpected to me, however, it displays this way in
both ie6 and ff1 so i think it is rendering correctly and i've coded
something incorrectly.


The height of the DIV is 6em, which means 6 times "the computed value of the
'font-size' property of the element on which it is used [i.e., the DIV]." If
you double the DIV's font-size property from 1em to 2em, you've doubled its
computed value, which means you've doubled any value that's defined in terms
of that computed value. In other words: this is the correct behavior.

Jul 21 '05 #5

P: n/a
Jan Roland Eriksson <jr****@newsguy.com> writes:
On 11 Jan 2005 13:26:28 -0800, "skeeterbug" <js******@san.rr.com> wrote:
please see
http://www.geocities.com/operationsengineer1/test.htm
for an idea of how i want my logo header div to be layed out.
when i went to resize "Test" to 2em (from 1em), this is what
happened...
http://www.geocities.com/operationsengineer1/test1.htm
the div expanded to twice the size, too!


Hard to tell really.

Your "strict" doctype declaration will not be picked up by the doctype
sniffers when you serve a page from geocities, so anything that comes
out of that place will be rendered in "quirks" mode regardless of what
you do to try to get it right.


Would you care to elaborate? If naďfely I wget the page, and
look at the first two lines I see:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Where do the "doctype sniffers" sniff?

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

Jul 21 '05 #6

P: n/a
On 11 Jan 2005 22:58:32 +0000, "Jón Fairbairn"
<jo***********@cl.cam.ac.uk> wrote:
Jan Roland Eriksson <jr****@newsguy.com> writes:
On 11 Jan 2005 13:26:28 -0800, "skeeterbug" <js******@san.rr.com> wrote:
>please see
>http://www.geocities.com/operationsengineer1/test.htm
>for an idea of how i want my logo header div to be layed out.
>when i went to resize "Test" to 2em (from 1em), this is what
>happened...
>http://www.geocities.com/operationsengineer1/test1.htm
>the div expanded to twice the size, too!
Hard to tell really.

Your "strict" doctype declaration will not be picked up by the doctype
sniffers when you serve a page from geocities...

Would you care to elaborate?
Sure, this is what the "sniffers" see...

<script language="JavaScript">var PUpage="76001067"; var
PUprop="geocities"; </script>
<script language="JavaScript" src=
"http://www.geocities.com/js_source/pu5geo.js"></script>
<script language="JavaScript"> var thGetOv=
"http://themis.geocities.yahoo.com/themis/h.php";
var thCanURL=
"http://us.geocities.com/operationsengineer1/test.htm";
var thSpaceId="76001067";
var thIP="84.217.65.78";
var thTs="1105479503";
var thCs="2d54c51abf084a05dd92c4abf36a8ffd";
</script>
<noscript>
<link rel="stylesheet" href=

"http://themis.geocities.yahoo.com/jsoff.css?thIP=84.217.65.78&thTs=1105479503">
</noscript>
<!-- text above generated by server. PLEASE REMOVE -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html> ... etc...

I.e. all parts of Geocities crap gets served first, before your doctype
declaration. "Sniffers" wants to find your doctype declaration as the
first line ever...
If naďfely I wget the page, and look at the first two lines I see:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Seems like 'wget' is doing some filtering :-)
Where do the "doctype sniffers" sniff?


Right there at the <!DOCTYPE... thingy, but it has to be the first thing
they encounter, no crap up front that might look like "markup".

--
Rex
Jul 21 '05 #7

P: n/a
skeeterbug wrote :
please see

http://www.geocities.com/operationsengineer1/test.htm

for an idea of how i want my logo header div to be layed out.

when i went to resize "Test" to 2em (from 1em), this is what
happened...

http://www.geocities.com/operationsengineer1/test1.htm

the div expanded to twice the size, too!

this was totally unexpected to me, however, it displays this way in
both ie6 and ff1 so i think it is rendering correctly and i've coded
something incorrectly.

any guidance would be appreciated.


Not sure if this is what you should be considering, but take a look
here anyway....

http://mycoolfish.com/t/thing.html
All the divs are using the same class. They each have been applied the
same text size in /em/

resize the text and see what happens. This behaviour is because they
are each nested and inheret each others parent size.
So... the outermost uses 1.2em of its parent (the body) - 100%. the
first ensted element uses 1.2 em of its parent (which is already using
1.2em of its parent)... and so on.

play around and see what happens when you make the em size 1em, 1.2 em,
and .9em.

All expected results because of the nesting.

This may lead you into reason of the behaviour of your page.

Hope it helps.

--
dance with children in the rain

Jul 21 '05 #8

P: n/a
> Makes sense. You've told the div to be 6 times the font-size and then
you've doubled the font size.
that makes sense aqs you've explained it, but that IS NOT what i was
trying to do. i was trying to make the div 6em - period. well, you
know, at the normal text size in a browser.

i want em so that its size can be adjusted when folks adjust their
browser's text size.

i then want to be code different font-sizes within my 6em div.

i *thought* that is what i did, however, i'm obviously wrong.

i still don't see where i went wrong. can anyone help?

tia...

When a length is defined in em the value of 1em varies on the property being defined:
For font-size 1em = the font-size of the parent element.
For all other properties 1em = the font size of the current element.

Steve


Jul 21 '05 #9

P: n/a
"skeeterbug" <js******@san.rr.com> wrote:
Makes sense. You've told the div to be 6 times the font-size and then
you've doubled the font size.
that makes sense aqs you've explained it, but that IS NOT what i was
trying to do. i was trying to make the div 6em - period. well, you
know, at the normal text size in a browser.


Then make it 3em.

height of element relative to own font size = height of element
relative to default font size / element's own font size relative to
default font size*

3 = 6 / 2

*If there was an inbetween element with font-size 1.2em you would need
to take that into account as well. So instead of dividing by 2 you
would divide by 1.2 because he computed value for the element's
font-size would be 1.2*2 = 2.4 times the browser default.
i want em so that its size can be adjusted when folks adjust their
browser's text size.
How much text will you have in your header? As the font size increases
the text may wrap onto a second line, and then onto a third. In this
case it may spill out of the box you're providing. Instead of setting
a height set a bottom padding.
i still don't see where i went wrong. can anyone help?


Is there something missing from the description I gave and which you
quoted (and Harlan gives the same explanation in more technical
terms.):
When a length is defined in em the value of 1em varies on the
property being defined:
For font-size 1em = the font-size of the parent element.
For all other properties 1em = the font size of the current element.


Steve

Jul 21 '05 #10

P: n/a
Jan Roland Eriksson <jr****@newsguy.com> writes:
On 11 Jan 2005 22:58:32 +0000, "Jón Fairbairn"
<jo***********@cl.cam.ac.uk> wrote:
Jan Roland Eriksson <jr****@newsguy.com> writes:
Your "strict" doctype declaration will not be picked up by the doctype
sniffers when you serve a page from geocities...
Would you care to elaborate?


(thanks)
If naďfely I wget the page, and look at the first two lines I see:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">


Seems like 'wget' is doing some filtering :-)


Strange. I didn't think it was that "clever".

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

Jul 21 '05 #11

P: n/a
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
Jan Roland Eriksson <jr****@newsguy.com> writes:
On 11 Jan 2005 22:58:32 +0000, "Jón Fairbairn"
<jo***********@cl.cam.ac.uk> wrote:
>Jan Roland Eriksson <jr****@newsguy.com> writes:

>> Your "strict" doctype declaration will not be picked up by the doctype
>> sniffers when you serve a page from geocities...

>Would you care to elaborate?
(thanks)
>If naďfely I wget the page, and look at the first two lines I see:
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>"http://www.w3.org/TR/html4/strict.dtd">


Seems like 'wget' is doing some filtering :-)


Strange. I didn't think it was that "clever".


It seems that Geocities is only adding it's junk at the start of the
ile if it detects certain user agents (IE of course and Firefox,
probably some others). When I visited the site with Opera and looked
at the source there was junk at the end of the file but not at the
start.

Presumably wget uses it's own user agent string and doesn't spoof IE?
So it doesn't get the junk at the start of the file.

Steve

Jul 21 '05 #12

P: n/a
steve, thanks. i did exactly that. the strange thing is i was working
on a different layout and was able to adjust my text size in the header
w/o the header changing dimensions. that's why this caught me off
guard.

anyway, i have "case a" and i have "case b," so i guess i just need to
play around with the code and figure out what determines case a and
what determines case b.
when i have time to figure it out, i'll post the answer here.

Jul 21 '05 #13

P: n/a
Steve Pugh <st***@pugh.net> writes:
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
Jan Roland Eriksson <jr****@newsguy.com> writes:
On 11 Jan 2005 22:58:32 +0000, "Jón Fairbairn"
>If naďfely I wget the page, and look at the first two lines I see:
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>"http://www.w3.org/TR/html4/strict.dtd">

Seems like 'wget' is doing some filtering :-)


Strange. I didn't think it was that "clever".


It seems that Geocities is only adding it's junk at the start of the
ile if it detects certain user agents (IE of course and Firefox,
probably some others). When I visited the site with Opera and looked
at the source there was junk at the end of the file but not at the
start.

Presumably wget uses it's own user agent string and doesn't spoof IE?


Yes. If I tell wget to identify itself as mozilla I see all
the rubbish at the start. Ho hum. At least I understand
what's going on now.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk
Jul 21 '05 #14

P: n/a


skeeterbug wrote:
please see

http://www.geocities.com/operationsengineer1/test.htm

for an idea of how i want my logo header div to be layed out.

when i went to resize "Test" to 2em (from 1em), this is what
happened...

http://www.geocities.com/operationsengineer1/test1.htm

the div expanded to twice the size, too!

this was totally unexpected to me, however, it displays this way in
both ie6 and ff1 so i think it is rendering correctly and i've coded
something incorrectly.


how about specifying a width for the <div>?

for example, width:300px;

someone correct me if I'm wrong, but it seems to me if you specify a
width <div> will always be same width regardless of font size..

HTH... Frances

Jul 21 '05 #15

P: n/a
Frances Del Rio <fd***@yahoo.com> wrote:
how about specifying a width for the <div>?

for example, width:300px;

someone correct me if I'm wrong, but it seems to me if you specify a
width <div> will always be same width regardless of font size..


And that's
exactly
the
problem
with using
px to
specify
the width
of a DIV
element.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"If you find yourself in a hole, stop digging." - Will Rogers
Jul 21 '05 #16

P: n/a


Darin McGrew wrote:
Frances Del Rio <fd***@yahoo.com> wrote:
how about specifying a width for the <div>?

for example, width:300px;

someone correct me if I'm wrong, but it seems to me if you specify a
width <div> will always be same width regardless of font size..

And that's
exactly
the
problem
with using
px to
specify
the width
of a DIV
element.


why is it a problem? if you want a <div> to be exactly 200px wide, for
example, why is it a problem setting it to that width? sorry, I don't
understand.. thank you.. Frances

Jul 21 '05 #17

P: n/a
Frances Del Rio <fd***@yahoo.com> wrote:
how about specifying a width for the <div>?

for example, width:300px;

someone correct me if I'm wrong, but it seems to me if you specify a
width <div> will always be same width regardless of font size..

I wrote: And that's
exactly
the
problem
with using
px to
specify
the width
of a DIV
element.

Frances Del Rio <fd***@yahoo.com> wrote: why is it a problem? if you want a <div> to be exactly 200px wide, for
example, why is it a problem setting it to that width? sorry, I don't
understand.. thank you.. Frances


A width that makes sense for the DIV when the font size is 10px may not
make sense when the font size is 20px, or 30px, or...

But in general, the quest to keep everything the same regardless of the
reader's browser configuration is misguided. The goal should be to allow
everything to display appropriately on a wide range of browser
configurations.
--
Darin McGrew, da***@TheRallyeClub.org, http://www.TheRallyeClub.org/
A gimmick car rallye is not a race, but a fun puzzle testing your
ability to follow instructions. Upcoming gimmick car rallye in
Silicon Valley: TRC's 24th Anniversary (Saturday, February 5)
Jul 21 '05 #18

P: n/a
Frances Del Rio <fd***@yahoo.com> writes:
Darin McGrew wrote:
Frances Del Rio <fd***@yahoo.com> wrote:
how about specifying a width for the <div>?

for example, width:300px;

someone correct me if I'm wrong, but it seems to me if
you specify a width <div> will always be same width
regardless of font size..

And that's
exactly
the
problem
with using
px to
specify
the width
of a DIV
element.


why is it a problem? if you want a <div> to be exactly
200px wide, for example, why is it a problem setting it to
that width? sorry, I don't understand.. thank you.. Frances


200px means different things on different displays. On a
100dpi display 200px is 2". On a 1000dpi display (rare, but
not impossible) it would be 0.2". Which is probably not as
big as you intend.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk
Jul 21 '05 #19

P: n/a
On Wed, 19 Jan 2005, Jón Fairbairn wrote:
200px means different things on different displays.
You may need to check the definition of CSS px units.
http://www.w3.org/TR/REC-CSS2/syndata.html#length-units
On a 100dpi display 200px is 2". On a 1000dpi display (rare, but not
impossible) it would be 0.2".
No, it's meant to subtend a fixed angle at the normal viewing
distance, irrespective of the display dpi.

Even MS have a solution - an obscure registry setting, which they keep
rather quiet about.
Which is probably not as big as you intend.


On the author side, that depends whether the designer has actually
learned CSS!

On the browser side, that depends whether the browser designer
actually learned CSS!

In either case, for a personal browsing situation, it's the wrong
choice. But for a collective browsing situation, it might be the best
compromise. If it ever got implemented to specification, I mean.
Jul 21 '05 #20

P: n/a
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
a 1000dpi display (rare, but
not impossible)


First I heard of it, highest resolution screen I know of is 300PPI.
Example of a 1000PPI screen?

--
Spartanicus
Jul 21 '05 #21

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> writes:
On Wed, 19 Jan 2005, Jón Fairbairn wrote:
200px means different things on different displays.
You may need to check the definition of CSS px units.
http://www.w3.org/TR/REC-CSS2/syndata.html#length-units


I'd seen that in the past but forgotten about it.
On a 100dpi display 200px is 2". On a 1000dpi display (rare, but not
impossible) it would be 0.2".


No, it's meant to subtend a fixed angle at the normal viewing
distance, irrespective of the display dpi.


Actually, CSS2.1 says "If the pixel density of the output
device is very different from that of a typical computer
display, the user agent should rescale pixel values.", which
means that it does depend on the display, but not as badly
as my example suggested. (Scaling pixels by non-integral
amounts is generally a bad idea)

Even MS have a solution - an obscure registry setting,
which they keep rather quiet about.
Ah.
Which is probably not as big as you intend.


On the author side, that depends whether the designer has actually
learned CSS!


Hard to do. There are several conflicting documents and
AFAICT no browsers that behave exactly right.
On the browser side, that depends whether the browser designer
actually learned CSS!
That's doubtful, isn't it?
In either case, for a personal browsing situation, it's the wrong
choice. But for a collective browsing situation, it might be the best
compromise. If it ever got implemented to specification, I mean.


--
Jón Fairbairn Jo***********@cl.cam.ac.uk
Jul 21 '05 #22

P: n/a
On Thu, 20 Jan 2005, Jón Fairbairn wrote:
No, it's meant to subtend a fixed angle at the normal viewing
distance, irrespective of the display dpi.
Actually, CSS2.1 says "If the pixel density of the output
device is very different from that of a typical computer
display, the user agent should rescale pixel values.",


It does, yes. This discussion isn't new, of course, so I'll be brief.

I've seen screen dpi values between about 65 and about 140 in
perfectly normal everyday use. The linear ratio of those is more than
2, and that makes a massive difference to the perceived size (text is
a two-dimensional object, so I think it's actually fairer to talk in
terms of area - and then the factor is more than 4 between those
extremes).

Some will say that such differences can be waved away as "not
different enough" in the terms of the CSS specification, but I don't
accept that as being a useful argument.

I've now managed to find that Microsoft URL again:
http://msdn.microsoft.com/workshop/a...ew/highdpi.asp
(Scaling pixels by non-integral amounts is generally a bad idea)


That's true; however, text isn't usually inherently pixel-sized, and
the CSS units are merely guideline numbers which guide the font system
to select an appropriate font and scaling.

If we talk about scaling images, then different considerations apply.
FWIW, I have found that scaling typical photorealistic JPEGs gives
preferable results to displaying them at a very "wrong" size, even if
the scaling factor is not an integer multiple. I won't say that the
rescaling is implemented well in some browsers (obviously it's a
tradeoff between speed and accuracy).

For palette-based cartoon-ish images such as are suitable for GIF and
indexed PNG, scaling by non-integer factors is much more risky, no
argument from me about that.
On the browser side, that depends whether the browser designer
actually learned CSS!


That's doubtful, isn't it?


You said it!

Jul 21 '05 #23

P: n/a
Spartanicus <me@privacy.net> writes:
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
a 1000dpi display (rare, but not impossible)


First I heard of it, highest resolution screen I know of
is 300PPI. Example of a 1000PPI screen?


At time of writing I was thinking of "rare, as in big
diamonds" -- and probably only a research prototype, but
perhaps it's "rare as in hen's teeth". I was thinking of two
examples of high (for the time) resolution displays,
misremembering and extrapolating. The first example is the
HRD-1: [The HRD-1 laser display system (Proceedings of the
3rd annual conference on Computer graphics and interactive
techniques 1976, acm)] which could do 1201 lines (note lines
not pixels: addressability was to ten times that) per inch
onto 148×105mm film, but the projected image (on a 1m wide
screen) was obviously much lower resolution. I don't know
whether any of its successors had a smaller screen.

The second example was from [P-70: a 6.3-Mpixel AMLCD,
MARTIN, R, et al, digest of technical papers society for
information display international symposium, pp704-7, 1993]
3072x2048 on a fairly small screen. I remembered it as being
comparable to a printer, but printers back in 1993 weren't
up to today's standards, hence the confusion.

It's been thirty years since HRD-1 was built and it's 12
since P-70, so it's rather disappointing that there aren't
really high resolution displays around by now. So, no, no
example, though I think there /ought/ to be a research
project somewhere working on composing images from an array
of micromirror chips onto a single screen even if there
isn't -- I stand by the "not impossible" part.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

Jul 21 '05 #24

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> writes:
On Thu, 20 Jan 2005, Jón Fairbairn wrote:
No, it's meant to subtend a fixed angle at the normal viewing
distance, irrespective of the display dpi.
Actually, CSS2.1 says "If the pixel density of the output
device is very different from that of a typical computer
display, the user agent should rescale pixel values.",


It does, yes. This discussion isn't new, of course, so I'll be brief.

I've seen screen dpi values between about 65 and about 140 in
perfectly normal everyday use. [...]

Some will say that such differences can be waved away as "not
different enough" in the terms of the CSS specification, but I don't
accept that as being a useful argument.


Neither would I, though what browsers do is another issue. I
think my main quarrel with CSS in this respect is the names
for the units. "Pixel" has a precise normal meaning, as does
"mm". Neither normal meaning is much use for
displays. Since the visual angle is what matters for most of
these things, a unit that reflected that (and is named to
reflect that) would be a better choice. To invent two
plausible ones on the spur of the moment:

The vid, a visual degree: the width on the screen that
subtends an angle of one degree at the eye. Only useful with
non-integer multiples.

The mumal, a micrometre at arm's length, a more "human"
sized unit. Define a standard arm's length as 0.75m, then
1000mumals is a width on the screen that subtends the same
angle at the eye as 1mm 0.75m away.

Those definitions are somewhat tongue in cheek (and people
who work in the area perhaps already have better units), but
for future CSS to get away from absolute units would be a
Good Thing.
I've now managed to find that Microsoft URL again:
http://msdn.microsoft.com/workshop/a...ew/highdpi.asp


Hmm. The content of this document begins "The terms pixel
and dot are used interchangeably", which doesn't inspire
faith. My laptop is 100 dots per inch horizontally and
vertically but only 33 pixels per inch horizontally.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

Jul 21 '05 #25

P: n/a
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
Hmm. The content of this document begins "The terms pixel
and dot are used interchangeably", which doesn't inspire
faith. My laptop is 100 dots per inch horizontally and
vertically but only 33 pixels per inch horizontally.


Except in a context where it is necessary to distinguish between a
cluster of 3 rgb colour dots/pixels and the individual colours of that
cluster, a pixel refers to a 3 colour cluster, not an single
monochromatic colour dot/pixel.

How did you arrive at the 33 pixels per inch conclusion?

--
Spartanicus
Jul 21 '05 #26

P: n/a
Spartanicus <me@privacy.net> writes:
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
Hmm. The content of this document begins "The terms pixel
and dot are used interchangeably", which doesn't inspire
faith. My laptop is 100 dots per inch horizontally and
vertically but only 33 pixels per inch horizontally.
Except in a context where it is necessary to distinguish between a
cluster of 3 rgb colour dots/pixels and the individual colours of that
cluster, a pixel refers to a 3 colour cluster, not an single
monochromatic colour dot/pixel.


That was the point I intended to make. I'm not running any
subpixel antialiasing, so each pixel being three dots is
academic, but if I were, the distinction between dots and
pixels would matter.
How did you arrive at the 33 pixels per inch conclusion?


By getting the arithmetic wrong... I meant 300dpi and
100ppi. Not my day for versimilitude, is it?

--
Jón Fairbairn Jo***********@cl.cam.ac.uk
Jul 21 '05 #27

P: n/a
"Jón Fairbairn" <jo***********@cl.cam.ac.uk> wrote:
Except in a context where it is necessary to distinguish between a
cluster of 3 rgb colour dots/pixels and the individual colours of that
cluster, a pixel refers to a 3 colour cluster, not an single
monochromatic colour dot/pixel.


That was the point I intended to make. I'm not running any
subpixel antialiasing, so each pixel being three dots is
academic, but if I were, the distinction between dots and
pixels would matter.


I'm used to referring to dots and DPI for printers, and pixels and PPI
for screens. Using the phrases "dots" and DPI for screens seems an
invite to confusion.

--
Spartanicus
Jul 21 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.