dhosek@sif.claremont.edu (Hosek, Donald A.) (07/31/90)
Passing the following on... /From: dberry@TECHSEL.BITNET (dberry) /Subject: about tri-directional formatting Dear Don.. Someone passed your citation of our work to me >Dan Berry at UCLA has written a version of troff that handles >tri-directional typesetting (for documents mixing Arabic, Chinese >and Armenian, say) and has written a report describing his >efforts. I believe he monitors this group, so I'll let him >describe his efforts himself. Thanks for the citation.. but I must update and correct a few things.. I am no longer at UCLA, having moved to the Technion 3 years ago and having resigned all affiliation with them as of 30 June 90. I have changed my US affiliation (Every Israeli academic must have a US affiliation :-)) to SEI at CMU. We did not write a version of troff. Rather, we wrote a ditroff post-processor that runs on an UNCHANGED standard ditroff that makes the combination tri-directional. The original troff was written by Joe Ossana and ditroff was written as a modification of troff by Brian Kernighan. I, myself, did not write even the post-processor. My former student, Zeev Becker, wrote the top-to-bottom post-processor with me serving as customer and advisor. I wrote the English version of the paper following my reading of Zeev's thesis in Hebrew. The paper about "triroff" was published in Electronic Publishing 2:3 October 1989, pages 119-142. We typeset the article camera-ready using the software described in the paper. The article describes how the top-to-bottom post-processor maps from ditroff device independent output to the same. Thus it can be stuck in between ditroff and any device driver without either being the wiser. Ditroff does a standard left-to-right format, and then the top-to-bottom post-processor reorganizes the constant width far-eastern text to be read from top-to-bottom, taking advantage of the fact that any rearrangement of square characters takes up the same area! The right-to-left post-processor also maps from ditroff device independent output form to the same. Thus it can be stuck in between ditroff and the top-to-bottom post-processor, with neither being the wiser, to make the whole shebang tri-directional, all with NO CHANGE to ditroff and to device drivers! Triroff cannot handle the two-choices-for-comma-based-on-available space because ditroff cannot. Also, for vertical text, half width commas mean nothing, and in fact mess up the invariant of all characters being the same size that is required for the post-processor to work. For horizontal work, I am wondering how to trick an unchanged ditroff into choosing one comma or the other based on spacing available. It probably can be done by using some conditional macro accessing registers giving status of the line being formatted at the moment. But it would be a mess. I cannot post easily from here.. Dan --- Don Hosek TeX, LaTeX, and Metafont Consulting and dhosek@ymir.claremont.edu production work. Free Estimates. dhosek@ymir.bitnet uunet!jarthur!ymir Phone: 714-625-0147