Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!ANDREW.CMU.EDU!ajp+ From: ajp+@ANDREW.CMU.EDU (Andrew Palay) Newsgroups: comp.soft-sys.andrew Subject: Re: Tabs Message-ID: <4afar0e00VsSI9aWoD@andrew.cmu.edu> Date: 26 Jul 90 04:12:48 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 73 Many comments have recently been posted to why tabs have never made it into ATK in a reasonable fashion. Although I will admit that I may have missed some of the posts, I have yet to see anything close to the correct reason. The reason that tabs are difficult is due to the inconsistency of widths between screen and printer fonts. In the non-WYSIWYG world of ATK we did indeed want text to look reasonable on the screen as well as on the printer. To do this we set text on the screen using the screen fonts and set text on the printer using printer fonts. This raises the problem that if you set 2 tab stops (say at 1 and 2 inches) and on the screen you type text that gets you just past the first tab stop, hitting a tab will take you to the second tab stop. Unfortunately since printer widths are normally slightly smaller than the corresponding screen widths you will probably find out that on the printer the fist piece of text will leave you under 1 inch and the tab will take you to the first tab stop. This tends to surprise users (not to imply that our current scheme doesn't surprise them - but we have made no attempt to claim that tabs work). If others have a solution to this problem I am very interested in hearing it (By the way one solution to this problem is to put the non-WYSIWYG flavor of ATK's text object but I don't really believe that is the correct answer). There are other solutions to this tab problem that changes what the notion of a tab is. The Edittext solution to tab stops (alluded to in an earlier message) was one of those. If I remember it correctly typing a tab took you to first tab stop no matter where current position was. If it caused you to move backwards then it also added in a newline. Typing another tab would take you to the second tab stop, etc. This almost provided a consistent model between the screen and the printer, except for the introduction of newlines. It had the advantage that the left sides of the items but the final outcome of the text was unpredictable in that the exact layout depended on the width of the items that you entered and that varied from screen to printer. I too have a possible solution that changes the definition of tab, but have never actually attempted to implement it. It is based on first looking at why tabs are on typewriters. They were there for as a mechanism for building tabular data. In fact if the writer wanted to put in a string of text that did not fit in the current area (ie. it would move you past the next tab stop) then it was up the the writer to figure out how to break that piece into two lines and adjust all of the other entries appropriately. Given modern computers that are quite capable of doing this automatically given the correct constraints, it seems ridiculous that we use the normal notion of typewriter tabs to accomplish this task. By doing this we only perpetuate a barely tolerable solution that was chosen by the technology that was available at the time. I believe a better solution is to allow tabs to differentiate fields and have a tab take you to the next field. If the current text does not fit within the current area (as defined by the tab stops) it is automatically wrapped to another line. I can approximate this behavior by inserting a table inside of text with the size of the columns set to the tab stop settings and embedding a text object in each cell. Now when I type in the first cell it will not ever write in the second cell but just add an extra line to the first cell when I type too much. A tab at that point take me to the text object in the second cell and so on. I now get my information displayed in a reasonable fashion with minimal work and if I change the tab stop settings, something quite reasonable will happen. With typewriter tab model changing tab stops will often require changes to the tables that you have built up. As an aside: This is a problem that has existed for a long time. BRAVO (the editor on the XEROX alto) sufferred from this problem as well. It had a normal mode and a harcopy mode and if you ever used tabs only one of them ever worked out correctly, the other tended to look terrible. I know that was quite q while ago and we should have progressed beyond the alto but I believe this remains to be a fundamentally difficult problem as long as you want to mimic what a typewritter does with tabs and you are trying to do so in an environment where the basic parameters (like font widths) will be different depending on the output media you have chosen. Andy