- 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>
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 UTC