typst / biblatex Goto Github PK

View Code? Open in Web Editor NEW

119.0 5.0 14.0 386 KB

A Rust crate for parsing and writing BibTeX and BibLaTeX files.

License: Apache License 2.0

Rust 54.58% TeX 45.42%

biblatex bibliography rust-crate bibtex

biblatex's Issues

Missing Reserved Char Escapes

The characters '#', '~', and '^', are missing from the escape code here:

https://github.com/typst/biblatex/blob/main/src/resolve.rs#L387

These appear to be special characters:

http://latexref.xyz/Reserved-characters.html

The following entry when parsed Bibliography::parse() and then written out with bibliograph.to_bibtex_string()

let src = r#"
        @article{Monroe2022,
	author = {Monroe, Brian Albert},
	journal = {Working Paper},
	keywords = {Beliefs,Risk aversion},
	pages = {1--66},
	title = {Estimating Beliefs by Event Space Bisection \#1},
	year = {2022},
	}
"#;

results in the following bibtex string:

@article{Monroe2022,
author = {Monroe, Brian Albert},
journal = {Working Paper},
keywords = {Beliefs,Risk aversion},
pages = {1--66},
title = {Estimating Beliefs by Event Space Bisection \\#1! },
year = {2022},
}

Note the double backslash before the # character in the title field. This causes biber to fail to compile the document.

(/usr/share/texmf-dist/tex/latex/biblatex/lbx/english.lbx)) (./main.bbl
! Illegal parameter number in definition of \NewValue.
<to be read again>
                   1
l.43 ...ng Beliefs by Event Space Bisection \\#1!}

Error when encountering bibtex comments

I have created a biblatex bibliography file in JabRef and would like to use hayagriva to format reference lists from that. However, with the new version 0.2.1 of hayagriva, I get the following error message:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: [Parse(ParseError { span: 98803..98803, kind: Expected(Comma) })]'

The line indicated by the error span is

@Comment{jabref-meta: databaseType:biblatex;}

which is valid bibtex syntax.

I believe biblatex needs to be updated to support bibtex's @Comment syntax. Previously, with hayagriva version 0.1.1, there was no issue.

Parsing error on unprotected numbers

The following bibtex is valid but trigger a parsing error (unknown abbreviation "2020": 274-278):

@article{bullshit2020,
    title={At-scale impact of the {Net Wok}: A culinarically holistic investigation of distributed dumplings},
    author={Astley, Rick and Morris, Linda},
    journal={Armenian Journal of Proceedings},
    volume={61},
    pages={192--219},
    year=2020,
    publisher={Automattic Inc.}
  }

The problem comes from the value of the "year" field which is not enclosed (which is allowed in bibltex and found in many places).

Support `/` as an entry key delimiter

A BibLaTeX entry key, of the form name1/name2 currently fails:

@online{baez/online,
  author       = {Baez, John C. and Lauda, Aaron D.},
  title        = {Higher-Dimensional Algebra {V}: 2-Groups},
  date         = {2004-10-27},
  version      = 3,
  langid       = {english},
  langidopts   = {variant=american},
  eprinttype   = {arxiv},
  eprint       = {math/0307200v3},
}

Reference: biblatex-examples.bib

Improve error messages

When using typst, the error messages received by the biblatex crate are not good yet.

For example this code:

@article{asdf,
  month     = {Sep--Oct},
}

Produces the following error in typst:

Failed to parse BibLaTeX file (test.bib:1: invalid number)

In issue typst/typst#2849 I was informed, that this partially relies on the biblatex crate not yet being able to return good error messages.

This issues purpose is to track this :)

-- and --- aren't turned into en and em-dashes in the bibliography

Description

@Article{Doe58Knitting,
  author  = {Doe, John},
  journal = {International Journal of Underwater Basket Weaving},
  title   = {Knitting A--Z --- A practical guide},
  year    = {1958},
}

is rendered as

Reproduction URL

No response

Operating system

No response

Typst version

I am using the latest version of Typst

Certain LaTeX text accents are incorrectly displayed

Consider the following code

use biblatex::Bibliography;

fn main() {
    let src = r"@article {test, author = {L\^{e} D\~{u}ng Tr\'{a}ng}}";
    let bibliography = Bibliography::parse(src).unwrap();
    let entry = bibliography.get("test").unwrap();
    let author = entry.author().unwrap();
    println!("{}", author[0]);
}

When run, this code prints

L^e D~ung Tráng

The correct output should be

Lê Dũng Tráng

Supporting or at least removing hyphenation marks

BibLaTeX supports defining hyphenation with \-. I don't know if this library should really support custom hyphenation, but these marks could be at least removed from the output.

Here is an example:

@inproceedings{hyphenation,
  author = {Some One},
  title = {Strange Words like Win\-dows or Wash\-ing\-ton},
}

Just showing @hyphenation.

#bibliography("./broken.bib")

Support wider `biblatex` key syntax `Author:YYYY`

Currently biblatex supports key entries like Lehanneur:2021. typst fails silently and never renders the citation properly when using the syntax like: @Lehanneur:2022[p.~7]. It'd be great if it's supported in the future, thanks for your amazing work! 🚀

Panic when getting authors from entry

When creating an entry with an author, the call to "get" the author results in a panic. See the below MWE and stacktrace. Expected behavior is that I get a Result<Vec<Person>, RetrievalError>. Please let me know if I've made a mistake or if you need more information. Thanks a bunch!

Cargo version: cargo 1.64.0 (387270bc7 2022-09-16)
OS: Arch Linux
Kernel: 5.19.11-arch1-1

use biblatex::{
	Entry,
	EntryType,
	Person,
};

fn main() {
	let mut e = Entry::new("Test123".to_owned(), EntryType::Article);
	let v = vec![
		Person {
			name: "Brian Albert".to_string(),
			given_name: "Monroe".to_string(),
			prefix: "".to_string(),
			suffix: "".to_string(),
		},
	];
	e.set_author(v);
	// Prints fine, shows the author field
	println!("{:?}", e);
	// Works
	println!("{:?}", e.get("author"));
	// Panics
	println!("{:?}", e.author());
}

And the following stacktrace:

Entry { key: "Test123", entry_type: Article, fields: {"author": [Normal("Brian Albert, Monroe")]} }
thread 'main' panicked at 'attempt to add with overflow', /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/chunk.rs:319:19
stack backtrace:
   0:     0x55c840c8176d - std::backtrace_rs::backtrace::libunwind::trace::h9135f25bc195152c
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55c840c8176d - std::backtrace_rs::backtrace::trace_unsynchronized::h015ee85be510df51
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55c840c8176d - std::sys_common::backtrace::_print_fmt::h5fad03caa9652a2c
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x55c840c8176d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h2b42ca28d244e5c7
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x55c840c9c99c - core::fmt::write::h401e827d053130ed
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/fmt/mod.rs:1198:17
   5:     0x55c840c7f941 - std::io::Write::write_fmt::hffec93268f5cde32
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/io/mod.rs:1672:15
   6:     0x55c840c82e45 - std::sys_common::backtrace::_print::h180c4c706ee1d3fb
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x55c840c82e45 - std::sys_common::backtrace::print::hd0c35d18765761c9
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x55c840c82e45 - std::panicking::default_hook::{{closure}}::h1f023310983bc730
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:295:22
   9:     0x55c840c82b61 - std::panicking::default_hook::h188fec3334afd5be
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:314:9
  10:     0x55c840c833d6 - std::panicking::rust_panic_with_hook::hf26e9d4f97b40096
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:698:17
  11:     0x55c840c83289 - std::panicking::begin_panic_handler::{{closure}}::hfab912107608087a
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:586:13
  12:     0x55c840c81c64 - std::sys_common::backtrace::__rust_end_short_backtrace::h434b685ce8d9965b
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x55c840c82ff9 - rust_begin_unwind
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
  14:     0x55c840c38703 - core::panicking::panic_fmt::ha6dc7f2ab2479463
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
  15:     0x55c840c385cd - core::panicking::panic::hb3ad04c589a0e3c8
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
  16:     0x55c840c576f0 - biblatex::chunk::split_values::h4d52133d545a6007
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/chunk.rs:319:19
  17:     0x55c840c56e27 - biblatex::chunk::split_at_normal_char::h46c918bcbef07953
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/chunk.rs:280:28
  18:     0x55c840c4051c - biblatex::types::person::Person::parse::hc861f97c54e13198
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/types/person.rs:43:32
  19:     0x55c840c41f5d - biblatex::types::person::<impl biblatex::types::Type for alloc::vec::Vec<biblatex::types::person::Person>>::from_chunks::{{closure}}::h0a64543c3d982ca1
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/types/person.rs:221:30
  20:     0x55c840c596ae - core::iter::adapters::map::map_fold::{{closure}}::h2f6fd505fd85c775
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/iter/adapters/map.rs:84:28
  21:     0x55c840c4ebcb - core::iter::traits::iterator::Iterator::fold::h1045c3e0572ae2d7
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/iter/traits/iterator.rs:2414:21
  22:     0x55c840c57fa8 - <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::h588616f25e1170a2
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/iter/adapters/map.rs:124:9
  23:     0x55c840c592de - core::iter::traits::iterator::Iterator::for_each::h9386ffc17baeb57d
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/iter/traits/iterator.rs:831:9
  24:     0x55c840c4b325 - <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend::h0f1bdd838ea454c0
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/alloc/src/vec/spec_extend.rs:40:17
  25:     0x55c840c48da8 - <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter::hcbd80a2ac9be7ddd
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
  26:     0x55c840c4a2f3 - alloc::vec::in_place_collect::<impl alloc::vec::spec_from_iter::SpecFromIter<T,I> for alloc::vec::Vec<T>>::from_iter::h0df5cdbba0401372
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/alloc/src/vec/in_place_collect.rs:164:20
  27:     0x55c840c4b131 - <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter::hea1d7551e67b6486
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/alloc/src/vec/mod.rs:2648:9
  28:     0x55c840c59199 - core::iter::traits::iterator::Iterator::collect::h054887cac5c43957
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/iter/traits/iterator.rs:1836:9
  29:     0x55c840c4b828 - biblatex::types::person::<impl biblatex::types::Type for alloc::vec::Vec<biblatex::types::person::Person>>::from_chunks::hc2e9baf94cea8134
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/types/person.rs:219:12
  30:     0x55c840c3ae1b - <[biblatex::Spanned<biblatex::chunk::Chunk>] as biblatex::chunk::ChunksExt>::parse::haa020cfb3ca8d571
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/chunk.rs:98:9
  31:     0x55c840c3b7ac - biblatex::Entry::author::hd1e0e159f9f62231
                               at /home/bam/.cargo/registry/src/github.com-1ecc6299db9ec823/biblatex-0.6.2/src/macros.rs:6:17
  32:     0x55c840c3982c - bibtest::main::h4e73a55957b7c62d
                               at /tmp/bibtest/src/main.rs:23:19
  33:     0x55c840c39efb - core::ops::function::FnOnce::call_once::h11e9d1b62a55ac4f
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
  34:     0x55c840c38eee - std::sys_common::backtrace::__rust_begin_short_backtrace::h02ae98d2d10c74e7
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:122:18
  35:     0x55c840c3a441 - std::rt::lang_start::{{closure}}::h6ddf68b8bf01581f
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/rt.rs:145:18
  36:     0x55c840c7cc8e - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hcdfee62722e5e4b8
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:280:13
  37:     0x55c840c7cc8e - std::panicking::try::do_call::h84ca51609826746f
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:492:40
  38:     0x55c840c7cc8e - std::panicking::try::hd58075e533b8e0cb
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:456:19
  39:     0x55c840c7cc8e - std::panic::catch_unwind::h1ebac24d83cb6ce2
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panic.rs:137:14
  40:     0x55c840c7cc8e - std::rt::lang_start_internal::{{closure}}::h0145388a1edd1640
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/rt.rs:128:48
  41:     0x55c840c7cc8e - std::panicking::try::do_call::h7630182e534a0a32
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:492:40
  42:     0x55c840c7cc8e - std::panicking::try::h05b6544f0c6331dc
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:456:19
  43:     0x55c840c7cc8e - std::panic::catch_unwind::h77b2ba8fd3309f34
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panic.rs:137:14
  44:     0x55c840c7cc8e - std::rt::lang_start_internal::h6612c8a7a6861b8b
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/rt.rs:128:20
  45:     0x55c840c3a410 - std::rt::lang_start::h89e20cedb11bae07
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/rt.rs:144:17
  46:     0x55c840c3991c - main
  47:     0x7f61df9fc290 - <unknown>
  48:     0x7f61df9fc34a - __libc_start_main
  49:     0x55c840c38995 - _start
                               at /build/glibc/src/glibc/csu/../sysdeps/x86_64/start.S:115
  50:                0x0 - <unknown>

Formulas are rendered incorrectly

Source:

@article{NewBrunerie,
  title = {Formalizing $π_4(bb(S)^3) ≅ bb(Z)/(2 bb(Z))$ and Computing a Brunerie Number in Cubical Agda},
  author = {Axel Ljungström and Anders Mörtberg},
  year = 2023,
  url = {https://arxiv.org/abs/2210.08232},
}

I wish the formula can be rendered as typst code.

Pages and volume parse errors

I'm moving here the issue typst/typst#210.

Compilation fails if the bibliography (.bib) file has an entry such as this:

@article{1,
    title = {A},
    number = {B4},
    pages = {B97},
    volume = {40-42},
    price = {$76.60}
}

Parse errors due to letters ("B") in pages and "-" in volume. Also fails on price with unexpected end of file due to the dollar. No error due to "B" in number.

I think this entry should be valid as I have official bib entries with ranges on volume and letters on pages.

Repeated keys in input .bib files

I was running some tests and found the following.

I manually counted that tests/gral.bib has 85 entries. But after running parse the resulting Bibliography has 83 entries. I tracked down 2 entries that have repeated keys in the file, these are:

@inproceedings{kim2009,
  title={Sewersnort: A drifting sensor for in-situ sewer gas monitoring},
  author={Kim, Jihyoung and Lim, Jung Soo and Friedman, Jonathan and Lee, Uichin and Vieira, Luiz and Rosso, Diego and Gerla, Mario and Srivastava, Mani B},
  booktitle={2009 6th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks},
  pages={1--9},
  year={2009},
  organization={IEEE}
}

@INPROCEEDINGS{kim2009,
  author={J. {Kim} and J. S. {Lim} and J. {Friedman} and U. {Lee} and L. {Vieira} and D. {Rosso} and M. {Gerla} and M. B. {Srivastava}},
  booktitle={2009 6th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks},
  title={SewerSnort: A Drifting Sensor for In-situ Sewer Gas Monitoring},
  year={2009},
  volume={},
  number={},
  pages={1-9}
}

and:

@article{ishihara2012,
  title={Active node selection in flowing wireless sensor networks},
  author={Ishihara, Susumu and Sato, Daisuke},
  journal={Proc. 6th ICMU},
  pages={8--15},
  year={2012}
}


@inproceedings{ishihara2012,
  title={Active node selection in flowing wireless sensor networks},
  author={Ishihara, Susumu and Sato, Daisuke},
  booktitle={Proceedings of the 6th International Conference on Mobile Computing and Ubiquitous Networking (IMCU)},
  pages={8--15},
  year={2012}
}

The parse method just keeps the second one. I guess this is because of how the insert method works in a HashMap / BTreeMap.

Is this intended behavior? I don't think parse should assume that the latter one is the correct entry, perhaps the user wishes to keep the first one if asked, or to change one key and keep both. I see two possible solutions:

1- parse errors out in this case

2- keep both entries, but automatically put a (1) after the key of the second one (or (2) if there are already 2 of the same, etc.). This solution would also play nicely with my library, since handling this type of repetitions is precisely what it is designed to do. If we go this route, I have a similar function for doing that (see fn get_new_citation_key in line 173). I could adapt it and make a pull request here.

Have Bibliography::parse return Result instead of Option?

Hi, I'm the author of this crate, which uses biblatex: https://github.com/ariroffe/bib-unifier

I was testing it with some real files, which some colleagues gave me, and Bibliography::parse was returning None and failing to parse some of them. I managed to track down the issue to the following entry, which those files contained:

@inproceedings{conigliocorbalan,
  author    = {Marcelo Coniglio and Mar{\'{\i}}a I. Corbal{\'{a}}n},
  title     = {Sequent Calculi for the classical fragment of {B}ochvar and {H}alld{\'{e}}n's {N}onsense {L}ogics},
  booktitle = {Proceedings Seventh Workshop on Logical and Semantic Frameworks, with Applications, {LSFA} 2012, Rio de Janeiro, Brazil, September 29-30, 2012.},
  pages     = {125--136},
  year      = {2012},
}

The problem is merely that there is an extra \ before the i in Mar{\'{\i}}a. When that backlash is removed, the files parse correctly.

The thing is, parse was failing completely, without any explanation as to why, so all I can tell the end user is that there was a problem parsing that file. I'm new to Rust, and maybe this too much to ask, but would it not be more appropriate if parse returned a Result instead of an Option? (or at least to have another method that does return a Result). The Err variant could then detail which part of the original file was the cause of the parsing failure. I believe this could help users of the library such as myself.

Whitespaces in field value

This parser produces extra whitespaces if the field value is in multiple lines. Yet BibTeX/Biber compresses whitespaces in field value to a single space and removes leading or trailing whitespaces.

@article{aksin,
  title        = {Effect of immobilization on catalytic characteristics of
                  saturated {Pd-N}-heterocyclic carbenes in {Mizoroki-Heck}
                  reactions},
}

---- tests::test_whitespaces stdout ----
Bibliography {
    entries: [
        Entry {
            key: "aksin",
            entry_type: Article,
            fields: {
                "title": [
                    Normal(
                        "Effect of immobilization on catalytic characteristics of\n                  saturated ",
                    ) <34..119>,
                    Verbatim(
                        "Pd-N",
                    ) <120..124>,
                    Normal(
                        "-heterocyclic carbenes in ",
                    ) <125..151>,
                    Verbatim(
                        "Mizoroki-Heck",
                    ) <152..165>,
                    Normal(
                        "\n                  reactions",
                    ) <166..194>,
                ],
            },
        },
    ],
    keys: {
        "aksin": 0,
    },
}

Some commands do not get parsed

The following bibtex returns TCP\textquotesingle s Third Eye: Leveraging eBPF for Telemetry-Powered Congestion Control. Note that the \textquotesingle command is ignored.

@inproceedings{Hinz2023,
  doi = {10.1145/3609021.3609295},
  url = {https://doi.org/10.1145/3609021.3609295},
  year = {2023},
  month = sep,
  publisher = {{ACM}},
  author = {J\"{o}rn-Thorben Hinz and Vamsi Addanki and Csaba Gy\"{o}rgyi and Theo Jepsen and Stefan Schmid},
  title = {{TCP}{\textquotesingle}s Third Eye: Leveraging {eBPF} for Telemetry-Powered Congestion Control},
  booktitle = {Proceedings of the 1st Workshop on {eBPF} and Kernel Extensions}
}

Distinguishing address (publisher-place) and location (event-place)

According to the ACM reference format:

For a (paginated proceedings) article in a conference proceedings (conference, symposium or workshop):

@inproceedings{Andler:1979:PPE:567752.567774,
    author = {Andler, Sten},
    title = {Predicate Path Expressions},
    booktitle = {Proceedings of the 6th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages},
    series = {POPL '79},
    year = {1979},
    location = {San Antonio, Texas},
    pages = {226--236},
    numpages = {11},
    url = {https://doi.org/10.1145/567752.567774},
    doi = {10.1145/567752.567774},
    acmid = {567774},
    publisher = {ACM},
    address = {New York, NY, USA},
}

Should be rendered to:

[1] Sten Andler. 1979. Predicate path expressions. In Proceedings of the 6th. ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (POPL '79), January 29 - 31, 1979, San Antonio, Texas. ACM Inc., New York, NY, 226-236. https://doi.org/10.1145/567752.567774

However, in current implementation location and address are defined to be aliases.

biblatex/src/lib.rs

Line 761 in 6dcd4ee

location: "location" | "address",

One way to make the above rendering possible is to separately map location into CSL's event-place and map address into CSL's publisher-place. As mentioned in CSL specification appendix:

publisher
Publisher

publisher-place
Geographic location of the publisher
...

event-title
Name of the event related to the item (e.g. the conference name when citing a conference paper; the meeting where presentation was made)

event-place
Geographic location of the event related to the item (e.g. “Amsterdam, The Netherlands”)

Put empty lines between entries in the string generated from `to_bibtex_string()` and `to_biblatex_string()`

Sorry to be such a burden but I am actively working on something that uses this library. This is a mini issue.

The output of to_bibtex_string() and to_biblatex_string() lists entries one directly after the other, with no whitespace inbetween, which isn't very pleasing to the eye. I think it would be nicer if the methods put a space between them.

I think that all that would need to be changed is:
lib.rs, line 199: biblatex.push('\n'); ==> biblatex.push_str("\n\n");

And the same in line 217 for bibtex.

error: failed to parse BibLaTeX file (../zotero-autoexport.bib:28: unknown editor type)

Error:

error: failed to parse BibLaTeX file (../zotero-autoexport.bib:28: unknown editor type)

Offending biblatex entry, as generated by zotero-better-bibtex

@video{acerolaThisDifferenceGaussians2022,
  entrysubtype = {video},
  title = {This Is the {{Difference}} of {{Gaussians}}},
  editor = {{Acerola}},
  editortype = {director},
  date = {2022-12-24},
  url = {https://www.youtube.com/watch?v=5EuYKEvugLU},
  urldate = {2023-09-16},
  abstract = {In the realm of image based edge detection, aesthetically pleasing edges are hard to come by. But, what if we could get stylized edge lines by just blurring our image twice? Download my GShade shader pack! https://github.com/GarrettGunnell/Ace... Patreon: https://www.patreon.com/acerola\_t Twitter: https://twitter.com/Acerola\_t Twitch: https://www.twitch.tv/acerola\_t Code: https://github.com/GarrettGunnell/Pos... Join My Discord Server! https://discord.gg/FxGQvbfm6Y References: https://users.cs.northwestern.edu/\textasciitilde sc... Music: Sandgem Town (Day) - Pokemon Diamond OST Joy - Persona 3 During The Test - Persona 3 Afternoon Break - Persona 3 This Mysterious Feeling - Persona 3 Muscle Blues - Persona 4 Like A Dream Come True - Persona 4 Soft Oversight - Sonny Boy OST Summer Storm - Sonny Boy OST ソウとセイジ - Sonny Boy OST arrow in thumbnail drawn by thlurp Thanks for watching! This video is dedicated to my friend, Alotryx. \#acerola \#graphics \#gamedev \#unity3d \#graphics \#shaders}
}

Removing the editor = ... line fixes the issue.

Desired solution

ignore or dump all unrecognized entries into a hashmap and raise a warning,

and optionally

handle the editor tag for @video

Multiline author fields not parsed correctly

Thank you for making this package. For bibtex entries where the author field has linebreaks, the authors aren't parsed correctly in some cases. Here is an example:

fn main() -> Result<(), Error> {
  let src = r#"
@article{Monroe,
  author = {
    Monroe, Brian Albert and
    Doe, John
  },
  title = {Estimating Beliefs by Event Space Bisection},
  year = {2022},
  }
"#;

    let biblio = Bibliography::parse(src).unwrap();
    let entry = biblio.get("Monroe").unwrap();
    let author = &entry.author().unwrap()[0];
    println!("name: ({}) given: ({}) prefix: ({}) suffix: ({})",
             author.name,
             author.given_name,
             author.prefix,
             author.suffix);

    Ok(())
}

This prints:

name: (Monroe) given: (John
  ) prefix: () suffix: (Brian Albert and
    Doe)

The problem seems to go away if in the bibtex file, we put a space after "and".

Support verbatim fields

Hello,

Many thanks for your work on the biblatex crate. I use it in a little converstion tool: https://codeberg.org/mutluyuz/csv2bibtex

When working with the crate, I noticed that it does not support verbatim fields right now (like url or file). See this discussion on stackexchange: https://tex.stackexchange.com/questions/177201/bibtex-biblatex-verbatim-fields-and-special-characters

Would it be possible to support such unescaped fields as well (in their verbatim mode)?

Thanks for your help!

Bibtex containing unbalanced dollar symbol in `url`

Description

When using a BibTex bibliography, unbalanced dollar symbols in the url field result in an error failed to parse BibLaTeX file (bibliography.bib:9: unexpected end of file).

Typst:

@key

#bibliography("bibliography.bib")

BibTex:

@article{key,
  author = {A. Name},
  journal = {Journal},
  number  = {1},
  title = {Title},
  volume = {2},
  year = {1234},
  comment = {3\$},
  url = {example.com?A=$B}
}

Escaping the dollar symbol with "$", which is possible in other fields like comment, would change the url.

typst --version
typst 0.11.0 (2bf9f95d)

Reproduction URL

No response

Operating system

Linux

Typst version

I am using the latest version of Typst

Support for access time in bibliography

Description

I want to show what time I accessed a resource.

As hayagriva does not support the use of a time, I have switched to the BibTeX format.
Using this entry compiles without errors:

@online{online-source,
    author    = "Donald Knuth",
    title     = "Knuth: Computers and Typesetting",
    url       = "http://www-cs-faculty.stanford.edu/~uno/abcde.html",
    urldate   = {2024-05-09T14:30:00},
}

But the bibliography only renders the date:

I have used the IEEE style and tried several others and none of them rendered the time, so I suspect it is not a matter of the style used.

I have already added an issue in the hayagriva repo to add support for the access time: typst/hayagriva#160

Use Case

To be able to use a more detailed access timestamp for online ressources

Dates <> 4 digits

Please see typst/hayagriva#81

I tried to use the following BibTeX entry:

@Book{lucretius50bce,
author = {Lucretius}, 
title = {On the Nature of Things}, 
year = {50 BCE}, }

And Typst chokes on it, asking on discord it appears a hayagriva limitation. Making it {0050 BCE} and parsing can continue. Supporting non-quad years would be great!

Crossref inheritance and overloading

Hi, I'm a bit confused about the inheritance order of crossref. If both entries contain the same field with different values (like year), which one should be used?

Here is an example:

let bib = r#"
    @inproceedings{foo,
        author = {Max Müller},
        title = {Lorem Ipsum et Dolor},
        month = sep,
        year = 2005,
        crossref = {ref},
    }
    @proceedings{ref,
        month = jan,
        year = 2001,
        title = {Book Title},
        category = {baz},
    }
"#;
let parsed = Bibliography::parse(bib).unwrap();
println!("{parsed:#?}");

In this example, I would expect that the year from the referrer foo overwrites the year from the referee ref.

However, this is not the case:

Bibliography {
    entries: [
        Entry {
            key: "foo",
            entry_type: InProceedings,
            fields: {
                "author": [
                    Normal(
                        "Max Müller",
                    ) <43..54>,
                ],
                "booktitle": [
                    Normal(
                        "Book Title",
                    ) <252..262>,
                ],
                "crossref": [
                    Normal(
                        "ref",
                    ) <159..162>,
                ],
                "date": [
                    Normal(
                        "2001-01",
                    ) <18446744073709551615..18446744073709551615>,
                ],
                "title": [
                    Normal(
                        "Lorem Ipsum et Dolor",
                    ) <74..94>,
                ],
            },
        },
        Entry {
            key: "ref",
            entry_type: Proceedings,
            fields: {
                "category": [
                    Normal(
                        "baz",
                    ) <285..288>,
                ],
                "month": [
                    Normal(
                        "January",
                    ) <209..212>,
                ],
                "title": [
                    Normal(
                        "Book Title",
                    ) <252..262>,
                ],
                "year": [
                    Normal(
                        "2001",
                    ) <229..233>,
                ],
            },
        },
    ],
    keys: {
        "foo": 0,
        "ref": 1,
    },
}

PS: Also, the category is not inherited.

PS2: PS: Thank you for this crate. This is a good replacement for the very slow bibtexparser python package.

Discuss wider `@string` syntax

Best suited for Discussions, but I'm opening an issue for reference.

After reversing for a while I found this interesting one, and it's so cozy that I find it not a bug but a feature.

In BibTeX/BibLaTeX there's the @STRING special entry, that defines abbreviations of strings and which the preprocessor will take care of.

So we can define our list of aliases or abbreviations:

@string{anch-ie = {Angew.~Chem. Int.~Ed.}}
@string{cup     = {Cambridge University Press}}
@string{dtv     = {Deutscher Taschenbuch-Verlag}}
@string{hup     = {Harvard University Press}}
@string{jams    = {J.~Amer. Math. Soc.}}
@string{jchph   = {J.~Chem. Phys.}}
@string{jomch   = {J.~Organomet. Chem.}}
@string{pup     = {Princeton University Press}}

And then we can use it instead of typing the full journal name, notice the field journaltitle:

@article{aksin,
  author       = {Aks{\i}n, {\"O}zge and T{\"u}rkmen, Hayati and Artok, Levent
                  and {\c{C}}etinkaya, Bekir and Ni, Chaoying and
                  B{\"u}y{\"u}kg{\"u}ng{\"o}r, Orhan and {\"O}zkal, Erhan},
  title        = {Effect of immobilization on catalytic characteristics of
                  saturated {Pd-N}-heterocyclic carbenes in {Mizoroki-Heck}
                  reactions},
  journaltitle = jomch,
  date         = 2006,
  volume       = 691,
  number       = 13,
  pages        = {3027-3036},
  indextitle   = {Effect of immobilization on catalytic characteristics},
}

At the same time, typst allows us an alternative syntax:

@string{
  anch-ie = {Angew.~Chem. Int.~Ed.},
  cup     = {Cambridge University Press},
  dtv     = {Deutscher Taschenbuch-Verlag},
  hup     = {Harvard University Press},
  jams    = {J.~Amer. Math. Soc.},
  jchph   = {J.~Chem. Phys.},
  jomch   = {J.~Organomet. Chem.},
  pup     = {Princeton University Press}
}

That will work and compile just fine, just like in the example above.

I'm not aware if this has unintended consequences or if there's good reasons to disallow it, personally I'd love that in the TeX world we supported that alternative syntax.

Again, I find it nice of typst 🧡, even if it won't work on BibTeX/BibLaTeX.

Examples come from biblatex-examples.bib.

typst / biblatex Goto Github PK

biblatex's Issues

Description

Reproduction URL

Operating system

Typst version

Desired solution

Description

Reproduction URL

Operating system

Typst version

Description

Use Case

Recommend Projects

Recommend Topics

Recommend Org