[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Chartrans patches impressions..
Re: LYNX-DEV Chartrans patches impressions..
Tue, 4 Mar 1997 21:51:35 +0100 (MET)
On Sun, 2 Mar 1997, Klaus Weide wrote:
> If you mean that the other lynxes would refuse to display the document and
> offer a download prompt instead - they don't do this if the charset is
> specified in a META tag (instead of the real HTTP headers). Just to
Agreed. This was the case when the server sent
> The following should currently work (using -assume_charset and '@' in
> combination): Your display (C)haracter set is set to "ISO Latin 2".
> Start lynx with lynx -assume_charset=windows-1250 ..., then when you use
> '@' it should toggle between "assume unlabelled is iso-8859-1" and
> "assume unlabelled is windows-1250".
It works fine with -assume_charset=windows-1250.
I tried -assume_charset=ISO-8859-2, which didn't work, ISO-8859-1 was
assumed, so I wrote that -assume_charset doesn't work.. After some
experiments I found out that the -assume charset flag works only when the
Display and Assumed charsets differ. If they don't, ISO-8859-1 is assumed.
Was this meant to be so?
> I don't think putting them in lynx.cfg for system administrators would be
> a good idea. The system administrator should not have any business of
> setting charset defaults (and thereby, indirectly, language defaults)
> for what his/her users browse on *remote* systems.
I don't agree with you here. If the sysadmins don't set there anything
reasonable, the users won't be able to read the documents with right
accents (because the documents aren't marked etc.). They aren't able to
read cyrillic/chinese/hebrew/whatever by now anyway (we don't have the
fonts etc), so it wouldn't limit them any more than they are limited now -
it would just help them to see the documents in Eastern european (read:
> > Charset: iso-8859-1 (assumed)
> Ok, this needs an explanation...
> What I have written in the README.chartrans file is
> - The "Raw" toggle (from -raw flag, '@' key, or Options screen)
> o [...]
> o otherwise toggles the assumption "Default remote charset is same
> as Display Character Set" on or off.
> What I haven't documented anywhere is the following:
> o IF a document's charset is unlabelled, and the charset to assume
> for unlabelled documents (via -assume_.. flag) is already the
> same as the selected display (C)haracter set (so that toggling "Raw"
> as described above wouldn't make any difference),
> THEN toggling "Raw" means switch between
> - assume unlabelled docs are what -assume_... and display (C).s. says
> - assume unlabelled docs are the default of defaults, i.e. iso-8859-1.
> You see, there was this '@' key that would otherwise have no effect under
> those circumstances. And I thought It would be useful to toggle
> between those two states, without leaving lynx or changing -assume_...
> The result is that
> - if you have -assume_charset=iso-8859-2 AND display (C).s. = ISO Latin 2,
> you should also have -raw for unlabelled iso-8859-2 docs (or use '@').
> - the behaviour w.r.t. "Raw" on/off is then the same as it was without
> chartrans code.
> Whether this is a good idea is up for discussion...
Well.. I don't think so. I use the -assume_charset flag to override the
assumption that the document is in ISO-8859-1, because of the many
unmarked documents that are in ISO-8859-2 or Windows-1250. Why this
shouldn't work when the assumed charset is the same as my display Charset?
> Yes, translation of all thoses strings where it is needed is not in place.
> But some testing reveals:
> flags TITLE OK '=',history,'V' etc. OK
> (nothing) NO NO
> -raw YES YES
> -assume_charset=iso-8859-2 NO NO
> -assume_charset=iso-8859-2 -raw YES YES
> -assume_charset=windows-1250 YES NO
> -assume_charset=windows-1250 -raw YES YES
> -assume_local_charset=windows-1250 YES NO
> -assume_local_charset=windows-1250 -raw YES YES
> -assume_local_charset=iso-8859-2 NO YES
> -assume_local_charset=iso-8859-2 -raw YES YES
> Confused now? Well I am..
Who wouldn't be. :-)
> The -assume_local_charset comes into play because lynx creates
> temporary files for '=', history list, 'V' etc. screens and then reads
> them in.
OK, it works fine with -assume_local_charset.
BTW, why not to set -assume_local_charset to the one we got by
-assume_charset? Do we even need a local charset in this stage, when
without correct local_charset we don't have right "global" documents?
Hynek Med, address@hidden
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.