[dev-biblio] Fwd: [Bibdesk-users] Long author name
Just a use-case that might be useful for considering the range of
formatting requirements for the in-page citation. Jurabib offers a
way to have an abbreviation of the full author show up in author-year
type styles. Can CSL handle that?
Begin forwarded message:
From: Christian Burk <[EMAIL PROTECTED]>
Date: January 29, 2007 4:59:36 AM EST
To: For general discussion about using BibDesk [EMAIL PROTECTED]>
Subject: Re: [Bibdesk-users] Long author name
Reply-To: For general discussion about using BibDesk [EMAIL PROTECTED]>
Hello,
I use \usepackage {natbib} \bibliographystyle {natdin} and this works
fine for me and is customised for my needs. For this reason, I would
like to change the winning team.
I think there is an solution..., hopefuly ;)
Christian
Am 29.01.2007 um 10:39 schrieb Stephan Kurz:
Hi,
AFAIR jurabib supports the use of a "shortauthor" field.
Jurabib also offers a convenient way of dealing with the issue you
were
asking for in the last thread "Citing a webpage".
Hope this helps,
Stephan
Christian Burk wrote:
Hello,
I have an entry in BibDesk where the name of the author (it's an
institution) is quite long but has an abbreviation which would I use
inside the text.
The case is as follows:
Author: {BQS-Bundesgeschäftsstelle Qualitätssicherung GmbH}
This I ned inside the bibliography but in the text I would use only
"BQS".
Is there a way to do so?
Thanks
Christian
--
---
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?
page=join.php&p=sourceforge&CID=DEVDEV
___
Bibdesk-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] important question
I took a brainstorming session today on this issue and I would like to add some of my thinking to this discussion: - I now believe that flags are a less than optimal idea -- they add to much complexity (many flags necessary to do something more complex) -- they limit the things that could be done only to those for which flags do exist, and only in a pre-specified way -- every reference has to be set individually, and, most important, wishing to change the formatting has to be done on all those references (there is NO mechanism to do it globally) e.g. in the medical literature, references are often cited as a superscript number (as [2], or simply 2, but superscript). Now consider the following sentence: "Further details can be found in reference 2." We need another flag to specify that 2 is NOT superscript, and another that it is NOT enclosed in brackets (IF the initial format would have been [2]). The problem gets more complex if more than one reference are cited. e.g. "Further details can be found in references 2, 3 and 4." This could have been represented as (superscript) 2, 3, 4 or 2-4 (of course with/ w/o brackets and various other combinations). What I think is necessary is a *more flexible way* to cover various coding possibilities. Flags just don't seem the right solution. *My Vision of a flexible Solution* Instead of coding flags, I would propose to have one byte (or a global flag) that stores the class name (or number) of the *formatting scheme*. In other words: - allow the text to contain more than one formatting schemes - NO formatting scheme flag set (or class set to 0): use the default, the master formatting - allow user to define additional formatting schemes, like: -- scheme 1: drop author:: [year] -- scheme 2: drop year, allow chapter: (Author in chapter) -- these schemes should be fully customizable, exactly as the default scheme; -- so these schemes are much more powerful than the flag-options -- they are stored globally, too, so the user does NOT need to view every reference IF he decides to change later the formatting BUT can do it globally, in a very flexible way I also believe, this is more easy to implement. NO extra flags, just additional styles. The style engine becomes more simple. Just my thoughts. And of course provide a field 'caption', IF the user wants to manually change the text to be displayed. This field will store that text, and, as long there is text in this field, this text will be displayed inside the document. Automatic updating is NO longer possible, BUT OOo Writer could identify any entries that have changed, so the user can manually change them again. Regards, Leonard Mada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] important question
That was my point, I don't think the citation field does need locale. The *source* needs it, as it might be cited by another document in a format which requires locale. I tinkered with it and found what might be a problem though. The RFC3066 string put out as meta data is specified by the application language option, and overrides the content in the ODF 'meta.xml' source. There is a default(German) in my download of 2.1; easy enough to change but I feel like I was not warned. --Gannon --- Bruce D'Arcus <[EMAIL PROTECTED]> wrote: > > On Jan 28, 2007, at 5:45 PM, Gannon Dick wrote: > > > As I see it, there are several reasons to keep locale. None are > > related to computer processing, but rather Library Science. > > Locale for the source metadata, sure, but I'm still unclear why the > citation field itself needs it. > > Bruce > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
