Suggestions for added Formatting Comands

A place for users to ask each other questions, make suggestions, and discuss Bookends.
Post Reply
ahmiller
Posts: 9
Joined: Wed Jun 29, 2005 4:12 pm

Suggestions for added Formatting Comands

Post by ahmiller »

Would it be possible for future versions of BE to add some features to the formatting of names in the format manager? In particular, I think the program could become much more versatile in the way "other" names are handled.

Choosing which name (author or editor) that other names will follow in their formatting works in most circumstances, but if you could also have an exception to the rule should the other name precede the title field in the format, it would reduce the need to constantly create new reference types, especially when there is a limit to the number of types allowed.

For example, an edited book with a translator is easy to create using the current options.

e,$ ed++. $ t. $Trans. $u3*. l: u, d.
Johnson, John, ed. title. Trans. John Doe

Of course, for the names of the translator(s) to display in the proper order (John Doe), one must choose other names to resemble the unused author field set to that word order. Often, one will encounter books that are edited and translated by the same individual(s), so all that information precedes the title.

Johnson, John, ed. and trans. Title.

Trying to use the format for the reference type used to create the first example above won't work in this situation because the names will then be output in the wrong order.

e,$ ed.++. $ u8*,$ ed. and trans.$ t.
will result in

John Johnson, ed. and trans. Title.

Of course, changing the other name to follow the word order specified for editors will only screw up the word order of other names in other records the first time they appear after the title. If there was an exception to the treatment of other names so that when they appear before the title field in the format, they would follow a specified word order (First: Editor: Doe, John or Subsequent format), then this would eliminate the need to create an additional reference type to handle this problem.

I know the issue of unlimited reference types has been raised in the past, and I don't think it is necessary should there be more flexibility in the formatting options. However, without this additional flexibility, there definitely needs to be more reference types. For those who work with old texts that often require the identification of author, editor, translator, compiler, annotater, punctuater, collater, etc. in the bibliography, it is really easy to use up all the reference types very quickly.

On top of that, although there is already a reference type for journal articles, the current formatting commands make it impossible to use just one reference type to handle the different formats specified for journals by the Chicago Manual of Style.

For example, for journals without a volume number, there are two different styles depending on whether or not the numbering begins anew each calendar year.

title, no. # (year): p-p.

or

title, year, no. #: p-p.

Right now, it seems I have to create two different reference types with their own formatting to generate these correctly. However, it seems that with additional tools that work like the ~ but have the ability to have fields, not just text, between them, it should be possible to generate two formats using just one reference type. For example, when creating records, if I use the issue field for those journals that begin numbering anew each year and use the volume field for those journals with continuous numbering, then with the addition of a special character or two, couldn't one create the following type of format:

t,$ no. $v~ (d):~|~ d, no. ~i: p-.

In this case, the date and text will be formatted according to which numbering system is used (v or i).

Bookends is still the best bibliographic program out there for OS X, but I dread the day I use up my last unused reference type. I don't know which is easier to implement from the programming end--additional reference types or more formatting commands and flexibility. The latter, at least, seems like a more interesting programming challenge.

Andrew
Jon
Site Admin
Posts: 10291
Joined: Tue Jul 13, 2004 6:27 pm
Location: Bethesda, MD
Contact:

Post by Jon »

Hi Andrew,

Adding more types is relatively easy. Creating more flexibility, as you say, also adds more complexity. Creating bulletproof formats (meaning dealing gracefully when fields are empty) is already pretty challenging, I think.

Jon
Sonny Software
Post Reply