Re: plain text has its points

   
Jason White wrote:
"The solution is to provide a well marked up document which preserves all
of the semantic distinctions and structural aspects necessary to enable
conversion into a variety of formats, across a range of output devices.
HTML can achieve this objective in many cases (taking into account its
inability to represent mathematical content, for which MathML is
required)."

(I strongly agree.  Math content is another very important topic not discussed at all thus far and has much wider implications for all future formats sure to come down the road)

"It should be possible to construct a tool that would collect a series of
small but related HTML documents into a single file, especially if the
LINK element is used, as provided for in the HTML 4.0 specification, to
connect the components. Anyone who really wanted plain text could easily
render the document in a web browser and save it as a text file, or use a
search and replace utility to eliminate the markup (perhaps replacing
paragraph elements with blank lines, headings with tabs and performing
other rudimentary operations that hardly compensate for the loss of
structure which is involved in such a transformation).
My personal approach to reading HTML documents off-line is to use
Emacspeak with the W3 browser. By using the audio extensions to CSS, this
software can indicate such features as lists, emphasised text, links,
code, quotations, etc., using different voices. It is genuinely
astonishing to observe how much richer and more informative this rendering
is than that produced by a screen reader."

(I would agree from what I have heard about emacspeak, but, bringing up concernns of the kind Jamal Mazrui has mentioned, how widespread is emacspeak?  How easy is it to install and learn - for the average non-techy?)
"Certain braille translators can process HTML files, though not always with
a high degree of formatting accuracy. The ability to combine various
components of a document into a single file might be useful in this
context as well, although the user would presumably then have to split the
file again in order to divide the output into separate braille volumes."

(I simply don't know enough about Braille translators to intelligently comment)


Although I might disagree here and there with specific well-thought-out points made by various people on this thread, I believe the overall framework Jamal Mazrui has consistently brought up on this and related threads should be the top level.
First, we want *equal access* for *all* irregardless of:

1) particular equipment, including hardware, software and adaptive technology.
2) Particular knowledge of the user/consumer of information and information services.  

3) Set of relationships: We all have different rehabilitation institutions, family, friends, and for those employed, co-workers, each of whom has varying degrees of knowledge, experience, and desire to learn.  Some happen to have friends, teachers, rehab. professionals etc. who excel in all these areas and therefore can give maximum support.  I consider myself fortunate for the most part in this regard.  However, The system, on the whole, should not assume that every individual just happens to have all the necessary knowledge or all the best support.  This is simply not the case for a whole range of reasons, not the least of which is the complexity of this issue as evidenced by this very thread.
4) income level of particular individual.


To sum up my two cents on this thread thus far, I may be persuaded to change my mind about particular means by which we achieve this goal (e.g. standardize on a browser such as Lynx or a format such as HTML 4.0 or require plain text), but if the discussion of these means is before the above considerations, I believe we are putting theproverbial cart before the horse.










------
Steven McCaffrey
Information Technology Services
NYSED
(518)-473-3453


>>> Jason White <jasonw@ariel.ucs.unimelb.EDU.AU> 12/07 5:39 PM >>>
The solution is to provide a well marked up document which preserves all
of the semantic distinctions and structural aspects necessary to enable
conversion into a variety of formats, across a range of output devices.
HTML can achieve this objective in many cases (taking into account its
inability to represent mathematical content, for which MathML is
required).

It should be possible to construct a tool that would collect a series of
small but related HTML documents into a single file, especially if the
LINK element is used, as provided for in the HTML 4.0 specification, to
connect the components. Anyone who really wanted plain text could easily
render the document in a web browser and save it as a text file, or use a
search and replace utility to eliminate the markup (perhaps replacing
paragraph elements with blank lines, headings with tabs and performing
other rudimentary operations that hardly compensate for the loss of
structure which is involved in such a transformation).

My personal approach to reading HTML documents off-line is to use
Emacspeak with the W3 browser. By using the audio extensions to CSS, this
software can indicate such features as lists, emphasised text, links,
code, quotations, etc., using different voices. It is genuinely
astonishing to observe how much richer and more informative this rendering
is than that produced by a screen reader.

Certain braille translators can process HTML files, though not always with
a high degree of formatting accuracy. The ability to combine various
components of a document into a single file might be useful in this
context as well, although the user would presumably then have to split the
file again in order to divide the output into separate braille volumes.

Received on Wednesday, 9 December 1998 14:26:57 UTC