wdc@ATHENA.MIT.EDU (Bill Cattey) (07/26/90)
I can keep my silence no longer. Fred Hansen mentioned that EditText, the precursor to Andrew had tabs. What he did not mention is that there has, historically, seemed to be code sharing between ATK and the older versions. Nick Williams and I have been going through style.c and various parts of the text object. We've come across something very interesting: TAB SUPPORT. It's there, but was never finished. From our preliminary research, it shouldn't be too hard to finish it. Does anyone remember way, way back in the past, the code was completely supported in style.c, but never connected through text? Was it a memory hog? A time hog? Dropped due to lack of time? We plan to find out.... You will CERTAINLY hear of our results. Does anyone else want to play too? -wdc
ajp+@ANDREW.CMU.EDU (Andrew Palay) (07/26/90)
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
tcrowley@bbn.com (Terry Crowley) (07/26/90)
Andy, thanks for your post. I'm also certainly very conscious of the problems with interactions between tabs and the difference between screen and printer fonts. For many purposes, the table semantics you discuss would be superior to trying to make do with "typewriter" style tabs (although most typewriters don't support right, centered, decimal, etc). But, this might be an example of a case of "the best is the enemy of the good". Even with the problems of differences between screen and printer fonts, tabs are extremely useful. While a table editor is appropriate for many things, consider all those "informal" 2 and 3 line tables that can easily make do with a simple notion of tabs, or with tabs used at the beginning of the line where character widths don't create a problem or with tabs used in a style with fixed-width fonts. There are some simple things a user can do to get around the problem even for bigger tables. They're the same kind of thing a troff user learns when using the raw tabbing of troff (instead of tbl). For example, set an explicit tab stop and tab over once rather than using (a different number of) multiple tabs on each line. Terry
tpn+@ANDREW.CMU.EDU (Tom Neuendorffer) (07/27/90)
Thanks to Andy for explaining the real story.
So what do people want tabs for anyway? In general , it seams to be for
creating simple tables where numbers or strings line up reasonably. The
table object provides this functionality, and it even goes to the extent
of using the same troff machinations that tbl uses to get everything to
line up. Though as Terry Crowley pointed out, often people don't want to
bother with this mechanism just to get a simple 2 or 3 line table. I
have been experimenting with some software to make doing this sort of
thing easier and I have a package that does some interesting things.
Take for example the following table, created with tabs between the fields
header 1 (memo) header 2 header 3
note 1 123 54 65
note 2 234 not applicable 88
note 3 999 645 345
Neither readable or pretty, I can select it with the mouse and call a
function that transforms it into :
header 1 (memo) header 2 header 3
note 1 123 54 65
note 2 234 not applicable 88
note 3 999 645 345
This form has the advantage that it both prints reasonably , and can be
mailed to non-atk sites.
Another function will actually turn the above into a table, with the
proper number of cells.
[An Andrew ToolKit view (a spreadsheet) was included here, but could not
be displayed.]
Thanks to table's print mechanism, this will print properly. The above
table just contains simple strings. If I want styled text, or text that
will span lines , I have another function that will turn.
header 1 (memo) header 2 header 3
note 1 123 54 65
note 2 234 not applicable but this is nothing to worry about 88
note 3 999 645 345
into the following
[An Andrew ToolKit view (a spreadsheet) was included here, but could not
be displayed.]
Again, this actually prints, though people that arn't reading this with
AMS are missing the table object that the above styled text became. Just
in case anyone reading this newsgroup the last few weeks is wondering
why people bother with ATK , I should point out that one of the beauties
of ATK is the fact that this sort of functionality can be added to the
system without any change or recompile of the system code.
I won't claim that this is the perfect solution, but it could make
things easier in many instances. If people are interested, I will look
into making this code available.
Regards,
Tom Neuendorffersmyser@ATHENA.MIT.EDU (07/27/90)
Tom Neuendorffer <tpn+@andrew.cmu.edu> writes: >> So what do people want tabs for anyway? >> [An Andrew ToolKit view (a spreadsheet) was included here, but could not >> be displayed.] This illustrates precisely the problem with relying on Table to do it all. On my desk I have three computers: this MIT Project Athena workstation with EZ as my favorite editor, a PC on which I often use one of Word for Windows, Wordperfect or Epsilon, and a Mac with Word. They're all connected to the net, and I have to routinely move data files and documents files between formats and programs. I want a tabbed document from the PC or Mac to be viewable on the workstation without herculean cutting and pasting or filtering into tables. Thus, I'd say, tabs in the basic editor have to work somewhat. "Somewhat" could mean every half inch left-justified and that's all. (that's about all on the PC too, and in the default settings of Macintosh and Windows Word, as well as WP). If the screen fonts have dpi metrics associated with them, measured tabs shouldn't be so hard to work out. Rob Smyser ---------- Manager, Computer Resource Laboratories MIT School of Architecture and Planning 77 Mass Ave #9-512, Cambridge, MA 02139 (617) 253-3535 smyser@athena.mit.edu
nichols@parc.xerox.com (David Nichols) (07/28/90)
One feature I would really like from Tabs is that they can be made to emulate Unix tabs easily. When I read mail with messages, I run across messages that have tables formatting for fixed with fonts. So I use the "This Message,Fixed Width" menu item to see it fixed width, only to discover that the tabs still don't work right. I'm not sure where the fix goes, but the Fixed Width menu item is a lot less useful to me in this mode. David
wdc@ATHENA.MIT.EDU (Bill Cattey) (07/28/90)
Excerpts from mail: 27-Jul-90 Re: Tabs David Nichols@parc.xerox (443) > One feature I would really like from Tabs is that they can be made to > emulate Unix tabs easily. When I read mail with messages, I run across > messages that have tables formatting for fixed with fonts. So I use the > "This Message,Fixed Width" menu item to see it fixed width, only to > discover that the tabs still don't work right. I'm not sure where the > fix goes, but the Fixed Width menu item is a lot less useful to me in > this mode. > David I'll bet I know why the tabs fail for typewriter font: The textview object currently sets the tab width to 8 pixels. The width of a character in andytype10 must be wider than 8 pixels. Or it could be bugs in the tabbing code of drawtextv. I think this problem can be repaired by incorporating the scaling factor I mentioned: fatten tabs on the screen by the amount that the font is fattened for screen display. (Some multiplier between 1.25 and 1.16) -wdc
wjh+@ANDREW.CMU.EDU (Fred Hansen) (07/29/90)
Excerpts from internet.info-andrew: 27-Jul-90 Re: Tabs Bill Cattey@ATHENA.MIT.E (975+0) > I think this problem can be repaired by incorporating the scaling factor > I mentioned: fatten tabs on the screen by the amount that the font is > fattened for screen display. (Some multiplier between 1.25 and 1.16) Egad. No. Please no. Tabs are already far too wide on the screen. FredH
grahamd@otc.otca.oz.au (Graham Dumpleton) (08/01/90)
Excerpts from info-andrew: 27-Jul-90 Tabs smyser@ATHENA.MIT.EDU (1268) > On my desk I have three computers: this MIT Project Athena workstation with > EZ as my favorite editor, a PC on which I often use one of Word for Windows, > Wordperfect or Epsilon, and a Mac with Word. They're all connected to the > net, and I have to routinely move data files and documents > files between formats and programs. What method are you using to do the conversion between Word and EZ? We have a need to do the same thing and would like to find something to do it rather than have to work it out ourselves. Has anyone else got this problem? Has anyone written a convertor or have a simple way of doing it? Graham Dumpleton. (grahamd@otc.otca.oz.au)