Comments (15)
Yes, if you refer to a non-declared variable, you'll get an error, and it still parses the rest of the entry. What other way would there be to handle that?
from biblatex-csl-converter.
A non-declared variable isn't actually an error. The below MWE compiles cleanly, but refs2
has variables that are not declared in that same file. BBT parses these and will output them again as variables if you have the appropriate option set.
\documentclass{article}
\usepackage[
backend=biber,
natbib=true,
url=false,
doi=true,
eprint=false
]{biblatex}
\usepackage{filecontents}
\begin{filecontents}{refs1.bib}
@String{pub-FRED = "Freds Publishing"}
@String{pub-FRED:adr = "London, UK"}
\end{filecontents}
\begin{filecontents}{refs2.bib}
@Book{cit1,
author = {R. A. Bert},
year = {2000},
title = {{{Atlantic}} bluefin tuna ({ \emph{Thunnus thynnus}})},
publisher = pub-FRED,
address = pub-FRED:adr
}
\end{filecontents}
\addbibresource{refs1.bib}
\addbibresource{refs2.bib}
\begin{document}
\cite{cit1}
\printbibliography
\end{document}
from biblatex-csl-converter.
Ah, so you output bibtex that people can use to fill their variables in. Question: Do you have an estimate of how many users worldwide use that functionality? At least to begin with it sounds like a rather complex thing to do to keep variables used in your bibliography separate from your bibliography manager.
from biblatex-csl-converter.
Worldwide? No idea, but it came by user request to me, so at least one, but in fact multiple BBT users structurally have vars in the journaltitle field and use an externally managed var declaration file.
But that's the output side. On the input side, Booktitle = IEEE_J_PROC
is simply well-formatted BibLaTeX, even if it may not render a correct reference. But a reference that's missing a title will also render improperly while being cleanly imported.
from biblatex-csl-converter.
No idea, but it came by user request to me, so at least one, but in fact multiple BBT users structurally have vars in the journaltitle field and use an externally managed var declaration file.
Ok, that sounds like people who are professional hackers. FW users seem to be less concerned about how to add their own scripting to it all. At least I haven't heard anyone complain about this. If you think it would make sense to add here, maybe this would be code you would want to write?
But a reference that's missing a title will also render improperly while being cleanly imported.
True. But that is because at least so far, we are not enforcing the required_fields list, right?
from biblatex-csl-converter.
Ok, that sounds like people who are professional hackers. FW users seem to be less concerned about how to add their own scripting to it all. At least I haven't heard anyone complain about this. If you think it would make sense to add here, maybe this would be code you would want to write?
There are still a surprisingly large number of BBT users who post-process their references.
But what do you mean with scripting? A separately maintained bibvar file is just standard bib(la)tex functionality. I do have scripting in BBT, but that's only for export, not import.
True. But that is because at least so far, we are not enforcing the required_fields list, right?
So my proposal is then to also not enforce require-var-present đ . Simply put, I need the contents of that field one way or the other. I don't mind if it ends up outside the fields
section.
from biblatex-csl-converter.
But what do you mean with scripting? A separately maintained bibvar file is just standard bib(la)tex functionality. I do have scripting in BBT, but that's only for export, not import.
Users just edit their text, click on print. Done. They don't worry about adding extra files afterwrad.
So my proposal is then to also not enforce require-var-present đ . Simply put, I need the contents of that field one way or the other. I don't mind if it ends up outside the
fields
section.
Maybe what we could do was to add a "raw_fields" that simply contains all the fields in their unprocessed state. and we can also have "other_fields" which contains all fields that were not added to fields that are processed as much as possible.
from biblatex-csl-converter.
Assuming the raw fields would have had stuff like \"o
already transformed, that would be the ideal option for me.
from biblatex-csl-converter.
The raw fields do have those transformed. However there are likely shortcomings in our translation table.
from biblatex-csl-converter.
I'll not be using the raw fields as I need the cooked values.
from biblatex-csl-converter.
Ok, the raw fields represent no overhead to us. Until now their values were simply overwritten for a small list of fields that were handled differently, so the original field values were simply overwritten by reformed versions. Now we handle all the known fields according to specific rules, so it was just a matter of cleanliness not to overwrite the values. But yes, you'll probably want the unknown and unexpected values.
from biblatex-csl-converter.
I'll just use those first. Object.assign FTW.
from biblatex-csl-converter.
bare variables give only { type: 'variable_error' }
as error? no reference?
from biblatex-csl-converter.
and field? Or is that not available?
from biblatex-csl-converter.
What is the difference between variable_error and undeclared_variable?
from biblatex-csl-converter.
Related Issues (20)
- <em> in title field HOT 5
- Is {{...}} detectable?
- nocase nesting HOT 2
- BibLatexExporter does not get bibtexStr HOT 2
- How to use CSLExport to get csl-json? HOT 1
- Allow to export unexpected_fields in the BibLatexExporter
- LICENSE: Make MIT/ISC? HOT 12
- ñ as {~n} HOT 5
- Add command line interface? HOT 1
- Export types
- json->bibtex?? HOT 2
- unused fields HOT 1
- Is Îșαί lower case? HOT 9
- @string concatenation ignores relevant whitespace
- open interval dates HOT 4
- package.json pulls in dependencies that (I think) should be devDependencies HOT 8
- travis is not running HOT 2
- Documentation needed HOT 5
- New character mapping: "\v{c}" => "\u01D2" HOT 2
- Preserve entry key during BibTex to CSL conversion HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
đ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google â€ïž Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from biblatex-csl-converter.