typst / hayagriva

Rusty bibliography management.
Apache License 2.0
312 stars 47 forks source link

"Available" Field for Paper in IEEE Style. #80

Open stellarpower opened 9 months ago

stellarpower commented 9 months ago

I am currently exporting my bibliography from Zotero in bibtex form to use in Typst - so admittedly, I may well have some problems in Zotero/with that pipeline.

However, when citing journal articles in the IEEE style, Hayagriva is including the URLs I used to access those - which is something I have been told should not be included in my bibliography for the document I am writing, when the source is already part of a journal or other source that can be found canonically using the other information present.

If this is on me and the format of my bibtex file, then more than happy for this issue to be closed - but in case others are experiencing this and the output style of Hayagriva possibly needs to be looked at, thought I would raise.

Thanks!

zepinglee commented 9 months ago

Can you provide the exported .bib entry?

The ieee.csl implements Reference Guide of IEEE Editorial Style Manual where the subsection "Periodicals Online" describes the cases with URLs.

Screenshot 2023-11-14 at 14 20 48

A possible solution is using the Better BibTeX plugin and setting the option "Add URLs to BibTeX export" to "no".

stellarpower commented 9 months ago

So far, I have tried using Better Bibtex, but this has been causing more problems in other areas (e.g. backslashes and latex instead of unicode in the text) than the built-in Zotero plugin, and sometimes Hayagriva panics. (As an aside, I opened an issue asking if Better Bibtex would consider Hayagriva support, but it sounds like the maintainer would prefer Hayagriva to support CSL input. I'm not sure where the boundaries lie exactly internally, but seems fair comment.)

I have brought up the bibliography; using the latest release on the Typst web app, it doesn't seem to be reproducing immediately in a minimal example - so possibly has changed since CSL support was added for styles. I will keep an eye out if it comes up again, but if CSL is now in the master branch and this is definitely the way forward, then I'm happy for this to be closed.

Thanks!

zepinglee commented 9 months ago

I've noticed your issue https://github.com/retorquere/zotero-better-bibtex/issues/2711.

It seems more natural for hiyagriva to directly support CSL-JSON/YAML data. Hope to hear from the maintainer about future plan.

retorquere commented 9 months ago

So far, I have tried using Better Bibtex, but this has been causing more problems in other areas (e.g. backslashes and latex instead of unicode in the text)

You can disable this in the BBT preferences, but this just means Hayagriva doesn't really support bib(la)tex. There are some constructs that must use latex commands if you want them in the output (like a literal backslash, or a percent sign), and these will be exported as valid TeX commands even if you turn unicode mode on for BibTeX. Better BibLaTeX has unicode mode as the default. But if eg \% turns up in your bib(la)tex and that in turn shows up as \% instead of % in your rendered bibliography, then Hayagriva superficially may seem to support bib(la)tex, but it in fact does not. e.g. this:

@article{x,
  title = {title with a % sign, or an _nderscore}
}

is simply not valid bib(la)tex, and it should be impossible to generate this with a program that claims to produce bib(la)tex.

reknih commented 9 months ago

So far, I have tried using Better Bibtex, but this has been causing more problems in other areas (e.g. backslashes and latex instead of unicode in the text) than the built-in Zotero plugin, and sometimes Hayagriva panics.

Please open some issues for the panics!

In terms of the URLs, Hayagriva behaves in a CSL-spec-compliant way here. However, we could introduce an option to always suppress URLs for "formally published" items