Giter Club home page Giter Club logo

biblatex's Introduction

Typst

Documentation Typst App Discord Server Apache-2 License Jobs at Typst

Typst is a new markup-based typesetting system that is designed to be as powerful as LaTeX while being much easier to learn and use. Typst has:

  • Built-in markup for the most common formatting tasks
  • Flexible functions for everything else
  • A tightly integrated scripting system
  • Math typesetting, bibliography management, and more
  • Fast compile times thanks to incremental compilation
  • Friendly error messages in case something goes wrong

This repository contains the Typst compiler and its CLI, which is everything you need to compile Typst documents locally. For the best writing experience, consider signing up to our collaborative online editor for free. It is currently in public beta.

Example

A gentle introduction to Typst is available in our documentation. However, if you want to see the power of Typst encapsulated in one image, here it is:

Example

Let's dissect what's going on:

  • We use set rules to configure element properties like the size of pages or the numbering of headings. By setting the page height to auto, it scales to fit the content. Set rules accommodate the most common configurations. If you need full control, you can also use show rules to completely redefine the appearance of an element.

  • We insert a heading with the = Heading syntax. One equals sign creates a top level heading, two create a subheading and so on. Typst has more lightweight markup like this, see the syntax reference for a full list.

  • Mathematical equations are enclosed in dollar signs. By adding extra spaces around the contents of an equation, we can put it into a separate block. Multi-letter identifiers are interpreted as Typst definitions and functions unless put into quotes. This way, we don't need backslashes for things like floor and sqrt. And phi.alt applies the alt modifier to the phi to select a particular symbol variant.

  • Now, we get to some scripting. To input code into a Typst document, we can write a hash followed by an expression. We define two variables and a recursive function to compute the n-th fibonacci number. Then, we display the results in a center-aligned table. The table function takes its cells row-by-row. Therefore, we first pass the formulas $F_1$ to $F_8$ and then the computed fibonacci numbers. We apply the spreading operator (..) to both because they are arrays and we want to pass the arrays' items as individual arguments.

Text version of the code example.
#set page(width: 10cm, height: auto)
#set heading(numbering: "1.")

= Fibonacci sequence
The Fibonacci sequence is defined through the
recurrence relation $F_n = F_(n-1) + F_(n-2)$.
It can also be expressed in _closed form:_

$ F_n = round(1 / sqrt(5) phi.alt^n), quad
  phi.alt = (1 + sqrt(5)) / 2 $

#let count = 8
#let nums = range(1, count + 1)
#let fib(n) = (
  if n <= 2 { 1 }
  else { fib(n - 1) + fib(n - 2) }
)

The first #count numbers of the sequence are:

#align(center, table(
  columns: count,
  ..nums.map(n => $F_#n$),
  ..nums.map(n => str(fib(n))),
))

Installation

Typst's CLI is available from different sources:

  • You can get sources and pre-built binaries for the latest release of Typst from the releases page. Download the archive for your platform and place it in a directory that is in your PATH. To stay up to date with future releases, you can simply run typst update.

  • You can install Typst through different package managers. Note that the versions in the package managers might lag behind the latest release.

    • Linux: View Typst on Repology
    • macOS: brew install typst
    • Windows: winget install --id Typst.Typst
  • If you have a Rust toolchain installed, you can also install the latest development version with cargo install --git https://github.com/typst/typst --locked typst-cli. Note that this will be a "nightly" version that may be broken or not yet properly documented.

  • Nix users can use the typst package with nix-shell -p typst or build and run the bleeding edge version with nix run github:typst/typst -- --version.

  • Docker users can run a prebuilt image with docker run -it ghcr.io/typst/typst:latest.

Usage

Once you have installed Typst, you can use it like this:

# Creates `file.pdf` in working directory.
typst compile file.typ

# Creates PDF file at the desired path.
typst compile path/to/source.typ path/to/output.pdf

You can also watch source files and automatically recompile on changes. This is faster than compiling from scratch each time because Typst has incremental compilation.

# Watches source files and recompiles on changes.
typst watch file.typ

Typst further allows you to add custom font paths for your project and list all of the fonts it discovered:

# Adds additional directories to search for fonts.
typst compile --font-path path/to/fonts file.typ

# Lists all of the discovered fonts in the system and the given directory.
typst fonts --font-path path/to/fonts

# Or via environment variable (Linux syntax).
TYPST_FONT_PATHS=path/to/fonts typst fonts

For other CLI subcommands and options, see below:

# Prints available subcommands and options.
typst help

# Prints detailed usage of a subcommand.
typst help watch

If you prefer an integrated IDE-like experience with autocompletion and instant preview, you can also check out the Typst web app, which is currently in public beta.

Community

The main place where the community gathers is our Discord server. Feel free to join there to ask questions, help out others, share cool things you created with Typst, or just to chat.

Aside from that there are a few places where you can find things built by the community:

If you had a bad experience in our community, please reach out to us.

Contributing

We would love to see contributions from the community. If you experience bugs, feel free to open an issue. If you would like to implement a new feature or bug fix, please follow the steps outlined in the contribution guide.

To build Typst yourself, first ensure that you have the latest stable Rust installed. Then, clone this repository and build the CLI with the following commands:

git clone https://github.com/typst/typst
cd typst
cargo build --release

The optimized binary will be stored in target/release/.

Another good way to contribute is by sharing packages with the community.

Pronunciation and Spelling

IPA: /taɪpst/. "Ty" like in Typesetting and "pst" like in Hipster. When writing about Typst, capitalize its name as a proper noun, with a capital "T".

Design Principles

All of Typst has been designed with three key goals in mind: Power, simplicity, and performance. We think it's time for a system that matches the power of LaTeX, is easy to learn and use, all while being fast enough to realize instant preview. To achieve these goals, we follow three core design principles:

  • Simplicity through Consistency: If you know how to do one thing in Typst, you should be able to transfer that knowledge to other things. If there are multiple ways to do the same thing, one of them should be at a different level of abstraction than the other. E.g. it's okay that = Introduction and #heading[Introduction] do the same thing because the former is just syntax sugar for the latter.

  • Power through Composability: There are two ways to make something flexible: Have a knob for everything or have a few knobs that you can combine in many ways. Typst is designed with the second way in mind. We provide systems that you can compose in ways we've never even thought of. TeX is also in the second category, but it's a bit low-level and therefore people use LaTeX instead. But there, we don't really have that much composability. Instead, there's a package for everything (\usepackage{knob}).

  • Performance through Incrementality: All Typst language features must accommodate for incremental compilation. Luckily we have comemo, a system for incremental compilation which does most of the hard work in the background.

biblatex's People

Contributors

ariroffe avatar bamonroe avatar cgmossa avatar constraintautomaton avatar dependabot[bot] avatar laurmaedje avatar mutlusun avatar pjhuxford avatar quachpas avatar reknih avatar violetfauna avatar yuxqiu avatar zepinglee avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

biblatex's Issues

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

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.

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 :)

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,
    },
}

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!

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

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.

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.

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”)

-- 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
image

Reproduction URL

No response

Operating system

No response

Typst version

  • I am using the latest version of Typst

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.

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!

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!}

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

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.

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.

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! 🚀

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}
}

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

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

and optionally

  1. 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 `/` 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

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.

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:

image

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

#bibliography("./broken.bib")

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.

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

image

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.