RE: px vs. pt

> > > > For reference, the units are defined as being:
> > > > 1pt == 1/72 inch (device independent for physical size)
> > > > 1px == 1 pixel   (device dependent for physical size)
> > > 
> > > (No - see the belowcited URL)
> > 
> > I think you'll find that's how they're defined in the CSS 1 spec as:
> 
> [snip]
> 
> Quite possibly, but as explained at that URL, 1pt is not
> device-independent, because the computer does not know what an inch is,
> and therefore uses an arbitrary conversion factor, such as 72ppi. As I
> explained there, whereas 1pt is 33% larger at 96ppi (e.g., Windows) than
> 72ppi (e.g., Mac) at the same resolution, 1px is the same on both
> platforms.

> > > I disagree strongly - see
> > > http://richinstyle.com/masterclass/lengths.html
> > 
> > Pretty, but it is flawed by the fact you're example was/is using large
fonts
> > on a resolution intended for small fonts...
> 
> What?
> Why?
> How do you know?

Because your UA was assuming a screen resolution of 96dpi, which is used
when the "large fonts" option is selected by the user in the Display
Properties on the windows client.

I tested, btw.

AFAIK, UAs rely on the same setting that wysiwyg text editors (eg. Word) use
for computing font sizes, so you'd have to log a bug against them for
displaying 'incorrect' font sizes...
 
Your line of argument purely states that OSs don't report the real physical
DPI rating (because the monitor doesn't return it's physical size to the OS
in a readable form)

> > The size of a pixel is only *suggested* so cannot be guaranteed:
> > "Pixel units...are relative to the resolution of the canvas, i.e. most
often
> > a computer display. If the pixel density of the output device is very
> > different from that of a typical computer display, the UA should rescale
> > pixel values. The suggested reference pixel is the visual angle of one
pixel
> > on a device with a pixel density of 90dpi and a distance from the reader
of
> > an arm's length. For a nominal arm's length of 28 inches, the visual
angle
> > is about 0.0227 degrees"
> 
> That's actually irrelevant.
> 
> See:
> http://lists.w3.org/Archives/Public/www-style/2000Jan/0196.html
> http://lists.w3.org/Archives/Public/www-style/2000Jan/0199.html
> and also the rest of the thread and its ancestor thread(s).

My point was that the spec only gives a recommendation on what size to
render it, as apposed to stating that when dealing with pixels, resolutions
out of the range 70->100 dpi should be scaled as close as possible to fit
within that range.
That's purely something I've thrown up off the top of my head though...

> > > (Unfortunately most WYSIWYG tools do to - products such as Dreamweaver
> > > and all Microsoft products use points).
> > 
> > They transfer to print nicely like that...
> 
> Just a shame about the overwhelming majority of people using screens -
> eh?

So why bother with support for paged media in CSS? My original point was for
the "best for all situations" solution, for which I think points are pretty
useful, and familiar to a lot of people starting up with webdesign from use
in word processors (which suffer the same inaccuracies for screen
scaling)...

> And also, on a point of fact, pixels do translate well to print, since
> they are rescaled (printers, unlike computers, have the required
> information to do the necessary rescaling).

Well, technically the printer doesn't know that much, it's some nice clever
scaling either by the OS subsystems (Eg: Win GDI, which allows you to
specify canvases in all sorts of measurement units), printer driver or even
the UA (printing to Windows canvas in pixel mode doesn't "auto scale" for
you)

> > IMHO, physical sizes should be used for root elements, and relative
sizes
> > (in em or ex) for all the others...

> I hope not. This is the height of rudeness on the part of the designer -
> by doing this he maximises the problems, causing difficulties reading
> for the greatest number possible. To counter this it would be useful if
> browsers did proper rescaling of fonts (zooms are unsatisfactory):

Would you like to back that up?
72pt is 72pt is 6picas is 1 inch is 25.4mm is 2.54cm is...
Next, you'll be telling me that they are no WISIWYG word processors because
they're all scaled incorrectly...

> user without perfect sight sets font size in browser; e.g., 20px
> user enables 'rescale fonts' option

> Example:
> rude developer creates page with font size of (say) 9pt. 
> Browser rescales font size to 20/16 * 9 * 96/72 = 15px. 
> Result: all accessibility problems caused by lazy/rude developers
> disappear, and without the need for an annoying zoom feature (i.e. it's
> automatic)

I don't follow your argument in your example... Especially in a debate over
choice of units: px vs. pt

> [Note there could be an 'advanced' dialogue box, where the figures I
> suggest here (default font size, in pixels, of developer's computer (16)
> and ppi value for that computer (96), which represent what most
> developers/WYSIWYG editor makers use, could be changed.]

Under Win systems: Control panel -> Display properties -> Settings -> Font
size (small = 72 dpi screen res, large = 96dpi screen res)

> In fact, to rebut your suggestion, no size at all should be used for the
> root element, and relative sizes for all others. By using no size for
> the root element, you respect the user's wishes as to size, rather than
> inflicting upon them a size that is smaller than they an read. (BTW,
> please read the page: exes are a BAD idea for font sizes.)

I forgot percentages (sorry), which is what I would suggest for font sizes,
reserving em and ex for things like padding, margins etc.

Received on Thursday, 27 July 2000 08:09:12 UTC