"Normal" - let me clarify - would mean simply this: That the order in
which you read the text is the order it occurs in the file. This has
nothing to do with the way the text is displayed. I felt it was impor-
tant to separate these two issues out. "Reverse" would be allowed, but
depracated, because it only works if you put in hard carriage returns,
and know what the line lengths are going to be. You'd need to block off
each line separately, putting in <BR> and turning off </arabic>. It is
a horrible mess, and I would not complain a bit if everyone just said,
"To hell with it; we'll just make sure clients know what to do when a
shift from left-right to right-left occurs, or can barf appropriately
if they don't."
>What I do not want is to have to cope with two orderings where one is enough.
>If there is a need to reorder bytes for the purposes of the display I
>would much prefer to do it myself after I have rendered the entities etc
>into tokens. Having the user do it as well simply confuses matters.
I agree. But in fact both ways of doing things seem to exist. Note the
RFCs I quoted in my last posting (1555 & 1556). The default MIME standard
is, in fact, the "backwards" way of doing things that you and I are com-
plaining about.
>The one exception I would make is for apperances of out of band entities in
>normal text. IE if I have a bit of text "fred ℵℷ" and the entities
>are just pushed into standard text I want them to be read left-right since
>they are in a LATIN context. To make them read right-left I would have to
>put them in a HEBREW context.
You think of everything!
Richard Goerwitz
goer@midway.uchicago.edu