<IMG> enhancement suggestion
Steven Grimm
specify several versions of an inlined image. For example, you might
have a color image and a monochrome version of the same picture. The
client would get a list of alternatives and their characteristics,
then decide which one it would best be able to display.
My rationale: I often do my webbing on a monochrome screen over a
fairly slow network link. Mosaic doesn't do a very good job of
showing color images in monochrome, and even if it did, it'd be nice
to avoid wasting time downloading a bunch of bitplanes I don't need.
Even on a color display, I'd like to quickly browse the web in
monochrome until I find something I want to see in color.
I envision something along these lines, off the top of my head:
<A HREF="Home.html">
<IMG NAME="homepage" SRC="icons/homepage.smallcolor.gif" SIZE="64x64"
COLORS=256 SCALE=75 ALT="Return to home page">
<IMG NAME="homepage" WHERE="icons/homepage.bigcolor.gif" SIZE="1000x1000"
COLORS=256 SCALE=600>
<IMG NAME="homepage" WHERE="icons/homepage.smallmono.gif" SIZE="64x64"
COLORS=0 SCALE=75>
</A>
That would give the client three icons to choose from. The first one
is the default, and since it has a SRC attribute it's the only one that
old clients will pay attention to. If it's not a problem to have old
clients show all the versions of an image, then the WHERE attribute in
alternate versions should be SRC for consistency. Alternates are grouped
together by matching NAME attributes, of course.
SIZE is the size in pixels, COLORS is the number of colors in the image
or 0 for monochrome. SCALE is a scaling factor, pixels-per-inch in this
example. It's distinct from SIZE since a document author might want to
provide images with different levels of detail and let user preferences
decide which is displayed.
Comments? Is this worth pursuing? Does it push too much implementation
detail out into the HTML document?
-Steve
Tony Sanders
] This might quickly get too complicated, but it'd be neat if you could
] specify several versions of an inlined image. For example, you might
] have a color image and a monochrome version of the same picture. The
] client would get a list of alternatives and their characteristics,
] then decide which one it would best be able to display.
Read:
http://www.bsdi.com/HTTP:TNG/MIME-ClientProfile.html
This talks about how to solve the problem.
--sanders
James Eric Tilton
>kor...@spud.Hyperion.COM (Steven Grimm) writes:
>] This might quickly get too complicated, but it'd be neat if you could
>] specify several versions of an inlined image. For example, you might
>] have a color image and a monochrome version of the same picture. The
>] client would get a list of alternatives and their characteristics,
>] then decide which one it would best be able to display.
>
> http://www.bsdi.com/HTTP:TNG/MIME-ClientProfile.html
>
>This talks about how to solve the problem.
>
But how can I, as an information provider, use this? Is this implemented
yet? To wit, could I set up, right now, a color and a black&white version
of the same picture, and could Mosaic (for example) negotiate for the
correct one, based on whether it was running on monochrome or a color
screen? And if so, how?
Thanks for any info...
-et
H Morrow Long
Hmmmm..currently?
Well, if the user has inline image downloading/display turned off in NCSA
Mosaic you could get the same effect by captioning alternate versions of the
same image and letting the user click on the version they want (hey, its
not automatic but it works). Otherwise you could let the user click on
one of several alternate hyperlinks (icons or text) that branch off to
HTML pages that present the different versions of the inline image, ie:
Click here to see the art gallery as color 1024x1024 pixel images.
----
Click here to see the art gallery as monochome dithered postage stamps.
----
Click here for an ASCII art appreciation consolation prize.
----
I have seen similar multiway branches used on European WWW sites
(especially from the front door or home page), ala :
If you speak and (or?) read English click here.
----
~
Habla Espanol? Si? Va aqui!
------------
Sprechen ze Deutch? Ja!
--
Parle vous Francais? Oui!
----
Shalom!
------
_ _ __ _ __
(/_ / (/ \/ \ _ __ __ ____ _ __ (/ _ __ _)
/ / . / )_(_)_/ (_/ (_(_) (_(_( /___(_)_/ )_(_)
( ( ( _)
H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT
06520-8285, VOICE: (203)-432-{1248,1254} FAX: (203)-432-0593
INET: Long-...@CS.Yale.EDU UUCP: yale!Long-Morrow BITNET: Long-Morrow@YaleCS
WWW: http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow.html
Brandon S. Plewe
I think multiple representation for inlined images is a great idea.
Trying to produce an html document that is pretty and useful when you
have to contend with low-resolution macs, 16-color (but high-resolution)
PC's, and monochrome X servers (why don't we all just go out and buy 21"
1280x1024 24bit monitors?). An icon that is too small to see on my sun is
too large to be an icon on a mac.
I'm not sure if I like Steve's suggested implementation. I'm one for
trying to keep improvements to HTML as simple and consistent as possible.
Having three IMG tags would be construed by a non-aware client as three
separate images, and having to select a version for each image would be too
difficult for the user.
I think Tony Sanders' HTTP Client Profile Proposal is exactly what is needed,
but a complete profile of the user's system may be a lot for the server to
wade through. Perhaps we could have categories of display capabilities, say:
L1 Low-Resolution Monochrome (i.e. for 640x480 monitors)
L4 Low-Resolution Low-color (16 colors i.e. plain VGA)
L8 Low-Resolution High-color (256 colors i.e. Mac)
M1 Med-Resolution Monochrome (i.e. 1024x768 14" monitors)
M4 Med-Resolution Low-color (i.e. 512K SVGA)
M8 Med-Resolution High-color (i.e. UVGA)
H1 High-Resolution Monochrome (Large monitors i.e. X-Servers)
H4 High-Resolution Low-Color
H8 High-Resolution High-Color (i.e. 19-21" Workstations)
Therefore, the work would be on the server side. If it did not have multiple
representations, it would just ignore the option and send the image. If it
had the correct version (with fn's like hobo.M1.gif, hobo.H4.gif, etc), it would
send that. If it didn't, it could either use some criteria to choose an
appropriate one that was available, or build one on the fly (i.e. color
reduction, resolution halving).
Client profiles in the ACCEPT: Header could allow multiple representations
for a lot of things (QT/AVI/MPEG? AU/SND/WAV? WP/Word/Frame?). This could
make everything almost as user-definable and platform-independent as the fonts.
Steven Grimm
>I think Tony Sanders' HTTP Client Profile Proposal is exactly what is needed,
>but a complete profile of the user's system may be a lot for the server to
>wade through. Perhaps we could have categories of display capabilities, say:
I agree that Client Profile is a better way to do this than what I suggested.
When I posted the head of this thread I hadn't yet waded deep enough into
the HTTP documentation to discover it.
However, I think it's a mistake to enumerate specific system configurations
in a list like you've done. Or rather, building such a list into the
protocol is a bad thing. If the server wants to provide shorthands for
authors to specify the display requirements for their images, that's fine,
but what those shorthands are should be left up to the server, since any
predefined list might not be suitable for a particular application.
Now for a more naive question: Which servers support using the Client
Profile data like this? So far I've been playing with NCSA httpd, and it
doesn't seem to have any such capabilities. Which isn't to say I couldn't
add them, but why reinvent the wheel? (For that matter, which _clients_
pass information about themselves to the server?)
-Steve
Scott Fritchie; ACC @ St. Olaf College
>>> said in <2ggde6...@SPARKY.CF.CS.YALE.EDU>:
hml> I have seen similar multiway branches used on European WWW sites
hml> (especially from the front door or home page), ala :
hml>
hml> If you speak and (or?) read English click here.
hml> ----
hml> ~
hml> Habla Espanol? Si? Va aqui!
hml> ------------
hml> Sprechen ze Deutch? Ja!
hml> --
hml> Parle vous Francais? Oui!
hml> ----
I've wondered about this. The HTTP protocol has an "Accept-Language"
option (see
http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html#z12):
Accept-Language:
Similar to Accept, but lists the Language values which are preferable
in the response. A response in an unspecifies language is not
illegal. See also: Language .
My question: There isn't anything mentioned in that bit or in the
"Accept" description about a preference among preferences. Is there a
way to rank/order preferences in the preferred languages? For
example:
Accept-Language: en, la, asl
(Pardon the non-ISO-ness -- my other languages are Latin and American
Sign Language :-) I would like doc in the first available language
reading left to right: English first, else Latin, else ASL (which
might look a bit strange in ASCII). My understanding of the HTTP
specs is that the spec does not mandate or imply such ordering.
Looking for kosher ways to provide for a Web-based, multi-lingual
Free-Net...
-Scott
---
Scott Fritchie, UNIX Systems Manager Member: Twin Cities Free-Net
Academic Computing Center, St. Olaf College Organizing Committee
1510 St. Olaf Ave., Northfield, MN 55057 (Minneapolis/St. Paul, MN)
frit...@stolaf.edu ... 507/646.3407
Luis Miguel Sequeira
>I've wondered about this. The HTTP protocol has an "Accept-Language"
>option (see
>http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html#z12):
>
> Accept-Language:
>
> Similar to Accept, but lists the Language values which are preferable
> in the response. A response in an unspecifies language is not
> illegal. See also: Language .
Ok, this sounds interesting. As a matter of fact, I'm quite interested
in creating a multilingual tree of documents (ie. we started it in
English but now they're requiring it in Portuguese... :-( ).
How does this work? For instance, does Mosaic/X (or WinMosaic)
actually send the Accept-Language field? And how does my httpd server
know which file to send him back?
Consider the following scenario. User is running Mosaic/X and selects
the Portuguese language (I wonder how this is done, but let's assume
for the moment it's one of the obscure options on the conf files). He
clicks on a hyperlink to document something.html which is on my
server. The server sees what is the preferred language by the client
(in this case, Portuguese), and "looks up" a table which tells him:
"well, 'something.html' has Language: en, so it won't work - let's
feed the client 'qualquer_coisa.html' instead, which is exactly the
same document, but translated in Portuguese". Nice, huh? Obviously, it
there are no documents in the preferred language, the "default"
language is sent back instead (as stated on the HTTP protocol).
Now, all this sounds very nice - ie. it's nice to know that the
protocol supports this kind of multilingual stuff - but I wonder if it
really works that way! How can I configure the NCSA httpd 1.0 server
to have a "lookup table" to serve multilingual versions of the same
document?
Any help on this would be gladly accepted. If there is no way (yet) to
do this, well, I'll have to use normal hyperlinks instead... :-(
- Luis
--
_________________________________________________________________________
/
/ Computer scientists do it byte by byte.
_/ _/ _/ _/_/_/
_/ _/_/ _/_/ _/ We don't ask for miracles to get the job
_/ _/ _/ _/ _/_/_/ done, we RELY upon them!
_/ _/ _/ _/ If the job still isn't done, we'll stick
_/_/_/ _/ _/ _/_/_/ with Emacs instead...
l...@lnec.pt Luis Miguel Sequeira
Laboratorio Nacional de Engenharia Civil
Phone 351-1-8482131 Ext. 2752 Centro Informatica/Grupo Sistemas Centrais
Pager 067700 Code 204913 Av. Brasil, 101 - 1700 Lisboa, Portugal
Support the World Wide Web now! (Get XMosaic from ftp.ncsa.uiuc.edu)
If you're reading this with a WWW browser, know more about me clicking
<A HREF="http://draco.lnec.pt:8000/lmsmv.html#Luis Sequeira">here</A>.
/
_________________________________________________________________________/
Bob Bagwill
: Now, all this sounds very nice - ie. it's nice to know that the
: protocol supports this kind of multilingual stuff - but I wonder if it
: really works that way! How can I configure the NCSA httpd 1.0 server
: to have a "lookup table" to serve multilingual versions of the same
: document?
A quick and only slight dirty way to do it would be to use a form:
<FORM METHOD=POST ACTION="http://yoursys.org/cgi-bin/language">
<SELECT NAME="Language">
<OPTION> English
<OPTION> Portugues
<OPTION SELECTED> Martian
</SELECT>
<INPUT type=submit value="Choose Language">
</FORM>
Then use the language value to return caipirinha.html instead of
screwdriver.html.
--
Bob Bagwill
rbag...@nist.gov
Luis Miguel Sequeira
>option (see
>http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html#z12):
>
> Accept-Language:
>
> Similar to Accept, but lists the Language values which are preferable
> in the response. A response in an unspecifies language is not
> illegal. See also: Language .
Ok, this sounds interesting. As a matter of fact, I'm quite interested
in creating a multilingual tree of documents (ie. we started it in
English but now they're requiring it in Portuguese... :-( ).
How does this work? For instance, does Mosaic/X (or WinMosaic)
actually send the Accept-Language field? And how does my httpd server
know which file to send him back?
Consider the following scenario. User is running Mosaic/X and selects
the Portuguese language (I wonder how this is done, but let's assume
for the moment it's one of the obscure options on the conf files). He
clicks on a hyperlink to document something.html which is on my
server. The server sees what is the preferred language by the client
(in this case, Portuguese), and "looks up" a table which tells him:
"well, 'something.html' has Language: en, so it won't work - let's
feed the client 'qualquer_coisa.html' instead, which is exactly the
same document, but translated in Portuguese". Nice, huh? Obviously, it
there are no documents in the preferred language, the "default"
language is sent back instead (as stated on the HTTP protocol).
Now, all this sounds very nice - ie. it's nice to know that the
protocol supports this kind of multilingual stuff - but I wonder if it
really works that way! How can I configure the NCSA httpd 1.0 server
to have a "lookup table" to serve multilingual versions of the same
document?
Any help on this would be gladly accepted. If there is no way (yet) to
Tony Sanders
> "Accept" description about a preference among preferences. Is there a
> way to rank/order preferences in the preferred languages? For
> example:
>
> Accept-Language: en, la, asl
> Looking for kosher ways to provide for a Web-based, multi-lingual
> Free-Net...
First you will have to get client authors to support sending
Accept-Language: from their browser. Then you will see server
implementations follow.
--sanders
Dave Blaettler
I've taken interest in this myself, but being that my main second language
is Russian, I am having to deal with the problem of an alternate character
set. Is there any way within Mosaic to look for and use alternate fonts in
HTML documents. The font I usually use for Russian text is koi8. If there
isn't a way to do this on the Web, I would like to propose of a way for the
Server and Client to agree upon changing fonts when requested.
Dave Blaettler
UCSD Medical Center MRI
dbla...@mr2.ucsd.edu
<A HREF="http://waynesworld.ucsd.edu/users/dblaettl.html">Dave Blaettler</A>
Nelson Chin
: about this language thing:
: is Russian, I am having to deal with the problem of an alternate character
: set. Is there any way within Mosaic to look for and use alternate fonts in
: HTML documents. The font I usually use for Russian text is koi8. If there
: isn't a way to do this on the Web, I would like to propose of a way for the
: Server and Client to agree upon changing fonts when requested.
as for Mosaic for X 2.1 you can get the multilocalization patch L10N from
ftp://www.ntt.jp/networking/WWW/Mosaic-l10n
excerpt from readme file:
Automatic character sets detection
==================================
L10N-enhanced Mosaic supports a subset of ISO 2022's codeset designation
escape sequences. For example, documents encoded in ISO-2022-JP or
ISO-2022-KR are automatically displayed by Japanese/Korean fonts without
font setting via Font Menu.
However, documents in ISO 8859-X and EUC-C/J/K cannot be judged what
character set is used without external information. This enhancement
supports the following ISO 2022 designation sequences. ( Note: We will
always use G0 and G1 for GL and GR, respectively.)
"<ESC> - A" designate right-hand part of ISO 8859-1 into G1
"<ESC> - B" designate right-hand part of ISO 8859-2 into G1
"<ESC> - C" designate right-hand part of ISO 8859-3 into G1
"<ESC> - D" designate right-hand part of ISO 8859-4 into G1
"<ESC> - L" designate right-hand part of ISO 8859-5 into G1
"<ESC> - F" designate right-hand part of ISO 8859-7 into G1
"<ESC> - H" designate right-hand part of ISO 8859-8 into G1
"<ESC> - M" designate right-hand part of ISO 8859-9 into G1
"<ESC> $ ) A" designate GB 2312-1980 into G1
"<ESC> $ ) B" designate JIS X 0208-1983 into G1
"<ESC> $ ) C" designate KSC 5601-1987 into G1
"<ESC> ( B" designate 7-bit ASCII graphics into G0
"<ESC> $ B" designate JIS X 0208-1983 into G0
If a document includes the one of these escape sequences, the document
is displayed by appropriate fonts without font setting via Font Menu.
The above sample pages and the living example are encoded in this way.
Please check it.
Tips
====
When you set Mosaic*simpleInterface resource to True, localization
facilities cannot be used.
L10N-enhanced Mosaic remembers a specified character set of each
document in the Window History (not Hotlist), and if you revisit the
document, the current character set is automatically changed. This
causes some strange font changes. If you don't like this, set
Mosaic*keepDocumentCharset resource to False.