Zotero-better-bibtex: Mathematical expressions in a title line

[yoshum]

Would it be possible to add a switch that makes #LaTeX-ed behavior default?

As a physicist, I often see mathematical expressions in a title line but not dollar marks. and so it is not very convenient to add #LaTeX tag to every literature with math in its title. I guess people in physics and other fields of mathematical science would have a similar preference, but maybe some other people would prefer the opposite. So I would be happy if you could add an option that controls the default behavior.

[retorquere]

I'd really rather not add more preferences to BBT (with the attendant extra code). While not fully automated, it is possible to get some support from Zotero to get what you want:

1. Tag at least one reference with #LaTeX
2. In the tag box, click on the colored box besides the tag search and select Display all tags in this library
3. Create a new saved search with Match all of the following:
   
   
   
   • Tag is not #LaTeX
   
   
   • Title contains, $
   
   

You now have a saved search that will always list the references you wanted to have #LaTeXed but aren't; you can select-all on those and drag them onto the #LaTeX tag.

Is that sufficient for your needs?

[yoshum]

It would certainly make it easy to add the #LaTeX tag. Still it means I need to do that once in a few days, which is something I don't want.

[retorquere]

:robot: bleep bloop; this is your friendly neighborhood build bot announcing test build 4355 ("pages cleanup back again").

[retorquere]

You can give 4355 a spin if you want; to activate it you will have to go into Zotero preferences, Advanced Tab, click Config Editor, click I accept the risk, search rawLaTag and change it to *. After that, every reference will behave as if it has #LaTeX set on it.

The config is a little convoluted but it's a one-time thing; I'm still not wholly convinced it is a good idea so I'm not making it an exposed pref right now, but if you could test I can merge it into the release. Note that in raw mode you are wholly responsible for making sure that what's in any Zotero field is valid LaTeX; I do no checks and no conversions on references tagged as raw.

[yoshum]

Thanks. I'll try using it to see how it works.

[retorquere]

I could really use some feedback on this.

[yoshum]

Hi. At this point, changing rawLaTag to * does not seem to have any effect. I don't fully understand how BBT works, but maybe line 55 in resource/Better BibTeX.js is forcing rawLaTag=#LaTeX after it loads the preferences?

I was also considering possible side effects. I was originally thinking of keeping a title as it is in the Zotero field, but now I understand that #LaTeX keeps everything raw. This means that I need to care about the author field which possibly contains non-ascii characters and causes problems with BibTeX.

Considering this situation, possible resolution is something like this: escape all the non-ascii characters while keeping all the ascii characters, including $ and \, untouched. This rule seems strong enough to avoid corrupting math expressions and safe enough to avoid corrupting non-ascii outputs. It may cause some problem when a title contains letters like %, but as far as I look through arxiv.org, people in physics don't seem to use them.

Is it possible to implement this? I am also considering if this can be implemented by using the scripting feature of BBT because I am not 100% sure that this specific rule is really convenient for broad enough range of people.

[retorquere]

:robot: bleep bloop; this is your friendly neighborhood build bot announcing test build 4362 ("gem updates").

[retorquere]

Hi. At this point, changing rawLaTag to * does not seem to have any effect. I don't fully understand how BBT works, but maybe line 55 in resource/Better BibTeX.js is forcing rawLaTag=#LaTeX after it loads the preferences?

Yeah, that's the cause. 4362 should fix that.

I was also considering possible side effects. I was originally thinking of keeping a title as it is in the Zotero field, but now I understand that #LaTeX keeps everything raw.

That's what raw does. It marks a reference to indicate its fields are raw LaTeX, and consequently, I don't touch it.

This means that I need to care about the author field which possibly contains non-ascii characters and causes problems with BibTeX.

Yes.

Considering this situation, possible resolution is something like this: escape all the non-ascii characters while keeping all the ascii characters, including $ and \, untouched. This rule seems strong enough to avoid corrupting math expressions and safe enough to avoid corrupting non-ascii outputs. It may cause some problem when a title contains letters like %, but as far as I look through arxiv.org, people in physics don't seem to use them.

This doesn't feel right to me. It would change the semantics of raw, which would affect an unknown number of people already using it. And some people actually want non-ascii in their references -- not everyone chooses to trust my non-ascii -> LaTeX command translator. It's certainly not something I'm going to do in the midst of the 5.0 rewrite.

Is it possible to implement this? I am also considering if this can be implemented by using the scripting feature of BBT because I am not 100% sure that this specific rule is really convenient for broad enough range of people.

It would be possible in principle to do this in a postscript but it would be pretty complex to get right.

[retorquere]

Oh wait you mean only for the title? Something like this should do what you want:

if (Translator.BetterBibTeX && this.has.title) {
  this.add({ name: 'title', value: this.item.title.replace(/(\$.*?\$)/g, '<pre>$1</pre>'), replace: true });
}

[retorquere]

(this wouldn't require changing the rawLaTag)

[yoshum]

4362 is now working properly with rawLaTag=*.

Oh wait you mean only for the title? Something like this should do what you want:

Cool! Yes, indeed, I am just concerned with the title. Thank you very much for the code!

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