Re: Media type parameters for braille

Hi Jason and all,  This issue indeed deserves pondering and it could be of
benefit to those who magnify the pc output as well and who use larg print
to read, thus changing the way a page looks on paper much like braille
does.  Even though we use braille in a one line at a time mode and are
limitted to the number of characters per line, braille display devices
have the capability of meandering and jumping around the screen much like
screen reading packages do.  The header, footer and table issues are
important though because Speech braille and Large print readers like
having a consistent little repeated layout to follow.  Scrolling is a big
deal for all three and minimizing that would be a boon to productivity.  I
have no technical sollution input at this time, but offer these thoughts
that they might serve to guide.  I use braille and speech on the computer
and read braille on paper.  In braille on paper, the document is set up so
that the headers and footers exist only where appropriate.  If they are
too long they are stripped down or out and in many cases, they are stated
once because of space considerations.


On Mon, 30 Jun 1997, Jason White wrote:

> I would be interested in receiving feedback from members of this list with
> respect to my proposal for adding parameters to the braille media type for
> designating (1) whether the output is to be embossed or presented on a
> refreshable display; and (2) the dimensions of the braille device. The
> form of the relevant media declaration would thus be as follows:
> 
> media="braille embossed [x] [y]"
> or
> media="braille displayed [x] [y]"
> where the optional x and y values represent, respectively, the number of
> cells per line and the number of lines per page available on the braille
> device. The concept of a "page" is not directly applicable to braille
> displays, since most of them can present only a single line of text at
> once. However, larger displays have recently been developed, although they
> are not as yet widely available and are the subject of ongoing research.
> 
> Rationale:
> 
> The principal reason for distinguishing between embossed and displayed
> braille is that some stylistic features which are useful on paper, are not
> applicable when reading a document with a braille display. These include
> headers and footers, page numbering and block protection (to keep related
> text on a single page), all of which may potentially be controlled by
> style sheets. The formatting of tables may also differ depending upon
> whether the document is being embossed or displayed dynamically by the
> HTML user agent.
> 
> The justification for the optional x and y parameters that specify the
> dimensions of the output device, is not so clear. The motivation for this
> concept stemmed from consideration of the problems associated with the
> formatting of tables in braille, and the need for tables to be presented
> differently depending upon whether or not they exceed the line length of
> the braille line. If the presentation of tables is to be controlled via
> style sheets, then it may be desirable to create alternative styles, with
> different parameters, for producing tables on devices with various line
> lengths. For example, some braille embossers support narrow paper and thus
> generate output of 32 cells per line, and braille displays vary in size
> between 20 and 80 cells. The treatment of tables in braille is a complex
> issue which in my opinion needs to be considered and discussed thoroughly.
> I am aware that other subscribers to this list are much better qualified
> in this area than I am, and would be interested to know whether a solution
> has yet been proposed. The number of lines per page may also be a useful
> parameter that would affect the formatting of tables, especially if they
> were presented in paragraph form and there was a need to keep all of the
> contents of a particular element in the table on a single output page. One
> difficulty which is also relevant in this context is that the number of
> lines per page varies depending upon whether six-dot or eight-dot braille
> is being used. Although most braille codes available today employ a
> six-dot system, eight-dot braille is becoming more common. For example, in
> Denmark, it is being used to increase the correspondence between print and
> braille character sets, thereby facilitating the deployment of
> software-based translation schemes. For further details, see ch. 9 of Lars
> Christensen's AITIIB research project report, details of which can be
> found at http://www.sensus.dk/aitiib.htm. An eight-dot code is also
> proposed by the Science Access Project at Oregon State University:
> http://dots.physics.orst.edu/. Furthermore, it is theoretically possible
> that six-dot and eight-dot codes may both occur within a single document,
> thus resulting in different numbers of lines per output page in different
> parts of the same text. The specification of page dimensions may not be so
> important when reading a document with a braille display, since the
> controls on the display, in conjunction with controlling software, should
> provide ample means of traversing a document. However, in formatting
> tables, it may still be desirable for style sheets to be able to ensure
> that a certain item of text is presented on a single line, in which event
> the line length parameter is once again crucial.
> 
> As is evident from the foregoing discussion, I have not reached firm
> conclusions in relation to these issues. Nevertheless, I thought that it
> would be appropriate to seek input from others rather than to continue
> pondering these questions alone.
> 
> Regards,
> 
> Jason White.
> 
> 

Hands-On-Technolog(eye)s
touching the internet
voice: 1-(301) 949-7599
poehlman@clark.net
ftp://ftp.clark.net/pub/poehlman
http://www.clark.net/pub/poehlman

Received on Monday, 30 June 1997 05:58:52 UTC