groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: refer and Dutch names


From: Christian Jensen
Subject: Re: [Groff] Re: refer and Dutch names
Date: Wed, 11 Feb 2004 18:34:53 +0100 (MET)

On Wed, 11 Feb 2004, Robert Goulding wrote:

> On Wednesday, February 11, 2004, at 11:41 AM, Christian Jensen wrote:
>
> > But maybe there is a way to avoid that which I wasn't aware of?
> > (I should mention, though, that the " 't Hart" problem was by far one
> > of
> > the smallest I had with refer in connection with my thesis, which I
> > handed
> > in on Monday. If I am ever to write a book again I will look for a
> > replacement.)
> >
> Can you take a moment to describe what were the problems?  If refer is
> going to be developed, it would be useful to know what limitations were
> encountered in a real production job.

Yes, of course. I didn't want to include all that since (1) it might bore
people unnecessarily and (2) it would sound like griping over a program
which I am sure many people (including myself) find useful.

But to begin, the program is quite complicated in some ways. Customisation
is unavoidable for anybody who used it seriously -- both the .R1/.R2 lines
and the formatting commands in the macro package -- and the documentation
is, well, terse. You find yourself in need of tweaking and bending the
functions, and if you are not an expert (I am not) you are likely to do a
bit of a hatchet job. Among the specific problem were the following:

(1) In some scientific styles you need to be able to write references in
many different ways, such as:
a)      "It is often claimed that groff is easy to use (Clark 1992)."
b)      "Many claim that groff is easy to use (Clark 1992, Smith 1997)."
c)      "Clark repeatedly claimed that ... (Clark 1992, 1993)
d)      "Clark (1992) claims that ..."
e)      "Clark (1992, 1993) claims that ..."

+ the same with page numbers and more. While refer handles some of these,
I have not been able to produce e.g. b) and e).

(2) Refer uses some intricate way of constructing the '@' expression,
probably according to some general rules, but makes too many assumptions.
I have one auther who is listed in my bibliographic database as both

%A Toni Rietveld
and
%A A. C. M. Rietveld

and sometimes in collaboration with another author. In my reference labels
he/they appear(s) as "T. Rietveld and Hout", "Gussenhoven and Rietveld",
"A. C. M. Rietveld and Gussenhoven". While using initials to disambiguate
may be an MLA recommendation it is highly unfortunate when it is really
the same person, and it was frowned upon by my proof readers. All attempts
to redefine the label strings broke more than they fixed (for example the
"et al." function).

It seems that both these problems - (1) and (2) - could be solved if refer
allowed individual formatting of each entry. At one point I considered
removing labels altogether and writing them manually.

(3) A third, and quite serious, problem concerns that lack of index
fields.  There should be special fields for proceedings, online
publications incl.  a URL field and several others. Bending the few
existing fields to cover everything makes a mess of one's database.
Related to this problem is the fact that changing the macros to suit a
specific style is quite difficult (at first) due to the lack of
documentation.

I have more details, but I think this covers the important parts. I should
stress again that I have been glad to have a bibliographic system, but as
my work progressed, these problems became more and more obvious. Maybe the
comparison is unfair, but a program like Endnote can handle all of the
above.

(And just to add insult to injury my thesis document breaks the current
CVS version (Failed assertion, file label.y) but I will write a separate
message about that).

Best wishes,
Christian






reply via email to

[Prev in Thread] Current Thread [Next in Thread]