jcbeatty@lute.uwaterloo.ca (John C. Beatty) (03/07/91)
I am working on a project for which we want to build a >1000
record database of Benesh dance notation phrases, from which
we want to be able to repeatedly create a variety of dictionaries,
based (for example), on which notation schools use the phrase.
Problem #1: no database that I have examined is able to generate
the final output for a dictionary in anything like publishable
form. The obvious solution: export the pictures and text for
a dictionary to a word processing or desktop publishing environment
and finish the job there.
Problem #2: with the partial exception of 4D, the Mac databases
I have looked at don't export pictures, or text with attributes.
And the desktop publishing applications I have probed aren't
very clever about importing them. Note that it is essential
that the importing application be able to drop text and pictures
into the appropriate places and arrange the layout automatically;
there will be too many records, and too many iterations of too
many dictionaries, to do this manually.
I have found one marginally acceptable approach, and would be
grateful for comments regarding a second I am contemplating,
but I am most interested in hearing from people who can suggest
an approach I have overlooked. Given the nature of the Mac,
this shouldn't be a hard problem...
A little more detail:
Database records consist of fields such as:
o A textual name (eg "Arabesque").
o A list of schools using the phrase or symbol (eg Bournonville,
Cecchetti, French, RAD, Russian ...).
o A small number of paragraphs describing the entry, using a small
number of fonts and styles (eg italic/bold, and the international
phonetic alphabet for pronunciation).
o A picture of the sign or phrase.
A dictionary entry might look something like this:
Arabesque, Third <bold> Cecchetti, RAD <italic>
--------------------------- ... pronunciation and other stuff ...
| |
| | The textual description of the entry,
| A picture of variable | consisting of a perhaps 1-3 paragraphs
| width illustrating the | of text. For compactness, these want
| entry. | to flow around the picture, as I am
| | illustrating here. blah blah blah blah
| | blah blah blah blah blah blah blah blah
| | More blah blah blah blah blah blah blah
--------------------------- blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah.
A dictionary of such entries wants headers, footers, and page numbers.
It also wants to prevent inelegant page breaks in the middle of an
entry. And so on.
The workable but not very satisfactory solution:
4D's Write module allows me export both text and PICTS into an RTF
file. A route that works is to read these with MS Word, write a
standard word file, read that with Nisus, and use Nisus macros to
do the layout. There are several problems with this approach:
(1) it's very slow - on the order of a minute per entry; (2) it's
fragile, and this setup will be used by non-computer people when
I am on another continent; (3) it would take a programmer to
modify it (see point 2).
Two other possibilities:
o Have 4D (a) strip the postscript out of each picture and write
it into a file, and (b) create a TEX-compatible output file for,
the text, with interspersed commands to select italic/bold where
needed (probably sacrificing pronunciation in IPA). TEX can then,
certainly, deal with the formating issues.
Disadvantages: loss of IPA, and the fact that the people using
this stuff (dance choreologists) aren't TEX users and won't
want to become TEXers. But, of course, they will be able to
hire them ...
o Write an extension for Quark to import pictures in some appropriate
form. This could involve reading a subset of RTF, into which
PICTs are written as an ASCI dump in hex of the bits in the
PICT. Or a 4D extension could simply dump the PICTS in the
resource fork of a file, to be matched against resource IDs
stored in a text file with the rest of each entry. Or ...
So - I am looking for suggestions of other, better ways to solve this
problem. And I would be interested in hearing from people who have
used Quark enough to know how easily Quark could be bent into shape.
(I don't own it, and have never used it.)
I am surprised that it appears to be difficult to move pictures in bulk
from a data base into a publishing application. Have I missed something
obvious?
Thanks for any thoughts you may have.
jcbeatty@waterloo.edu