Zotero-better-bibtex: Unicode "ø" in author name is exported with trailing space which does not work in bibtex

[henrikh]

Report ID: G6NWLYL4-euc

Exporter used: betterbibtex

Expected behavior: "ø" is exported as {\o} making spacing right.

Actual behavior: "ø" is exported \o. Which doesn't work in MiKTeX as per #69

[retorquere]

Sorry about that. I'll get you a fix in the weekend. Maybe tonight, but that I can't promise.

[retorquere]

Not that this will stand in the way of that fix on the BBT end, but is this not something that MiKTeX intends to fix? It's a little strange I think. Is this discussed for MiKTeX somewhere?

[henrikh]

No need to rush for my sake :) I'll perhaps just switch to TeXLive to handle it.

I'll see how to make a bug report to MiKTeX.

[retorquere]

This weekend is doable. I know what I have to do, I just need an hour to modify the tests mostly.

[retorquere]

Is this bibtex specific? Or is biblatex affected too in MikTeX?

[retorquere]

And this is specific to author names? Other fields like titles are not affected?

[henrikh]

I’m not sure.

I can test it more thoroughly tomorrow.

On Sat, 6 Jun 2020 at 15.48, Emiliano Heyns [e-mail]
wrote:

And this is specific to author names? Other fields like titles are not
affected?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/retorquere/zotero-better-bibtex/issues/1538#issuecomment-640064085,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAVORE6ZW6C6TIF3JAGV53RVJCLFANCNFSM4NTMWM3Q
.

[henrikh]

I've made a minimal example which exhibits the desired behavior on my computer _and_ on Overleaf: link is here: https://www.overleaf.com/read/csphznvkznyx

I think it is a bibtex/bibliography issue and not BetterBiblatex, but as seen simply having \o will not work in one scenario. It is only on the author name when the format last, first is used in the author list.

[henrikh]

A temporary workaround is to set BBT to export unicode -- that seems to work fine.

I also checked the file generated by bibtex. It is bibtex which inserts a non-breaking space.

[retorquere]

OK, so if I'm reading this sample correctly, this problem is particular to bibtex author names (when the author names are written as Family, Given). This is great news, because I already treat bibtex author names differently for other reasons, so this can be a very localized fix.

What I had absolutely not expected is that this:

 author = {S\o{}ren, Space}

also inserts a space there, and that is, as far as I'm concerned, unequivocally wrong.

But if I interpret this sample correctly (that this problem is restricted to bibtex, not biblatex, author names), then that's an easy fix. I'm working on the implementation, but it'd be great to get your confirmation on that.

As an aside, you can construct such MWEs as a single file:

\documentclass{article}

\usepackage{filecontents}
\begin{filecontents*}{\jobname.bib}
@inproceedings{ABC,
  title = {A\o c {A\o c} A{\o}c},
  author = {S\o{}ren, Space and {S\o ren}, Enclosed and S{\o}ren, Unit and Søren, Unicode and Normal S\o ren},
  year = {2020},
  pages = {2},
  lccn = {abc}
}
\end{filecontents*}

\begin{document}

s\o s\cite{ABC}

\bibliographystyle{plain}
\bibliography{\jobname}

\end{document}

[retorquere]

The test suite is running and a build will drop here in 15 minutes or so.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 5.2.26.6647 ("two-stage tests")

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

[retorquere]

Can you try 6647?

[henrikh]

Amazing! @retorquere I just tested it and it seems to work perfectly!

[retorquere]

So fixed? This change only affects creator fields (author, editor, etc), for bibtex, not biblatex. All other circumstances use to regular latex generation with spaces to end commands when followed by text.

[henrikh]

I've only found it to affect author field. I suspect that it is a bug when bibtex reorders to first and last name. At least when I dig into the bibtex output, that seems to be the case.

Also, one small request, in these two files could you remove the "note" field from these example bibliography entries:

https://github.com/retorquere/zotero-better-bibtex/compare/gh-1538#diff-f359c9dc6c670e83bc2fca2f7e1995b9

https://github.com/retorquere/zotero-better-bibtex/compare/gh-1538#diff-d9d84ebbe604d3e4c380d4409dd76d4a

I didn't notice that it was included in the delivered output from Zotero.

[retorquere]

That's only because I have the "export notes" option on during that export. If it's off, those don't appear.

[retorquere]

I'd still say this is a bug in bibtex, but since I already treat bibtex creator names differently, I'm happy to release this.

[henrikh]

Thanks! And thanks for being super helpful :) Just tell me if there is something else I can help with :)

[retorquere]

Nope, that should be it, I'm prepping a new release

[Edmundod]

I'm experiencing the same problem with polish letter ł. Let's consider a name Michał Truchło, exported to bib file it becomes Truch\l o, Micha\l{}, which gives M. Truchł o. It looks like a surname is not processed correctly. On the other hand for name Paweł I have both Pawe\l and Pawe\l{} in different references, so tbh I'm a little bit lost. EDIT: OK, for Paweł I realized that it depends on the position, if there is some word behind it than {} is added.

Not sure if I should start new issue.

[retorquere]

@Edmundod do you still experience this with 5.2.28? Because 5.2.28 was not a targeted fix for \o; it should have fixed all commands in creator names that would previously rely on a closing {} or following space. So I really need to know whether you still experience this problem after upgrading, and if so, I'll need a debug log from right-clicking the item that exhibits the problem.

[Edmundod]

Indeed, I had 5.2.26, but with 5.2.28 it is working perfectly. Sorry for the trouble and thank you for your work :)

[retorquere]

That's alright, thanks for letting me know.

[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.