Insets and Tables: container paragraphs with no additional spacing

[Lin Sims]

Not a bad idea, but this is the corporate style. We're also not
single-sourcing. (We were moving to that, but then the company got acquired
and the techcomm department was decentralized. But that's a whole other
story.)

Even if it were my call, I'm not sure I'd go that way. If the table splits
across a page, you lose the title. And these tables can go on for a couple
of pages, depending on the content..

On Thu, Oct 2, 2014 at 5:14 PM, Robert Lauriston <robert at lauriston.com>
wrote:

> In a situation like that, I use headings instead of table names. In a
> single-source environment, headings are more flexible.
>
> On Thu, Oct 2, 2014 at 2:10 PM, Lin Sims <ljsims.ml at gmail.com> wrote:
> > For the registers, we list all the table names as active links in a table
> > upfront. But if I am simply scanning through the tables, I find it
> easier to
> > use the cursor button than the mouse wheel. Your mileage may, of course,
> > vary.  There are also places where a brief paragraph introduces a set of
> > tables. The data wouldn't work well combined into single table, and I'm
> not
> > about to say, "The following table describes X" when I've already said
> it up
> > above. It annoys my engineers and the customer engineers.
> >
> > If I were in a different environment producing docs for a different
> > audience, I would very likely be introducing each table with some text.
> In
> > this environment, with this highly technical audience, it is neither
> > necessary nor wanted.
> >
> > On Thu, Oct 2, 2014 at 4:48 PM, Robert Lauriston <robert at lauriston.com>
> > wrote:
> >>
> >> How do users find the one they're looking for?
> >>
> >> On Thu, Oct 2, 2014 at 1:34 PM, Lin Sims <ljsims.ml at gmail.com> wrote:
> >> > I'm describing IC chip registers. There is absolutely no point in
> having
> >> > text or a heading in between each one, and this particular piece of IP
> >> > has
> >> > about 500 or so of them.
> >> >
> >> > As always, it depends on what you're doing and who your audience is.
> >> >
> >> > On Thu, Oct 2, 2014 at 4:26 PM, Robert Lauriston <
> robert at lauriston.com>
> >> > wrote:
> >> >>
> >> >> I would never have one table follow another without a heading or
> >> >> explanatory text in between.
> >> >>
> >> >> On Thu, Oct 2, 2014 at 1:20 PM, Lin Sims <ljsims.ml at gmail.com>
> wrote:
> >> >> > I like to use my cursor keys to scroll from table to table, and
> >> >> > putting
> >> >> > each
> >> >> > table anchor in its own paragraph lets me do that. If they're all
> on
> >> >> > the
> >> >> > same line, pressing the up or down arrow once pops you to the
> >> >> > beginning
> >> >> > or
> >> >> > end of all of the tables that are anchored in the same line. I do a
> >> >> > lot
> >> >> > of
> >> >> > documents with hundreds of tables that are one right after the
> other,
> >> >> > so
> >> >> > having an anchor anywhere but on its own line becomes a nuisance.
> >> >> >
> >> >> > Putting all the anchors in the same line also makes it much
> difficult
> >> >> > to
> >> >> > select just one table, since unless you are VERY disciplined about
> >> >> > putting a
> >> >> > space between them, FM drops the anchors on top of each other. And
> >> >> > (again)
> >> >> > if you have a lot of them, even using just a small space between
> can
> >> >> > make
> >> >> > the anchors wrap to another line (or three or four), which messes
> up
> >> >> > your
> >> >> > spacing all over again but for a different reason.
> >> >> >
> >> >> > On Thu, Oct 2, 2014 at 3:53 PM, Stuart Rogers
> >> >> > <srogers at phoenix-geophysics.com> wrote:
> >> >> >>
> >> >> >> On 2014-Oct-02 3:23 PM, Robert Lauriston wrote:
> >> >> >>
> >> >> >> What is the benefit of putting a table anchor in its own
> paragraphs
> >> >> >> instead of putting the anchor at the end of the preceding
> paragraph?
> >> >> >>
> >> >> >> I've inherited lots of documents that do things like that and it
> >> >> >> seemed to me like pointless busywork, but the people who set up
> the
> >> >> >> templates were long gone so I couldn't ask for their rationale.
> >> >> >>
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Lin Sims
> >
> >
> >
> >
> > --
> > Lin Sims
>



-- 
Lin Sims
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20141002/484da165/attachment.htm>