Subject: RE: draft-ietf-conneg-media-features-02.txt; LAST CALL comments

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 11 Nov 1998 11:13:38 -0800

> -----Original Message-----
> From:	Graham Klyne [SMTP:[email-masked]]
> Sent:	Wednesday, November 11, 1998 8:34 AM
> To:	Larry Masinter
> Cc:	conneg WG
> Subject:	RE: draft-ietf-conneg-media-features-02.txt;  LAST CALL
> comments
> 
> At 16:40 10/11/98 PST, Larry Masinter wrote:
> [...]
> >I'm sorry to have misfiled your message, or I would have responded
> >to it before.
> 
> I guessed as much.
> 
> >> >2.1 Image Size
> [...]
> >Graham, the use of pixel sizes to describe screen sizes is
> widespread,
> >and the most useful metric for display applications.
> 
> I feel this is a very display-centric approach to media feature
> description...
	[McIntyre, Lloyd]  I agree.

> [...]
> >> Specifically, when a device offers several different resolutions
> these do
> >> not usually correspond to a change in physical display size
> supported.  If
> >> size is to be measured in pixels, a different size must be
> associated with
> >> each supported resolution.
> >
> >The convenience of representation for multiple possible resolutions I
> think
> >should take second priority to good fidelity representation of the
> >capabilities
> >of the device. Yes, you're right, it's more inconvenient to describe
> >in -algebra- such combinations, but I think this is a difficulty with
> >-algebra-, not a difficulty with the proposed media features.
> 
> I agree that good fidelity representation is the primary goal here.
> But I
> disagree that that has to be sacrificed if image sizes are related to
> some
> physical size.
> 
> Further, I don't see the "inconvenience" as being a problem with the
> algebra:  to me it seems a fundamental property of pixel+resolution
> descriptions in a world where physical dimension is often constant.
> 
> You argue that there are circumstances when physical dimensions are
> meaningless (e.g. displays).  I would argue that there are also
> circumstances when pixel dimensions are equally meaningless (e.g. pen
> plotters, non-raster image data).  Thus, if we choose two out of three
> possible media features (physical size, pixel size, resolution) then
> there
> will be circumstances in which one of the features will be somewhat
> artificial (e.g. a notional screen size, or some notional pixel
> dimension).
> 
> A "compromise" way out of this would be to define both pixel- and
> phyisical- dimensions, and allow an application to choose what it
> uses.
> But I would prefer to find a consensus that satisfies our various
> desiderata without creating duplicate ways to express the same feature
> set.
> 
> One approach I heard about was to use pixels/resolution as a measure.
> I
> like that approach very much, as in the absence of a resolution (the
> natural case for a display image) the value can be interpreted as a
> pixel
> size.  But when known physical dimensions are involved, the value is
> related to those.
	[McIntyre, Lloyd]  This seems very reasonable and is consistent
with the usage in TIFF.

	[McIntyre, Lloyd]  snip ...
> >> >2.2 Resolution
> >> >
> >> >   - Media Feature tag name:
> >> >
> >> >     dpi
> >>
> >> As discussed elsewhere, I would like to see differential resolution
> >> addressed in some way.
> >>
> >> The -fax-schema- draft contains such a proposal, which finds
> general
> >> acceptance in the fax WG.  Should this be part of this "core" of
> media
> >> features, since it is clearly not specific to just fax?
> >
> >This went back and forth in the discussion and in the draft.
> >My impression is that while legacy fax devices have differential
> >resolution in the two dimensions, this isn't actually common.
	[McIntyre, Lloyd]  This is indeed very common in fax. I would
claim that at least 75% of all fax documents are sent at 204x98 dpi
(8x3.85 lines/mm).

	[McIntyre, Lloyd]  Snip ... 

> >> >     color
> >> >     grey
> [...]
> >> >
> >> >     The color capabilities of the recipient are indicated with
> >> >     feature value describing the number of color (or greyscale)
> >> >     channel bits available.
> >>
> >> I would prefer number of levels rather than number of channel bits.
> >>
> >> I believe that the use of channel bits for measuring colour depth
> is too
> >> implementation-specific:  there are devices that offer a number of
> colour
> >> levels that is not an exact power of 2.
> >
> >I know there are a few such devices, but
> >
> >a) they are not common; the goal isn't to capture the exact nuances
> >   of all possible devices, but to simply describe those
> characteristics
> >   that are common. How many color levels are there with 24 channel
> bits?
> 
> Off the top of my head:  about 16 million.
> 
> I feel that in this you are contradicting the point you made
> previously
> with respect to image size when you said "...convenience of
> representation...should take second priority to good fidelity...".
	[McIntyre, Lloyd]  A color representation that does not
accommodate fidelity is of no value.

> I would argue that such display systems are not uncommon:  for
> physical
> devices, there are pen plotters (which is just a physical realization
> of
> palettized colour, so still follow the model used for many color
> display
> systems).  More importantly, I recall from the times when I used to
> program
> Windows GDI interfaces, when using an 8-bit device-independent-bitmap,
> 16
> of the available 256 palette slots are reserved for predefined
> colours, so
> may be effectively unavailable for some image display applications.
> Also,
> on systems that use a hardware palette (such as many PC display
> systems)
> the actual number of colors used might be important to determine
> whether
> two more more separate images can be rendered on the same physical
> display.
> 
> >b) in the cases where there are a small number of color levels, the
> >   characteristics of the device are not sufficiently captured merely
> >   by enumerating the number of color levels. A finer level of
> description
> >   is required. So changing this to "number of color levels" won't
> actually
> >   help without additional attributes.
> 
> This is true to a lesser or greater extent irrespective of the number
> of
> colour levels available.  Hence the proposal noted and posted
> separately
> for dealing with colour representation.
	[McIntyre, Lloyd]  Additional attributes are essential if color
is to be dealt with  in an honest manner.

	[McIntyre, Lloyd]  Snip..

	Lloyd