Sampling: What Nyquist Didn't Say, and What to Do About It
Dec 20, 2010 137 Replies
D
D Yuniskis
I'm not a zealot. I don't want to make a career out of maintaining my tools (unless I have to) but, rather, want to use a tool to get a job done. *Now* -- not when they get around to fixing some bug that is standing in my way (note that this critique applies equally to commercial products -- perhaps even MORESO as you are entirely at THEIR mercy as to when and IF they will fix the problem!).
As I said, there are many things that FrameMaker *can't* do that VP could. I have publications that I did under VP that are *stuck* there because of many layout tricks I could coerce VP to do for me that FM's design precludes.
The problem I find with many "packages" is getting all the right cruft in place that the package depends on. In the UN*X world, you have to make a commitment towards a particular direction as everything BUILDS on everything else. By contrast, the Windows world rebundles (usually needlessly reinventing!) all the cruft that a particular application is likely to need *with* the application (hence the bloat -- in both cases).
If you just install a prebuilt package, you are putting your faith in the "builder" that he understood the various (inevitable) compiler warnings, dependancies, etc. and made smart choices about what to do in each case (too often, people just blindly build things and as long as make ends "successfully" they figure "all is well").
[I build every application on my UN*X boxen from scratch so I have a better feel for what *might* go wrong "in use"]
I'm doing my end of year "swap in/out" of hardware so maybe I'll just install a prebuilt version and play with it long enough to at least see what it does/doesn't (that way I don't have to make a commitment to the software beyond reformatting the disk)
Didn't find your answer? Ask the community — no account required.
K
krw
A Child's Garden of Grass. Hadn't thought of that one in a while.
D
D Yuniskis
[attributions elided]
OTOH, it also imposes constraints on what you can *do* in those "other columns". E.g., if you use a different size typeface you get weird side-effects as one tries to force the other to "comply".
FM gives you control over widows/orphans on a "per type" basis. So, you can change how "Heading Text" is handled differently from "body text", etc.
Likewise, you have constraints on the extents to which text within a line is stretched/compressed. But, you typically need to *see* how things layout before you can decide if those are appropriate "for this publication". (as I said, you can do things in your layout to COMPLICATE your life :< )
FM (and most other WYSIWYG DTP packages that I've played with) *loves* to break things into little "units" whenever it can do so without looking like it is being obsessive. :> E.g., each "cell" in a table has it's own specific formatting.
Nominally, the "table heading" (e.g., top row) cells have one format ("paragraph type") while the cells in the *body* of the table have another. E.g., how far to indent from the edge of the "cell", how to hyphenate, what typeface, tabstops, etc. These can be overridden for individual cells, the table full of cells, *all* cells (i.e., the "cell body" paragraph type), etc.
The "title" for the table (e.g., "Table 3-9: Common Insect Larvae found in Foodstuffs") is a separate type and "thing". *References* to that title are different things, etc.
This is hard to get used to until you think in terms of *other* publications for which it could be used (e.g., imagine laying out a "weekly sale brochure" for your local grocery store...).
Different DTP tools give you different ways of *using* this "meta-information". Commonly, you can build a ToC that just includes all "Chapter Heading"s. A list of figures that tabulates all "Figure Heading"s, etc.
FM, for example, will let you create cross references to instances of specific paragraph types. An obvious candidate is "Figure Headings" or "Table Headings" -- so you get "consult the illustration in Figure 23.5 on page 94" automatically.
Exactly. Though I think there are packages (lyx?) that wrap an interactive user interface around it.
I've just found DTP to be an inherently interactive process. You tweek one thing and see what else changes as a result. E.g., if I put a non-breaking space here to keep this phrase intact IN THIS INSTANCE, what gets munged in the *next* paragraph that I will need to "fix"?
I've disciplined myself not to use them. This may be a bit Draconian of a stand but it's too easy to forget where those "tweeks" are in a document. So, you could end up tweeking something right next to it as a result of that previous tweek (that you have forgotten about).
When things need that level of fine tweeking, I resort to rewriting the text to cause the "natural" (un-tweeked) appearance to be more acceptable (sometimes at the expense of more stilted prose :-/ )
That's why I opted on using PDF's for publications and notes. It's too hard to prepare things that others will be able to review AS YOU INTENDED THEM using other presentation formats.
The problem with non-breaking spaces (besides the fact that you have to *insert* them (i.e., replace the normal space with a non-breaking one) is they make that "phrase" physically longer (intentionally). I typically only do this selectively (e.g., a global "search and replace" -- possible in FrameMaker even with formatting stuff -- will often end up causing a problem elsewhere in the document. (short column widths really makes things tough!)
The bigger "problem", IMO, is my not treating "Kirk - Bear Canyon" (KBCN) more formally. E.g., the names of each of the sponsors are typeset in italics -- yet KBCN isn't.
On the one hand, you want to litter the text with "Kirk - Bear Canyon" to drive that home to the reader (this is, in a sense, a "sales pitch"!). OTOH, you end up with that much more italics in the document (which is already seeing lots of pressure as a result of book titles, web links, etc.).
This is probably a fault in the spacing associated with the "font"s design. "Display fonts" (i.e., the wacky, decorative fonts like the one I used for the "article titles") are often poorly built. I.e., these are the types of things you get in those "5,000 fonts for $9.95" packages.
There are "space above" and "space below" parameters for each paragraph type (e.g., "Article Title", "body text", etc.). These are conditionally applied and interact with their counterpart parameters in the "paragraph types" above and below.
There is an invisible "column top" created for the two leftmost columns on that page -- a consequence of the *bottom* edge of that photo *plus* any "space below" parameter that may be associated with the photo. This interacts differently (but consistently!) with the "Article Title" font at the top of column 1 and the "body text" font at the top of column 2.
(notice how the "Article Title" font lines up "correctly" in the top of column 3).
All I can do is play with parameters looking for a sweet spot that results in FM putting the text where you would like it in these two instances. Note that if I change the definition of the "Article Title" paragraph type, then it has consequences elsewhere in the document. (notice how "Summer Reading Program" does/doesn't appear to line up with a "baseline" *above* in the adjoining column)
That "article" was tough to format. Too many conflicting "things" in each of the items within (it is essentially a list of "mini-articles"). I.e., each "mini-article" (event) has a date, time (sometimes timeSPAN), title and "responsible party".
I felt people wanted to see them expressed chronologically (and NOT "by topic"). So, date was the key item, with the time being secondary -- and closely associated with date. Left justifying the date and right justifying the time ON THE SAME LINE seemed pretty intuitive and, for the most part, worked great! The reader knows what to expect, where.
The "title" of each tends to be long. Too long to tolerate anything else on the same line. So, the "responsible party" had to fall onto yet another line. I opted to right justify it as it would, otherwise, have NOT "set the title off" to draw attention to it *as* a "title".
So, we've got three lines of text before we get to the description (body) of the event.
And, you would need at least *one* line between events. If I had opted for more, it ran the risk of looking too "airy" (remember, the baselines of the text in the adjoining column force things to line up in nice clean multiples of the line spacing... so, put one, two or three blank lines between events -- not 1.5! :-/ Unless I also diddled with the fonts used for the title/date-time, etc.
If I had chosen to start that whole "article" at the bottom of the preceding column (i.e., 86 the little blurb about "subordinate Clauses"), then I would have had more space to play with -- but, still had to fight the "swiss cheese" look that would result (everything else in the document tends to have a "tightness" to it).
The biggest single problem with the layout is that it isn't very "senior friendly". The typefaces are too small, columns too tight, etc. OTOH, stepping up to a two-column layout (almost essential if you use a larger typeface for the body of the text) would have made the document a lot longer. (and printing and mailing costs disproportionately so) E.g., examine the "before" and "since" editions -- much looser layouts but a lot less *content*. (consider the last page is devoid of *real* content as it acts as a mailing label -- the newsletter is folded in half on the solid line)
It was my first "non-technical" publication. I try to make each new project a "learning experience". So, in that sense, it was a success. Just figuring out how to merge
*my* writing (and editing) with that of others without having it "obvious" was an interesting experience!
From the Friends' point of view, it was a *great* success as it attracted a lot of attention -- which, after all, was it's intent!
D
D Yuniskis
Yes. There is also the *intent* and "emotion" to consider. E.g., technical papers are intended to be (largely) "cool" presentations, dispassionate, etc. Informative. Rational.
Newspapers should (theoretically) be likewise -- though there tends to be more of a sensational aspect as they are in the business of selling newspapers -- making you *want* to read them.
Sales brochures, flyers, etc. want to be terse and hard-hitting. They want to generate excitement and/or irrational responses in the reader to "trick" (do I sound too cynical? :> ) the reader into parting with his money.
I recall hearing that grocery ads tend to emphasize *red* as red is psychologically associated with hunger (though I would be hard pressed to find that reference :< ).
Then you have no problem! :> I am puzzled at the inconsistency (and lack of rational explanation there for) in *my* skill set in this regard. One would assume that being able to draw a particular shape would be invariant of the thing *owning* that shape...
D
D Yuniskis
*Far* beyond my goals! I'd be thrilled being able to draw a good *outline* of a person... :-/
I went to an art exhibit last year and spent a full 30 minutes examining an oil painting of a native american *convinced* that it was a photograph. Short of *touching* the work (frowned upon!), I tried everything I could imagine to convince myself that the few brush strokes that *were* visible were not, actually, just a "clear, textured overlay" atop a traditional photograph.
Absolutely amazing to see people with "alternative skills"... especially when those are excellent!
[I want to meet the guy who invented SEX and see what he's working on, now!]
C
Clifford Heath
Get a copy of "Drawing on the right side of the brain", read it, and do the exercises. You'll be surprised what you can learn to do when you learn to suppress the left brain.
He's trying to figure out how to get a woman interested in the idea.
Clifford Heath.
D
D Yuniskis
As I said, I can draw other things quite well -- including other "organic" things (still lifes, landscapes, etc.).
*And*, can tell you what is wrong with *your* drawing of a person. So, one would think these two things would
*imply* the ability to do so myself! :> [I want to meet the guy who invented SEX and see what he's
ROTFPMP! I will *have* to remember THAT one!
D
D Yuniskis
Thanks! Two of the PDFs didn't open for me (I'll try on a different system). And, the math is far too much for me to digest at the moment.
But, it looks like this describes the process completely (though probably in less detail than I can comprehend :< )
J
Jon Kirwan
Most of it isn't too difficult to broadly follow. Like many things in software, details matter and there are some details that still elude me. I'm particularly interested in the details for the 128 element vectors that are generated (over the entire picture, parts of it, etc.) and exactly how these are invariant over affine, magnification, and intensity changes. Actually, there are a lot of details that need to be clearly laid out. But I get the general idea pretty well from the presentation given at ICCV'03 by Brown.
If you get a chance, view the view I also posted separately. It adds something to hear the presentation take place. It even includes such details as their criteria for different algorithm choices depending on spatial frequencies for blending and constant factors they use in likelihood estimation. It's worth a moment or two.
Jon
D
David Brown
I understand entirely. Sometimes it is fun to play with software, try it out, and see how it works (or doesn't work). But most of the time, software is just a tool, and we expect it to work as it should.
Actually, Linux distributions have pretty much solved this problem years ago - tools like "apt" and "yum", or their gui front-ends, are excellent at finding and automatically installing all the required packages, libraries, etc., that are needed. So on a Ubuntu, I just type "apt-get install scribus", and apt pulls in python, cups libraries, and whatever else scribus needs. One can make many accusations about this system, but not bloat - it is very much about re-use and sharing of packages and libraries.
In fact, I find one of the biggest problems with the Linux way of handling packages is that it is hard to get the bloat you sometimes want. For example, if you want to install two different versions of the same program, it is easy in windows - just pick different paths during installation (assuming it's not a program that claws its way deep into the system and the registry). With Linux, this needs a lot more thought and work - the standard installation procedure is so easy, and so automatic, that it is hard to do non-standard installations.
How is that any different from anything else you install on your machine, Windows or Linux? You are also putting your faith in the programmer that wrote the software in the first place. All I can say is that it is worth getting the main parts of your system from a source that has good build and test procedures - when your distro comes from major players like Red Hat or Ubuntu, you can be reasonably confident. As you stretch out, getting packages from smaller groups or additional repositories, you might get more problems - in particular, the testing will not have covered the same range of systems.
Building from scratch is sometimes the best answer - I have typed the "./configure && make && make install" mantra many times myself. It can also be educational. But it is a lot more time and effort. Normally I expect software to just work straight out the box, whether it be a "setup.exe" in the windows world, or an "apt-get" or "yum install" in Linux. And most of the time, my expectations are justified (or they can be lowered until they are justified...)
D
David Brown
Lots of snipping to save electrons - your post was an interesting read, but I don't think I could add anything by commenting on much of it.
TeX also breaks things up into little boxes (mostly hbox's and vbox's), but most of that is handled behind the scenes.
DTP for a document like this is more of a visual art, and thus an interactive program is essential.
lyx is more of a glorified TeX-specific editor - it doesn't attempt to give you a true "live" view of your output document. I tried it a bit, but I didn't like it - since it can't handle any of the more interesting features of (La)TeX, it gives you very little. The real fun with LaTeX comes when you make macros and "program" your document - you can't see any of that with lyx. And because lyx is not quite standard LaTeX, you don't have such easy access to the enormous numbers of existing packages, styles, and add-ons.
pdf is ideal for delivering documentation to others. But sometimes it is necessary to work together on a document - I write some, someone else writes other parts. And that means using the lowest common denominator tool, which is typically a word processor. If I can at least get other people to use styles properly, then I can usually cope without tears.
I never claimed that following these typesetting rules would be easy!
Conflicting requirements are always a challenge - it's what makes the day job fun. Hands up all the engineers in these newsgroups who have been asked to make something small, good /and/ fast!
Be careful - you'll end up with a job for life.
D
D Yuniskis
My recollection of that is different. FM tries to treat every bit of *text* as a little "unit" (not every bit of page real-estate). [the term "paragraph" is approximately correct -- though it also applies to more than *just* (classical) paragraphs...]
E.g., the caption on an illustration, the text in each "cell" in a table, the page number at the bottom of the page, etc.
You can apply "styles" to almost everything in FM -- "paragraphs",
*characters*, tables, pages, etc. So, you might apply the "chapter title" PARAGRAPH style to the text: "Earthworm Mating Habits". This might cause the text to appear in a large decorative typeface, right justified on the line, 2.7 inches down from the top of the page, etc.
Within that "string", you could apply the "draw attention" CHARACTER style (all these names are user defined) to the substring 'Mating'. This might, for example, cause them to be displayed in a different typeface, as small caps, bold, italic and in red ink (thereby "drawing attention" to them! :> )
When the table of contents is built, that string will appear (by virtue of a cross-reference) yet will have a different "paragraph" style applied to it -- perhaps "TOC chapter". This would undoubtedly use a *smaller* typeface with different margins (so it appears in the right spot in the ToC), etc.
I think Word (et al.) have similar capabilities wrt "styles".
I've found that to be the case for almost everything I "typeset". I use *lots* of illustrations, tables, cross references, etc. Trying to insert them in the text directly (as if writing HTML in vi(1)) is too tedious (FM supports a "visible" file encoding that you technically *could* "edit" directly).
It's much more expedient to just race through the document "tagging" paragraphs with the "right" styles, etc.
Likewise, inserting a table or a photo is much more intuitive (, style "Short summary"; ; etc.) And, you can then scribble on things directly (e.g., adding callouts to an illustration).
Oh. : but I didn't like it - since it can't handle any of the more interesting
You might find it easier to just let folks "feed" straight ASCII to someone who does the editting, etc. This helps ensure a consistent "style" imposed on the results. Usually, getting the *content* right is where most of the work lies. E.g., if someone explains/describes something, I can completely rewrite it rather quickly (much faster than if I had to come up with the content myself). Then, it "reads" consistently with the other parts of the document (also, many people are terrible writers and are happy to have someone else "dress up" their prose.)
Yes. Now imagine marketing, manufacturing and engineering all telling you *different* goals -- and none actually doing any of the *work*! :>
No, some wanted an "boss-worker" relationship. If I'm *giving* my time, I sure don't *want* (nor NEED) a "boss" -- especially when I'm the one with the DTP experience! :> (no hard feelings; I just brought them a plate of cookies last week!)
It appears they found someone to take over the task (though it looks like it took them a full year to do so :-/ ). This is good as I believe public libraries to be a real asset (though I am deeply disappointed at how *loud* they have become!)
D
D Yuniskis
I played with the Windows version for an hour or so last night. (sigh) It's got a *long* way to go. I would consider it: "Wordpad with Tassles" (does more than Wordpad but not enough to make you want to adopt it IN PLACE of Wordpad).
You might consider looking at the FM "tryout" (I think Adobe still offers one?). I don't recall how it is crippled (features, time, etc.). But, you would be able to see the sorts of things you can do and the effort required to do so.
(E.g., for scribus, I tried to create a little document with a table, a photo, an illustration, etc. -- just to see what it felt like)
Exactly. I doubt many carpenters go home after work and play with their hammers! There are enough things that I *must* (or *choose* to) do with a computer so spending extra time is not high on my list. Sort of like "window shopping" (do you REALLY have that much free time that you can waste it passively looking at merchandise without an *intent* to purchase??)
The *BSD's have a "package" system with the same functionality. As with any "true" UN*X tool, it just pieces together actions performed by other (existing) tools. E.g., consult "database" for package (to identify dependencies), "install" dependencies (which requires examining database for that package's dependencies, etc.), etc.
My "bloat" comment is that everything calls other "packages" in. And, that those packages tend to have been created independant of the packages that rely on them.
So, for example, if a "program" (getting away from notion of "package") needs to be able to *display* a PNG, it drags in the *entire* png package (which has far more capabilities) instead of *just* that "display PNG" capability.
If you use the *BSD "package" system, you suffer the same fate. Things end up (in the file system) wherever the package "author" decided to put them. And, you get exactly the "features" that he decided upon when he created the package.
The *programmer* is different from the "package maintainer"! E.g., I wouldn't question Wolfram's abilities. OTOH, when "John Doe" *packages* his creation for my use, I don't have anywhere near the confidence in John Doe (how familiar is he with the actual "product"? How familiar is he with the package system? How clever is he at getting a package to support flexible configuration? Is this something he just does "in his spare time" -- or, is he passionate about it?).
This is why I am slow to upgrade... "chase the bleeding edge". If I have something (tool) that works -- at least "well enough for my current needs" -- then why waste time "upgrading"? (you can spend every waking minute "upgrading" *something*)
When I build from scratch, I see what goes into a "package"; what options are present in that particular "configure"; etc. I also get a chance to look at what decisions/conclusions configure (as well as the rest of the make) comes to ("Um, I have libfoo installed! Why didn't it *find* it?").
The pkgsrc system in *BSD lets me explore packages without embracing them. For example:
"make fetch-list" gives me a list of everything that has to be downloaded (not currently on my system) to build the package. The process recursively examines each dependency so I can get a feel for how much "work" is involved -- and how much potential there is for "fixups".
"make fetch" obviously *gets* whatever is needed (using URLs listed in the package's definition file)
"make extract" unpacks things and sets up a "work" directory in which to build the package.
"make patch" applies any particular patches (including those that are specific to the package system itself -- like rewriting the original *fetched* distribution's makefiles to site the results in specific places).
"make configure" runs configure et al.
At this point, I can rummage through the "work" hierarchy to see what's there and what *will* happen when the actual "make" is invoked.
I typically run "make > dgy 2>&1" so I can examine the messages emitted during the build. If that looks right, then proceed to "make install" (again capturing stderr/out) and "make clean".
The "make install" updates the database of *installed* packages on the system so anything that subsequently "requires" this package sees that it is there.
I have my own conventions for "what goes where". And, I notice some packages are inconsistent (there are guidelines for package creation but adherence is optional :> ). So, while most of these add-on packages go in the /usr/pkg hierarchy, some I will pull into /usr/local or other places (e.g., I mount /usr/pkg late and some of these are things I might want to use even with *just* the root filesystem mounted R/O)
M
Michael A. Terrell
What do you think of this PDF?
formatting link
Any idea how I did it?
For the last time: I am not a mad scientist, I'm just a very ticked off
scientist!!!
D
David Brown
It's not the most exciting reading...
The "producer" stamp just says ghostscript. So I'm guessing that you first generated a postscript file, then used ps2pdf to convert it to a pdf.
As for the postscript file, it was perhaps generated programmaticly from an existing database or table of information.
If that's the case, then you might want to consider generating the pdf file directly in the future. There are a number of pdf toolkits around
- I have used reportlab with python a number of times, and it makes it easy to generate some pretty reasonable pdf's.
An alternative is to have a program that generates a LaTeX file, and use pdfLaTeX to generate the pdf itself. This is an easy way to separate the data content from the style - change the style in the LaTeX part, and define macros for displaying the different parts of the document. Then the program part just generates a list of macro calls from the data, and you can easily experiment with different styles and effects. It would be much easier to get things like leaders, alternative fonts, clickable links, etc., in this way.
R
Randy Yates
A database query dump into a2ps followed by pstopdf?
Randy Yates % "My Shangri-la has gone away, fading like
Digital Signal Labs % the Beatles on 'Hey Jude'"
yates@digitalsignallabs.com %
http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELO
D
David Brown
Here in Norway, Christmas is celebrated mainly on the 24th rather than the 25th. So if my replies in this thread are short or non-existent, it's not because the posts are no longer interesting - it's just I don't have time to read them or reply to them.
There is no real chance of me ever buying FrameMaker (either at home or at the office), so I'm not going to bother testing it. I will give Scribus a shot some time for interest, but I doubt if I'll make much use of it. Most of my writings are technical, and I use either LaTeX if I can, or OOO if I have to. Interactive DTP is just for fun in my case.
The BSD "ports" system has a lot in common with the various Linux package managers, such as apt, yum, portage, etc. There are differences in the details and the functionality, but all are designed to make it easy to get hold of a package and any other packages that it depends on, and to keep everything updated (if you want it to).
I think you are exaggerating here. In a great many such cases, these libraries are shared by a lot of programs on the system. No "apt-get" is going to install "libpng", because the basic installation already has a dozen other programs that use the library. The same thing applies to other common libraries. And for rarer libraries, they are often made to work with the main package (and thus there is little extra). I'll not claim there is no wastage, just that there isn't much extra. It is certainly an order of magnitude better than the windows style of including copies of every library with every program.
True, but who is to say that the programmer is better at this job than the package maintainer? As an example, the typical programmer has tested his code on one or two machines, probably with the same cpu architecture. The package maintainer will test on dozens, and do builds on multiple cpu architectures, and will integrate with system testing on hundreds or thousands of systems.
You can do pretty much the same things with apt (and its underlying dpkg tools) and yum (and rpm tools). The details are different, and sometimes you need to install extra utilities, but the functionality is all there for those that want it. You can be sure that the *BSD and various Linux distribution developers learn about each others tools, and take inspiration from them.
D
David Brown
Word is poor at styles. It's biggest problem, however, is not lack of style functionality - but that users are encouraged to manually format everything by selecting fonts, sizes, etc., for text using toolbar buttons rather than styles. It's a guaranteed way to make the document inconsistent. OOO at least makes it easier to use styles and harder to use manual formatting, which helps document layout.
No, lyx is more a "what you see is a bit like what you get" layer. While editing, you see results that are closer to the output than you would with a simple text editor, but not /that/ close. It will cope with things like bold and italic, some fonts and sizes, and a bit of symbols. But it won't get line and page breaks right, it won't handle macros other than predefined ones (and even then, it assumes they have the standard definitions, while (La)TeX lets you re-define everything). If you use (La)TeX in a relatively simple way, sticking strictly to the basic standard styles, then it is maybe useful. But it never suited me. Mind you, it was /many/ years ago that I tried it.
That's okay if I am accepting work from others, and am happy to do all the layout, sectioning, etc. It loses a lot if there is non-ASCII data (tables, pictures, etc.).
D
D Yuniskis
If you want a *critique*... :>
I like a "fence" on the sides of tables (doesn't have to be between columns) -- it helps constrain your eye so that it knows where the edges of the table are located (see below).
For *long* tables (also see below), I like to add shading to help differentiate one row from another. E.g., much like old computer "green fan fold". This helps your eyes walk across a line without losing track of *which* line they should be following.
For *wide* tables (which this is NOT!), I would opt for perhaps "every other" line being shaded. For longer tables, perhaps groups of *4* lines (i.e., 4 lines shaded followed by 4 unshaded lines). If there is some strategic value associated with some other "grouping" (e.g., every 5 lines for a table listing the integers from 1 to 100), then that would influence my choice.
You could do similar with "lines" under every N'th table line.
[FM lets you specify these things in the "table's format"]
The same sort of thing applies to wide tables -- using lines between *select* columns (of differing thicknesses to set apart "groups" of related columns).
I would also have shaded the background of the "header" line too set it apart from the table's "body".
The page numbers would be either "center justified" or "right/decimal justified". The "Page" heading would then be centered above that.
The column contents aren't "synchronized" with each other. I.e., if you were to draw a line under any *single* entry (in any column) and extend that line to the page's borders, you'd find the text on neighboring lines floating above or below this "reference". With *no* shaded backgrounds or lines between rows (as in your example), it is less obvious. By the same token, it makes it harder to do things like count how many entries are in your table; or find the
14th one in column 3; etc. (note that this is also made more difficult by the variable *height* of each entry in the table).
In the absence of a fence around the table, I would opt for a thin line in each gutter (see below) to reinforce the visual structure of the table (i.e., it is really one *long* table "folded" onto the page).
The "See " references I would write as "(/see/ )" (why capitalize "See"?) This makes the *reference* subordinate to the actual "datum" and helps differentiate the cross reference from parenthetical cases wherein you are expanding on an abbreviation (Automatic Musical Instruments).
Lots of ideas as to how you *could* have done it. :>
How *I* would do it in FrameMaker:
Create a 4 column "master page" layout (or, just change the current "frame" on "this page" to be 4 columns... depends on whether or not you want to reuse this stuff). Pick an appropriate gutter size (if you put sides on the table, you can minimize the gutter; otherwise, I would go for a "noticeable" size gutter -- ideally with a 1 point line down the center)
"Insert Table", 2 columns, ~100 (?) rows, 1 heading row. Specify the shading/lines that I mentioned above.
Fill in the Table Title ("Index to SAMS CM & RC Manuals").
Fill in the two "header cells" ("Brand", "Page").
Select right column ("Page"). Specify "right" justification (or "decimal" if you want to go that route). Pick typeface, etc.
Select the header row. Change to desired typeface, bold, etc. Specify "center" (justification)
Fill in table contents...
FrameMaker will fold the table into the next column once it reaches the bottom of the current column. Then the next column. And next. etc. Continuing onto the next *page*, as necessary. yet, it will still exist as "table 1" (conceptually). If you don't have enough rows, click "add row above/below" (after selecting an approximate number of rows to add -- so you don't have to keep adding one at a time!). When done, delete any unused rows.
I think MSWord has a "convert to table" capability (wraps a table around a "delimited" set of lines of text). I think it also has provisions to add lines between rows/columns, etc. I'm not sure how/if MSWord lets you 'fold' tables, though.
You can also build brute force with tabs, etc. But, that gets a lot harder to maintain (e.g., what happens if you wanted to insert "Victor Corporation of Japan" in there??)
D
D Yuniskis
Apologies for not eliding all that cruft -- I got distracted looking at the PDF
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.