Authors with no given name


I thought that 2.1.6 had solved the question of authors with just a family name, but I just discovered there is still a problem.

I was asked to put the family name in small-capitals. Unfortunately the command leaves these specific authors' family name unchanged.

Hoping it won't be too difficult to solve and that the new release will make everything work all right.

  • it would probably be helpful to post a link to the style in question - name styling is quite intricate, we'd need to know what exactly you have right now.
  • Yes, access to the full style will be helpful. For Zotero 2.1.7, the names formatting code inside the processor has been completely rewritten. With the new code, everything will work the same, but a number of little bugs will either disappear or be quite simple to fix. This might be one of them, and it would be good to be able to check that out before the next Zotero release.
  • 1/ The style is available at :


    I tried with somebody else's style too. The result is the same.
    Entering a point in the given name works, but it is not really "clean"!
    There are quite a lot of such entries.

    2/ Concerning names, I have encountered the case of the dropping-particle : d'

    To have it recognized as a dropping-particle, I need to add a blank after it to separate it from the main part of the family name

    The problem is that this blank is not suppressed when the given name appears first, as:
    F. H. d’ Aubignac, while it should appear as:
    F. H. d’Aubignac,

    If you prefer, I can start another discussion for it
  • In Zotero running the latest version of the processor, the name comes out in large and small caps in your style, with the given name empty in the Zotero database entry. So that looks like its working.

    For the dropping particle, it should be placed in the given name, after any given name (particles placed before the family name are read as a non-dropping particle). However, although I could swear that this is included in the test suite, a space does appear between the two elements. I'll look into this tomorrow.
  • I'm not sure I completely understand what you mean.

    So, I give you some examples (with Zotero 2.1.6)

    1/ In the data base:

    François Hédelin d' Aubignac
    where "d' Aubignac" is the family name

    Jean de La Bruyère
    where "de La Bruyère" is the family name

    where "Molière" is the family name (no given name)

    2/ Results:
    2-a/ Bibliography:

    AUBIGNAC François Hédelin D’.
    (where A F H :capitalized, UBIGNAC D’ :small-caps, rançois édelin :small letters)

    (where L B J :capitalized, A, RUYERE, DE :small-caps, ean :small letters)

    Molière. (where M :capitalized, olière :small letters)

    2-b/ Footnotes (no small-caps)

    F. H. d’ Aubignac,
    J. de La Bruyère,
  • I don't want to hijack this thread but I played with dropping-particle two weeks ago and was surprised by the final output.

    I was desperate to get this output:
    "Belou (Pierre du)"
    "La Fontaine (Jean de)"

    Until now, in zotero, I've filled the family-name field with "du Belou" and "de La Fontaine" and the given-name field with "Jean" and "Pierre".

    With demote-non-dropping-particle="sort-only", I got:
    "du Belou (Pierre) "
    "de La Fontaine (Jean)"

    and with demote-non-dropping-particle="display-and-sort", (note the bug with parenthesis):
    "Belou (Pierre) du "
    "La Fontaine (Jean) de"

    With Frank's comment above, I understand now that "the dropping particle should be placed in the given name, after any given name (particles placed before the family name are read as a non-dropping particle). That's good to know!! And my problem is solved.
    However - and even if there might not be any use case - what about the parenthesis bug? And why "La" of "La Fontaine" is not appended to the rest of the name as the specs says it should be?

    @l2lafitte: Rien à voir mais dans votre style (lien git ci-dessus), vous indiquez aux lignes 253-254


    => Qu'est-ce qui vous manque exactement? Est-ce que l'ajout d'un champ "NB de pages" pour les "Chapitres de livre" réglerait le problème?
  • Gracile, thanks for adding this. We might as well take care of all of these issues under one roof here.

    These issues will all be addressed in the next processor version (1.0.161), which should feature in the next Zotero release (2.1.7). The new processor version takes advantage of a total reimplementation of names formatting that I completed about a week ago, which is much easier for me to control in the code. It wasn't performing correctly as of last night (it exhibited the same bugs you have both described), but the bugs are gone now.

    I've built a set of five tests to check that the fixes are working correctly. Please review the result strings, the CSL, and the input data in these fixtures to be sure that this is correct. Here are links to the tests: Note that a space is no longer required between an apostrophe-terminated non-dropping-particle and the family name. Also note that a dropping-particle should be entered at the end of the given name field, not at the start of the family name field, as Gracile has picked up.

    The failure of the non-dropping-particle "La" in "La Fontaine" was due to the fact that only lowercase particles were recognized by the parsing function. I've extended this with a heuristic that should catch these: words of two or three characters that begin with uppercase "D", "V" or "L" and are separated from the family name by a space will be treated as non-dropping particles. We'll see whether this causes problems in other contexts; the pattern can be tuned further if it does cause any difficulties.
  • name_ParsedDroppingParticleWithAffixes
    "family": "La Fontaine",
    "given": "Jean de"
    Result: Fontaine (Jean de La)

    => Do you mean that, in the next processor version (1.0.161), the dropping-particle (here "de") will be formatted independently of the given name? Otherwise, I don't see how such a result is possible with these input data (and I'm not sure that there is some use case) since the font-variant attribute is defined for the family-name ("de" is in the given name).
  • Curiously, as you can see in the style referenced above, I didn't mention anything about demote-non-dropping-particle

    and the result is quite different from what Gracile got after coding that parameter.

    AUBIGNAC François Hédelin D’

    - no parenthesis
    - sorting excludes "de" and "d'", which are rejected at the end, but includes LA

    (not mentioning the small-caps that I'm unable to copy here)
  • Magic, isn't it? The particles are parsed out of the fields before the formatting decorations, affixes and punctuation are applied; in effect the Zotero two-field input is exploded into four (actually five, counting the suffix field used for "Jr.", "III" etc.) separate fields, which are handled independently. This was the original concept in citeproc-js; it's just now been properly implemented.

    I'm not sure about use cases; but the CSL specification includes parameters that result in that output, so there it is. :)

    (I've found some more small, unrelated bugs, so 1.0.161 is soon to be superceded by 1.0.162 ...)
  • and the result is quite different from what Gracile got after coding that parameter.
    With demote-non-dropping-particle="display-and-sort"?
    No worry for parenthesis: that's because my custom style includes them...
  • Magic, isn't it?
    No magic performances without magician, ;-)
  • edited May 2, 2011

    Yes, I know you said, and intended, dropping-particle; I just wanted to flag the fact that it should be entered at the end of the given name field; if it goes at the front of the family name, if will be seen as a non-dropping particle -- I inferred that you had it on the family name when you wrote, "To have it recognized as a dropping-particle, I need to add a blank after it to separate it from the main part of the family name". Just a clarification, that's all.

    The difference between Gracile's earlier trials and the tests is due to the failure of the earlier processor to recognize the "La" at the start of "La Bruyere" as a particle at all -- it was just being left in place as a fixed part of the family name, which is incorrect when we have set demote-non-dropping-particle="display-and-sort". To fix such a term as a static part of the name (and therefore not as a particle), the family name field can be enclosed in straight double-quote marks. This will rarely be needed, but it is available as an override.

    The parentheses are just included in the tests to check that affixes behave correctly; you would of course use different CSL in your actual style. The aim here is just to confirm that the processor is correctly interpreting input data and the CSL stylesheet code, so that you can code your style with confidence that a given command produces a well-defined and expected result.
  • sorting excludes "de" and "d'", which are rejected at the end, but includes LA
    According to the specification, this will be the result with demote-non-dropping-particle="never".

    Basically, if anything fails to behave as described in the specification, it's a fault in the processor, and you should not hesitate to call attention to it.
  • @fbennett

    It happens that the author d'Aubignac I told about previously should be treated as :

    AUBIGNAC François Hédelin, abbé d'

    in the bibliography


    François Hédelin, abbé d'Aubignac

    in the footnotes

    Can you make it appear this way ?
    How should I enter it in the data base ?

    Sorry to bother you once again
  • I would enter:
    "family": "Aubignac",
    "given": "François Hédelin, abbé d'"
    But the comma (before "abbé") is going to be problematic here.
  • AUBIGNAC François Hédelin, abbé d'
    Would it be correct to say that dropping-particles, when rendered in this form, should not take the font decorations (text-case, italics, etc) from the family name part?

    If so, what about with normal ordering? I.e.
    François Hédelin, abbé d'AUBIGNAC
    In this case, should the d' be in small-caps, or is it correct in plain roman type?
  • I've decided to go that route for the present, with given-name formatting applied to dropping-particle, and family-name formatting for non-dropping-particle. I've also come up with a parsing solution that does the right thing (I think) with the abbé d'AUBIGNAC. Here are the revised tests -- comments welcome, as always. This has been a very productive discussion.
  • @fbennett,

    François Hédelin, abbé d'AUBIGNAC

    I think the d' should be in plain roman type, since it's a preposition which links abbé and Aubignac.
  • Would roman type also be appropriate for, say, the "de" in Jean de La Fontaine?
  • 1/ From the sources I found, the "de" or "d'" that are to be rejected to the right of the given name (when the family name appears first) should be written in plain roman type.
    That means they don't follow the family-name's rule.

    So, they would have to be:

    a/ entered :
    Family-Name field : La Fontaine
    Given Name field : Jean de

    b/ displayed :
    b-1/ name-as-sort-order: LA FONTAINE Jean de
    b-2/ default: Jean de LA FONTAINE

    where "LA FONTAINE" 's A and ONTAINE are potentially displayed:
    unchanged, small-caps or uppercase , depending on the style specifications.

    2/ If the "de" or "d'" would have to follow the rule of the major part of the family-name, I would expect them to be entered in the family-name field.
  • Great! Thanks for getting back. It looks like the basics are in place now. Let me know if you have an immediate need for Zotero with the updated processor; I can provide an advance copy if required.
  • I can have a look today, then won't have any time left for about 15 days
  • Would roman type also be appropriate for, say, the "de" in Jean de La Fontaine?
    I would write:
    La Fontaine (Jean de)
    Jean de La Fontaine

    (but I'm not an expert...)
  • I certainly wouldn't pretend to be an expert, but I think that "de" or "d'" should not be transformed in capitals or small-caps in either form.

    As far as we are concerned, we use small-caps for the bibliography section, for which we apply the name-as-sort-order parameter, so that the names come out in alphabetic order and more distinct among a long list,

    whereas in the footnotes, where we cite only one (or 2) reference(s), we'd rather use the default form without small-caps, as: Jean de La Fontaine, as we would write it normally, when referring to somebody.
  • edited May 12, 2011
    @Gracile: a few posts above you write:
    I was desperate to get this output:
    "Belou (Pierre du)"
    "La Fontaine (Jean de)"
    Do you need the parentheses, or did you just add these to clarify the point? CSL 1.0 doesn't allow affixes to be set on cs:name-part, but I see no reason why we couldn't allow for that.
  • I needed it but changed my views... But it works as Frank said with:
    <name-part name="given" font-variant="normal" prefix=" (" suffix=".)"/>
    <name-part name="family" font-variant="small-caps"/>

    Indeed, I did not try to validate the style - I think csl specs should be slightly modified to allow affixes here.
  • edited May 24, 2011

    I downloaded the 2.1.6.r9295.

    1/ Concerning AUBIGNAC François Hédelin, abbé d'
    it appears correctly in the footnotes as: François Hédelin, abbé d'Aubignac

    but in the bibliography it appears as: AUBIGNAC François Hédelin abbé d'

    instead of: AUBIGNAC François Hédelin, abbé d'

    (a comma is missing)

    2/ The authors with no given name appear correctly in small capitals

    3/ for another point tested with this release, see:
  • edited May 24, 2011
    I'll take a look at the discrepancy in rendering. It should be possible to bring the comma in for the bibliography as well. Note, though, that we're pushing the limits with this use case; if preserving the comma here causes name formatting to break in other contexts, we may need to reconsider whether this can be supported. But so far, so good.
  • @l2lafitte: Okay, I've checked in a small change that applies equal treatment to the comma in names rendered in sort order. The only remaining issue is the all-caps issue you've reported in the other thread.
Sign In or Register to comment.