W3C home > Mailing lists > Public > www-international@w3.org > October to December 1996

Re: Accept-Charset support

From: Martin J. Duerst <mduerst@ifi.unizh.ch>
Date: Thu, 5 Dec 1996 11:19:02 +0100 (MET)
To: Chris Lilley <Chris.Lilley@sophia.inria.fr>
cc: erik@netscape.com, Alan Barrett/DUB/Lotus <Alan_Barrett/DUB/Lotus.LOTUSINT@crd.lotus.com>, www-international <www-international@w3.org>, bobj <bobj@netscape.com>, wjs <wjs@netscape.com>, Ed Batutis/CAM /Lotus <Ed_Batutis/CAM/Lotus@crd.lotus.com>
Message-ID: <Pine.SUN.3.95.961205110822.279A-100000@enoshima>
On Wed, 4 Dec 1996, Chris Lilley wrote:

> On Dec 4,  1:19pm, Erik van der Poel wrote:
> > Chris wrote:
> > > Erik wrote:
> > > > This
> > > > would omit the "q" parameter, but I'm not sure this is needed in the
> > > > Accept-Charset case anyway.
> > >
> > > Since this would be a new representation, one could also add a
> > > requirement that the charsets in such a binary representation are
> > > sorted in decreasing order of q.
> >
> > Do we really need the "q" in the Accept-Charset case? What does it mean?
> 
> Well, a charset with a high q factor would be preferred, for example it
> might be the native charset on the browsers platform and require no fancy
> processing. A low q factor would indicate, I can accept this if it's all
> you have got, but then I need to futz with all those escape sequences and
> convert the document to another form internally.

Conversion, e.g. from escape sequences, is really not a big deal.
Either it is implemented, or it is not. It does not take much time
compared to all the rest that has to be done.
What is more appropriate are cases where conversion cannot be
complete, i.e. where a browser would decide to use character
combinations to represent single characters, or would have
to represent some characters as "undisplayable character" icons,
and so on.
However, if one has a realistic look at the above, conversion
of single characters (e.g. Latin with diacritics) to character
combinations is not very popular now and probably will not take
off (it is easier to supply a font with more glyphs than to
implement the conversion). Also, the main place for undisplayable
characters is stuff comming in as Unicode. In this case, you
might say that because you can render 20% of the characters
in Unicode, you give it a quality factor of 0.2. But that will
give the rather wrong impression that e.g. you are better able
to display a Japanese document if you get it in Shift-JIS
than if you get it in Unicode. With highest probability, this
is not true: You will be able to render all the JIS characters
in Unicode.

The above considerations seem to indicate that although "q" on
Accept-Charset might have some marginal use, in general it should
be left out.

Regards,	Martin.
Received on Thursday, 5 December 1996 05:19:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:16:46 GMT