TMG-L Archives
Archiver > TMG > 2005-06 > 1117930071
From: "John Davis" <>
Subject: Re: [TMG] Picture sizes & font point size in HTML output from TMG (6.0)
Date: Sat, 4 Jun 2005 17:09:16 -0700
References: <003601c56888$8fc74790$2a0c1fac@jfc> <5.1.1.6.2.20050603163952.00aa1cc0@mail.umich.edu> <003601c56888$8fc74790$2a0c1fac@jfc> <5.1.1.6.2.20050604120516.00a668d0@mail.umich.edu> <6.2.1.2.2.20050604120309.02ec6238@popd.ix.netcom.com>
Thanks Dennis,
I really appreciate it when someone with the ability steps forward with
one of these "boiling it down & summing it up" explanations. I've copied
this to my collection of "insights, why-for's and how-to's" related to
TMG & Second Site.
We all have our own experiences and training to bring to the table.
Having done my fair share of light programming, technical writing,
manual writing, instruction and developing SOP's in a manufacturing
setting, I can even better appreciate it when someone with expertise in
a certain area takes the time to reduce it down to the layman's level,
put on their instructor's hat, and share.
Keep it up, and this includes all of you who are so willing to help. I'm
really thankful for this forum.
I hope kudos aren't considered too far off-topic.
John Davis
Elgin, Oregon
Researching Davises, Corns, Fosters, Shields and who knows who all else.
----- Original Message -----
From: "Dennis Lee Bieber" <>
To: <>
Sent: Saturday, June 04, 2005 12:31 PM
Subject: RE: [TMG] Picture sizes & font point size in HTML output from
TMG (6.0)
> On or about 6/4/2005 09:17 AM a carrier pigeon from David S. Flower
delivered:
>
> > pixels, DPI ... have always been confusing to me.
>
> Pixel Picture Element smallest representable piece
of
> information in the image
>
> PPI Pixels Per Inch Number of Picture Elements
per
> inch of rendered display
>
> LPI Lines Per Inch From half-tone print
industry,
> number of half-tone "cells" per inch of rendered display
>
> DPI Dots Per Inch Hardware capability, smallest
> physical mark the device produces
>
> For color image scanners: DPI == PPI (one scanner dot
> produces full color range in one Pixel)
>
> For full color mode monitor displays: DPI == PPI (this
ignores
> the phosphor dot pitch factor -- I'm referring to the video driver
> resolution, not the phosphor on the glass, since you need three
phosphor
> dots (RGB) at minimum to produce a pixel)
>
> For color printers: DPI <> PPI <> LPI Color
> printer "dots" are bistate: On or OFF, no middle levels. As a result,
> producing any shade outside of (I'm using pure CMY for this example)
[white
> [paper]], Cyan, Magenta, Yellow, [Red [M+Y]], [Green [C+Y]], [Blue
[M+C]],
> [Black [C+M+Y]] requires using dither patterns where some dots are
off, and
> others are on. To produce a 256(7)-level grey scale requires being
able to
> go from no-dots-on to 256-dots-on. Such requires the use of a 16x16
square
> of printer dots. Divide the printer DPI (most photo printers are
720-2880
> depending on mode) by 16 to obtain the effective half-tone LPI. Common
> practice is for the source image PPI to be 2x the LPI (1.5x to 2.5x).
> Anything less may show artifacting (abrupt edges) and anything more is
data
> that the rendering engine has to throw away when setting up the print.
>
> 300PPI is commonly considered "photo-grade" (National
Geographic,
> for example). This translates to a 150LPI, or 2400DPI printer (using
CMYK).
>
> Photo inkjets can produce high quality at somewhat lower
LPI/PPI
> because of extensions: Some claim to dynamically vary the dot size (a
> Dye-Sublimation printer with 256 "pulse" levels means a 300DPI is the
same
> as 300PPI). Others have added "half-shades" (6 and 7 color printers
> CcMmYK(k) ), so again can produce a half intense smooth area at a
lower LPI
> (instead of using a box of half on, half off, they can use a single
> half-intense dot).
>
> The end result of all this is that an image meant for print
use is
> not suited for use on a web page.
>
> If you intend the web page for some minimal equipment level
> (800x600 resolution), you should probably limit your images to
720hx520v
> pixels (720x480 is common for digital video at NTSC format). 720x520
allows
> for 80 pixels to be used by the browser status bar, menus, scroll
bars...
> when the browser is full screen on an 800x600 display (it would only
be
> quarter screen on my current display 1600x1200).
>
> This same image, if sent to a photograde printer, would
optimize
> at 2.4x1.73 inches.
>
>
> >Thanks again,
> >
> > Dave Flower
> >
> >
> >==== TMG Mailing List ====
> >To un-subscribe from TMG-L (in MAIL mode), send a message to
> ><> [to <> in
Digest
> >mode] with just the word "unsubscribe" (no quotes)in the text and
turn off
> >your signature.
>
> --
> > ============================================================ <
> > | Wulfraed Dennis Lee Bieber KD6MOG <
> > | Bestiaria Support Staff <
> > ============================================================ <
> > Home Page: <http://bieberd.home.netcom.com/> <
>
>
>
> ==== TMG Mailing List ====
> Send all messages and replies to <>.
>
>
This thread:
| Re: [TMG] Picture sizes & font point size in HTML output from TMG (6.0) by "John Davis" <> |