Re: style sheet scalability (was: Specifying style notation in <link>)

H&kon wrote:
 
> Walter Ian Kaye writes:
> 
>  > Can an IMG have a "note" attached to indicate (1)its intended dots per
>  > inch, and (2)whether non-integral (i.e., other than 100%, 200%, 300%...)
>  > scaling should be allowed?

> 1) any element can have a suggested width [...]
>    Using a width property is more general than dpi which is only
>    useful for images.

But images were the original subject of enquiry.

>  > My 72dpi title graphics come out "tiny" (so I'm told) on 100dpi monitors,
>  > and I'm wondering if there's any way to keep bitmaps and text more in sync
>  > with each other.
> 
> The "magnification" property will help here. By changing one property,
> the user (or author) can scale all length properies by a certain
> factor. 

But this will keep the too-small or too-large images in synch with the
text as the magnification factor is altered.

Lets separate out several issues here:

a) Methods of rendering of inline images
b) The commonly implemented subset of a) used by current browsers
b) How stylesheets might/should give more control over b)

Most images are rasterised, ie consist of pixels.  However, the IETF
considers "image" to mean "2D picture" so for example CGM (which is a
resolution independent vector format) was registered as image/cgm

Using this definition for now, vector images can be rendered at any 
desired size. 

Raster images are rendered by defining some maping between each pixel of
the display area and the pixels of the raster image.  At it's most
complex, this involves a full decimation and resampling filter which
maps a frequency-domain filtered version of the raster image onto the
display.  This computationally intensive process gives the best results.

Simpler than that is bicubic or bilinear interpolation where each
display pixel will be made up from a contribution of several image
pixels based on fractional coverage.  Bicubic interpolation is better
than bilinear for blowing up a small image with less visible pixelation
(Photoshop uses bicubic interpolation).

Simpler than that is pixel replication:  for the centre of each pixel on
the display, find the corresponding pixel in the image and use that
color.  This gives very visible pixelation and will destroy the
legibility of small type, for example.  This method is used by all
browsers that I have seen which do image resizing.  It gives rather less
ugly results if the scaling factor (displayed image width in pixels /
original image width in pixels) is an integer.

The simplest and fastest method is the 1:1 mapping; one pixel on the
display maps to the corresponging one pixel on the image, so as the
display density goes up the displayed image size goes down.  This is the
default presentation of all browsers that do not do image scaling.  It
maintains graphic quality (and speed) at the expense of device dependent
size.  This is made more noticeable by the fact that browsers tend to
compensate for differences in display density when choosing bitmapped
typefaces.

Some image formats, such as TIFF and PNG, can give the desired display
dimensions of an image (and by implication, the number of pixels per
inch).  Should this size be honoured?

I would say no, if the browser is going to do a quick and dirty
rescaling job and mess up the image.  (Then again browser do quick and
dirty colour reduction jobs and further screw up the image quality, so
why not?)

On the other hand, if the colour depth is adequate and there is enough
CPU power and the user likes decent quality images then sure, resample
and display at the specified physical size. 

(This can be done as a separate pass after all the text and images are
displayed.  CPU is then pretty much idle while the user is reading.
This is the time to find an optimal palette, do high quality resampling,
pair kern your headings, and so on).

Some output media are required to resample, because their display
density or colour depth are greatly different from a screen display.
For example a 300dpi dye-sub printer is physically able to use a 1:1
mapping but the inline image would be tiny indeed.  A monochrome 600dpi
laser printer is also forced to resample, because each display pixel can
only be black or white.

The late lamented HTML 3.0 draft, the EMBED draft (I think) and the CSS
draft, give the possibility of over-riding the display size into which
an image is to be rendered.  The same considerations then apply.

What Walter seems to be asking for is control over how much a browser is
allowed to destroy his images ;-) for example by requiring only integer
scaling (if scaling is done by pixel replication).  If it was using a
better scaling method, though, the browser could get even better results
and still use non-integer scaling factors.

What seems to be needed is a means of specifying the fragility or
importance of the image.  Some images of mine, for example, I don't want
scaled at all; some images really need 24bit display to see the fine
detail or the differences between two very similar images.

Perhaps we could explore what information we want to express about
inline images, then we can find out what properties wil allow us to
express our intent.

-- 
Chris Lilley, Technical Author and JISC representative to W3C 
+-------------------------------------------------------------------+
|       Manchester and North HPC Training & Education Centre        |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: Chris.Lilley@mcc.ac.uk |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
| Timezone: UTC        URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | 
+-------------------------------------------------------------------+

Received on Tuesday, 5 December 1995 07:52:36 UTC