NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/next/software/1198

Text File | 1992-08-17 | 5.3 KB | 105 lines

Newsgroups: comp.sys.next.software
Path: sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!jeffo
From: [e-mail] (J.B. Nicholson-Owens)
Subject: Re: What DTP/WP do tables (other than Frame)? (long)
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Organization: University of Illinois at Urbana
References: <[e-mail]> <[e-mail]>
Date: Mon, 17 Aug 1992 18:09:03 GMT
Lines: 93

[e-mail] (Tom Marchioro) writes:

>Other than that there's not much to satisfy you out there, but I think
>something can also be said about forming reasonable expectations:  If
>you really want to make unusually formatted tables on an ongoing basis
>which can be put into other applications, manipulated graphically, etc.
>then you're in a small minority.

I never said that I wanted to put unusually formatted tables into
other applications.  I want an application to be able to 'formatize' a
peculiar table so I don't have to start with some checkerboard table
and custom modify each one (even though all the custom mods I'm making
to all the tables are the exact same mods!) I do manipulate a lot of
oddly-formatted tables, but I can come up with ways to have Frame
generate them if Frame had a couple more features.

Of the table features in FrameMaker, it's almost exactly what I need
to get my work done.  I do use a lot of tables (some things cannot be
done in Frame unless you use tables), but the table support is very
close to what I need.

For example, here's a simple table that I want to be able to turn into
a format, so when I say "insert table type <X>, it inserts one of
these":

--------------------------------
|                              |
--------------------------------
|                              |
--------------------------------
|               |              |
--------------------------------

This table has three rows and the third row has two columns.  One way
to make this table in Frame 3.0, one must lay down a three row, two
column table and join (straddle) the two columns on rows 1 and 2.
This joining is a custom modification.  Even if you make the third row
a footer row, you cannot independantly specify how many columns wach
row has (not even specify that the header and footer rows have X
columns and the body rows have Y columns).  Being able to do that
would be a simple extension on what Frame offers, and allow one to
turn this table into a named format.  Instead, if you use a lot of
these tables, as I do, each table must be custom modified by either
using straddling or insertion of columns.  This defeats the whole
purpose of having named formats.

To be able to do this independant column specification, they could
implement another scrollView like they do for tabs where each entry in
the scrollView consists of a row number and the number of columns to
go in that row (or rows per column, whichever suits your needs
better).  This way, a minimal amount of change would be needed to
support something that is much more flexible and powerful than what
Frame already allows.

There are ways to get this table by using two named formats and laying
them down one before the other.  To get this table to be created using
named formats, you could make two table formats, one for the first two
rows and another for the third row with two columns, but since this is
the most basic form of the one table I use a lot in a particular
document, it defeats the point of using a single named format.  If you
lay down these subtable formats in the wrong order, the whole big
table is messed up.  The whole big table, even if you lay them down
right, doesn't act like one table anyhow when it comes to using the
tab key to move the cursor around; you end up always TABbing around
within one table.  Using more than one named format is basically a
hack, and an ugly one.

I don't think that the aforementioned table is so incredibly wild
that only I will want to make one like that.
I'm not saying that I would want someone to make TeX into a GUI-based
app.  What I'm saying is that what I want in tables (and other
DTP-oriented things) is a combination of what I've seen that Frame can
already do with tables and how I'd like to extend some things to make
them able to do more.  Since I cannot take features out of Frame and
Word and extend or generalize them as I think would be better, I tell
others who are making DTP programs what I would like to see, hoping
that they'll view my suggestions as a superset of what's available.

To concentrate on PasteUp for a moment, if the article and the posts
I've read on USENET are correct, there seems to be some sort of a
comparison between PasteUp and Frame going on even with beta copies of
PasteUp.  If PasteUp is to even approach the same users as Frame
users, it must have things like tables, auto table of contents and
index generation, conditional text, cross-references and variables.
Being able to select non-contiguous items would be a real time-saver
(not only in DTP but a number of other things too).  Since the Text
object is so poor and DTP people are having to rewrite or extend the
Text object so much, putting this thing in would make a large number
of the people who want Nissus/NeXT happy.  Regular documents demand
these things or things which perform the same functionality.
--
-- Jeff ([e-mail])
-- No NeXTmail please