lynx-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV did something happen to <img alt="xxx"> ??

From: Klaus Weide
Subject: Re: LYNX-DEV did something happen to <img alt="xxx"> ??
Date: Sat, 4 Oct 1997 02:35:05 -0500 (CDT) 
On Sat, 4 Oct 1997, Nelson Henry Eric wrote:

> >    alt="some string with ISO-2022 shifting"><p>
> 
> Please send me the string you fabricated.  It might be worth testing
> in my environment.

Find it in <URL: http://sol.slcc.edu/~kweide/nhealt.html>.
As far as I know, that is byte-by-byte what you sent.

> > on that file with various versions of lynx.  I am just using less
> > as a convenient way to "see" the bytes; the alt text becomes
> > <B6><E1><B5><A6><C2><E7><B3><D8><A1><DD><C0><D6><CE><FB>
> > <B4><A4><A4><CE><C0><B5><CC><E7>
> 
> I don't know how to get this kind of output; sorry.

I want to see:

       BYTES, not CHARACTERS.

When you try to show me (and the rest of the list) what some output of
lynx "looks like", you have to find some way to let us see exactly the
bytes which lynx outputs.  That also applies to the input you feed it.

Put it on a http server, uuencode your mail, or something else.
The way you are sending your examples, the strings you include go through
some transformation which neither I nor (I am afraid) understand (or are
aware of).

Try a few flags for most: -b and -k.
Or try piping through: od -c
Also try setting your locale to "C" or "POSIX".
(Try setenv LANG and/or LC_ALL to one of those values.)

> > I didn't find any difference between different versions of Lynx.
> > Do you?
> 
> Yes; see the results below.  Perhaps it will provide some kind of
> hint that stdin read by most is different from the -dump redirected
> to a file only in the case of ac-0.74.  Both of the strings are
> wrong.  Both ac-0.60 and 2-7-1+fmods give the correct string, either
> way the dump is read.
> 
> > It is more important what lynx.cfg and .lynxrc have.
> 
> Don't have anything to do with charset in lynx.cfg.  .lynxrc has
>      display (C)haracter set      : Japanese (EUC)
>      Raw 8-bit or CJK m(O)de      : ON
>      preferred document lan(G)uage: ja,en
>      preferred document c(H)arset : ISO-2022-JP

Ok.  (The "preferred" options shouldn't make any difference, unless you
are loading the file from a HTTP server which does content negotiation.)

> > Does the charset of the file containing the string matter?
> 
> Not sure what I need to do for you here.  Do you want me to put
> a META tag in the document?  Spell out exactly what I should do.

Yes, that's what I meant - try to put a META HTTP-EQUIV="Content-type" ...
in there.  It shouldn't make a difference, but just to make sure.

> __Henry
> 
> (No one uses alt="" in Japan :(, so I'm hard pressed to find
> examples that you wanted.)

Just make some for testing - any short Japanese text.  So far we don't
even know whether ALL strings are messed up for you or wheter all but
one are OK.  Also test what happens to exactly the same string it it is
not in an ALT attribute value but in the normal flow of text.

> results of test of:
>       <html><body>
>       <img align=left width="340" height="100" src="kinda.gif"
>        alt="$B6a5&address@hidden@5Lg(J"><p>
>       </body></html>
> 
> 
> ************** lynx2.7.1ac-0.74: "-dump | most" (then cut-n-paste display)
> 
>    
> [1]$BB6C!B5B&(J~^B$BC'B3(J~^X$BB!(address@hidden;B4B$B$(address@hidden(J~^L$BC'(J
> 
> ************** lynx2.7.1ac-0.74: "-dump >> thisfile"
> 
>    [1]$BB6C!B5B&CC'B3CB!CC   

And none of these agree with what you sent in the first mail :-(

> ************** lynx2.7.1ac-0.60: "-dump | most" (then cut-n-paste display)
> 
>    [1]$B6a5&address@hidden@5Lg(J
> 
> ************** lynx2.7.1ac-0.60: "-dump >> thisfile"
> 
>    [1]$B6a5&address@hidden@5Lg(J
>    
> 
> ************** lynx2.7.1 + fotemods [97/07/05] "-dump | most" (then 
> cut-n-paste)
> 
>    [1]$B6a5&address@hidden@5Lg(J
> 
> ************** lynx2.7.1 + fotemods [97/07/05] "-dump >> thisfile"
> 
>    [1]$B6a5&address@hidden@5Lg(J

This isn't very useful for diagnosis (at least for me, no doubt someone
understanding Japanese encodings better could make a guess what happened).
Something has encoded the bytes into ISO-2022 escaped sequences and
(prrobably) dropped the high bits on the way.  Your mail client, a mail
transfer agent, your cut-and-paste procedure - who knows.
The same may or may not happen to the HTML fragment you show as your
input.

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;
reply via email to
[Prev in Thread] Current Thread [Next in Thread]