Do you mean an easy way to set point sizes for a web site /or/ to deconstruct what choices they have made?

I guess the question is: How to reconstruct the styles and sizes used from a page of bits? First, you can answer the question, how tall is the EM either by typing an H and a return and an H with 0 leading, or count pixels from baseline to baseline any way you can. If you are working on the Mac, (72 dpi), your pixel count is the same as your point size, (or close enough). If not, your formula is: Pixels per Em = resolution/72 X points and you can rearrange it several ways depending on the variable you’re seeking…but because Nearly all fonts on all Windows driven screens are fractional point sizes, type is only approximately a point size there.

Click on the line of type and look in the Typesize format field of your App.

ChrisL

The question, and answers so far, seem to ignore the fact that web text generally isn’t, and shouldn’t be, specified in points, which are a “real world” physical measure.

The actual size of text you see is affected by your own display resolution (72dpi is a bit of a myth by the way) and your browser view settings.

If you need to specify web text size absolutely, rather than relative to the user’s base size (em), you’re better off doing it in pixels (px).

If it is a web page, view the page as code (source). If you are lucky and they have inline formatting, you might see a size but it will not relate to points very well. If they use a style sheet as they should, it may not even be available to you.
The big wiz is that browsers, monitors, video cards, and system configurations vary all over the place. Typographic point size is meaningless on the web. The best you can do is count pixels and that only works for one set-up. Set your monitor to a higher rez and it is out the window. This is why controlling typography on web sites is such a royal pain to attempt.

ChrisL

I am not sure yiou can reconstruct perfectly it without testing - but if you want to know the answer for sure & quickly and you have access to the site you can look up their CSS and see exactly what was used.

…and at least that way, you can tell whether they attempted/intended to set the size in points, or by pixel, “smaller-small-large”, percentages or whatever…

Ever since I chose to block pop-ups, my toaster’s stopped working.

> you can tell whether they attempted

Which explains MUCH more than looking at the screen capture and is certain. Whereas pixel counting is less precise/sure.

Or you could just look at the capture & dink with your CSS until you get the same result.

Bruce,

Do you know how to access the CSS?

” (72dpi is a bit of a myth by the way)”
Yes. All screen resolution, and point size(s) there put, is/are a bit of a myth, but there are always ways of turning the mythical sizes into a number of actual pixels, and, unless there is a .5000000 remainder no longer in evidence, actual pixels can be turned into mythical points, through the mythical resolution, be it Mac or WinTel.

If you want to blow away the myths, you *just* need to measure, with a ruler, the actual area occupied by a screen’s full capacity, then use the “Displays” control panel or its kin, to get the pixels displayed across and down, e.g. 1600 x 1024, dividing that into the measure you just made and you have the actual dpi. THEN, you need to know the dpi being used by the OS, and the number of points the OS thinks there is in an inch, and then you can figure out, depending on whether you’re looking for pixels or points, what’s what, including, if you can, specifying a fractional point size that wil get you an ACTUAL, e.g. 12 pt.

The part(s) that cause(s) the mythic shroud is that the OS does not know the actual size of the screen(s)’s writable area(s), and the device manufacturers lie about resolution. This issue was almost solvable at Apple until another choice was made, and MS, (where the myth of point size is additionally murked by a resolution guaranteed to leave remainders, and as unruly a herd of device makers as is possible), was lobbied to improve this in Longhorn coming, but they only got to 1/2 of it.

The results of this are a sad lack of truth to the terms “actual size” and “100%”, not to mention, 10 point, but ‘eh’, you can’t have it all…

Quark is the only graphics application I know in which you can tell the app what your actual screen resolution is to get real 100% views (any others?). Should be more common - Acrobat particularly should have this. I know a few browsers, like Firefox, allow you to switch between the 72dpi Mac and 96dpi Windows standards. (I guess strictly rather than dpi the measure is pixels per nominal text inch)

It will be much more of an issue when display resolution increases significantly.

When I said 72dpi was a myth I had in mind 2 issues:

(1) it’s too often used when it really isn’t relevant, for example the old chestnut of scanning an image at 72dpi because it’s for on screen use

(2) all the displays I’ve used in the last few years have been closer to 90dpi anyway.

I’m still not sure what the actual question is.

you have the actual dpi

PPI. DPI is a print measurement, PPI is the density of pixels in a display…what you are actually measuring.

THEN, you need to know the dpi being used by the OS

The OS doesn’t use a DPI. It just cares about the number of pixels. A browser will use an arbitrary DPI conversion, though, for renderin type spec’d in a print measurement. These days, that’s typically 96PPI on both Macs and PCs.