Zotero-better-bibtex: Could page range be cleaned up automatically?

[paultjevdh]

Hi,
Being a sloppy maintainer of my zotero database, and importing references from many different sources as well, I get space and dash- differences in the pages field.
Sometimes there is just one dash between the page numbers, sometimes there are more.
Also the space between the numbers and the dashes can vary.

Better bibtex currently (5.2.16) seems to do no translation of this field and I think (correct me if I'm wrong) a bibtex citation style also cannot remove superfluous space.
I propose to automatically clean up the 'pages' field during export by replacing
<space><number1><space><dash(es)><space><number2><space>
with
<number1><en-dash><number2>

Paul

Report ID:
HNWRJTFW-euc
Exporter used:
better bibtex
Expected behavior:
numberen-dash number
Actual behavior:
no filtering at all, just a copy of the pages field contents

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 5.2.14.5943 ("clean up some dashes")

Install in Zotero by downloading test build 5.2.14.5943, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[paultjevdh]

Hi,
In my test
149-158 becomes pages = {149--158}
123 ---- 432 becomes {123---432}
Paul

[retorquere]

The first is because I assume that to be a page range, and https://tex.stackexchange.com/questions/58668/why-should-i-use-in-pages-field-of-a-bibtex-entry. The second is because 4 dashes don't mean anything in latex (or citeproc - it also looks strange in a zotero-generated bibliography), and a triple-hyphen (em-dash) seems to come closest to the input.

[paultjevdh]

When I google en-dash and em dash, I understand that the proper character for a page range is the en-dash.
One dash is considered an error by the test build, and fixed by adding the missing dash.
I think 3 dashes should also map to two dashes, to end up with an en-dash in latex. I don't see the difference with the single dash, both are syntactically valid, but bad practice.
I understand your argument against replacing 4 dashes, it wasn't a very serious example, but still possible...
Paul

[retorquere]

Anything is possible in the pages field, as it's free-form text, but I haven't seen it ever in any of the samples that were submitted to me.

I'd very much prefer it if you could submit serious samples. I'd rather not bake in behavior based on synthetic samples unless those synthetic samples point out an actual bug. Dash-replacement is more an aesthetic judgement than a bug, and at some point (that we may already have gone past) it becomes the responsibility of the user to make sure the zotero entries contain sensible data. If the 4 dashes do not come from an import but you've put them there deliberately, who is BBT to judge you don't actually want them there?

[qqobb]

Looking at https://github.com/retorquere/zotero-better-bibtex/commit/a6796ad481719d4f904d4ddcbb7b8cfef6f90da6, I think that a space after a comma should be kept, e.g., for

pages = {20, 1--14}

[paultjevdh]

Ok, this makes sense.
Thanks for your time.

Paul

[retorquere]

@qqobb working on that.

[retorquere]

@qqobb would you expect the space to be retained, or added?

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 5.2.14.5963 ("keep spaces after comma")

Install in Zotero by downloading test build 5.2.14.5963, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

[njbart]

My view is, while it’s probably safe to remove spaces in patterns like “number(s) space hyphen(s) space number(s)“ in pages fields (though some nagging doubts remain), spaces after commas as well as pretty much everything else in a pages field should definitely be retained unchanged.

For example, /usr/local/texlive/2019/texmf-dist/bibtex/bib/beebe/tugboat.bib on my machine contains pages = "{c\,3}-{c\,3}", which would no longer be formatted as intended if spaces after commas were added.

A similar (though admittedly hypothetical) example would be a page numbering pattern along the lines of A,7–A,11. (Note that similar patterns such as G--i--G--v, G-1--G-28, M-1--M-14 do occur in bib files that come with TeX Live as well as in books in the wild.)

As you said yourself, above, ultimately it’s “the responsibility of the user to make sure the zotero entries contain sensible data.”

[retorquere]

The replacement is currently pretty picky - I split on ,<spaces> (which is subsequently replaced by ,<space>), and of the chunks that sit between us them, only those exactly matching number - number would be changed. 7-A should be safe.

[retorquere]

c<thin space>3-c<thin space>3 wouldn't be picked up for change -- this conversion affects BBT export only, and in Zotero, you either wouldn't have {c\,3}-{c\,3} (and also, it wouldn't be changed because the text between the commas doesn't match <number><optional spaces><hyphens><optional spaces><number>), or you'd have it surrounded by <script> tags, which is always just passed through as-is.

None of G--i--G--v, G-1--G-28, M-1--M-14 would be picked up by the dash mangler.

[retorquere]

5963 retains space after comma but does not insert it if it's not there.

[retorquere]

@njbart do you have samples at hand for the cases you mention so I can add them to my test suite? I'm prepping for a new release.

[qqobb]

Sorry for replying late. I agree with @njbart's comments, but don't have strong opinions. As written in https://tex.stackexchange.com/a/58671 linked to above, many BibTeX style files (.bst) take care of the pages field, e.g., replacing - by -- to produce an en-dash. So at least some of the issues here might already be taken care of by the style you use. Generally, avoiding automatic "corrections" might be desirable for code simplicity and user control of the output. Trying to keep the translation on a letter-by-letter basis where possible might be a good design choice. But the transformations here seem moderate, so it might be ok to include them. An alternative might be to move this to a postscript which users could find in the documentation.

[retorquere]

the cleanup behavior is pretty old in BBT (although this extends it a bit), if I removed it entirely behavior would change for existing users. I'd rather not do that, I'm going to schedule a release with what I have now.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.