Filter by a list of bibkey on printbibliograhy
I am currently using biblatex
for creating my document. I want to know if it is possible to split the bibliography with only the bibkeys.
The idea will be to use
printbibliography[title=Primal,key={KEY1,KEY2}]
printbibliography[title=Complementary,notkey={KEY1,KEY2}]
KEY1
and KEY2
designate here the bibkeys associated to references. I know I can use keywords in references for filtering but I want to avoid it if possible.
biblatex filter
add a comment |
I am currently using biblatex
for creating my document. I want to know if it is possible to split the bibliography with only the bibkeys.
The idea will be to use
printbibliography[title=Primal,key={KEY1,KEY2}]
printbibliography[title=Complementary,notkey={KEY1,KEY2}]
KEY1
and KEY2
designate here the bibkeys associated to references. I know I can use keywords in references for filtering but I want to avoid it if possible.
biblatex filter
add a comment |
I am currently using biblatex
for creating my document. I want to know if it is possible to split the bibliography with only the bibkeys.
The idea will be to use
printbibliography[title=Primal,key={KEY1,KEY2}]
printbibliography[title=Complementary,notkey={KEY1,KEY2}]
KEY1
and KEY2
designate here the bibkeys associated to references. I know I can use keywords in references for filtering but I want to avoid it if possible.
biblatex filter
I am currently using biblatex
for creating my document. I want to know if it is possible to split the bibliography with only the bibkeys.
The idea will be to use
printbibliography[title=Primal,key={KEY1,KEY2}]
printbibliography[title=Complementary,notkey={KEY1,KEY2}]
KEY1
and KEY2
designate here the bibkeys associated to references. I know I can use keywords in references for filtering but I want to avoid it if possible.
biblatex filter
biblatex filter
asked Jan 14 at 10:02
GuukGuuk
891515
891515
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The approach of filtering by entry keys is quite non-semantic and it might be possible to find a more elegant solution based on keywords, entry types or other fixed criteria instead of the arbitrary entry key. That is not to say, however, that in some cases splitting or grouping by entry key is not the best or most sensible solution.
A quite elegant solution is to use categories. Bibliography categories were meant to categorise/group entries on the fly from within the .tex
document and not in the (more static) .bib
data (where keywords
would be the right approach).
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
DeclareBibliographyCategory{keys}
addtocategory{keys}{sigfridsson,nussbaum}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[category=keys]
printbibliography[notcategory=keys]
end{document}
The less elegant brute-force methods uses bibchecks, which gets a bit messy as the lists grow, but can be more easily combined with other sorts of test.
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
defbibcheck{keys}{%
iffieldequalstr{entrykey}{sigfridsson}
{}
{iffieldequalstr{entrykey}{nussbaum}
{}
{skipentry}}}
defbibcheck{notkeys}{%
iffieldequalstr{entrykey}{sigfridsson}
{skipentry}
{iffieldequalstr{entrykey}{nussbaum}
{skipentry}
{}}}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[check=keys]
printbibliography[check=notkeys]
end{document}
The output would be the same.
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f470035%2ffilter-by-a-list-of-bibkey-on-printbibliograhy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The approach of filtering by entry keys is quite non-semantic and it might be possible to find a more elegant solution based on keywords, entry types or other fixed criteria instead of the arbitrary entry key. That is not to say, however, that in some cases splitting or grouping by entry key is not the best or most sensible solution.
A quite elegant solution is to use categories. Bibliography categories were meant to categorise/group entries on the fly from within the .tex
document and not in the (more static) .bib
data (where keywords
would be the right approach).
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
DeclareBibliographyCategory{keys}
addtocategory{keys}{sigfridsson,nussbaum}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[category=keys]
printbibliography[notcategory=keys]
end{document}
The less elegant brute-force methods uses bibchecks, which gets a bit messy as the lists grow, but can be more easily combined with other sorts of test.
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
defbibcheck{keys}{%
iffieldequalstr{entrykey}{sigfridsson}
{}
{iffieldequalstr{entrykey}{nussbaum}
{}
{skipentry}}}
defbibcheck{notkeys}{%
iffieldequalstr{entrykey}{sigfridsson}
{skipentry}
{iffieldequalstr{entrykey}{nussbaum}
{skipentry}
{}}}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[check=keys]
printbibliography[check=notkeys]
end{document}
The output would be the same.
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
add a comment |
The approach of filtering by entry keys is quite non-semantic and it might be possible to find a more elegant solution based on keywords, entry types or other fixed criteria instead of the arbitrary entry key. That is not to say, however, that in some cases splitting or grouping by entry key is not the best or most sensible solution.
A quite elegant solution is to use categories. Bibliography categories were meant to categorise/group entries on the fly from within the .tex
document and not in the (more static) .bib
data (where keywords
would be the right approach).
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
DeclareBibliographyCategory{keys}
addtocategory{keys}{sigfridsson,nussbaum}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[category=keys]
printbibliography[notcategory=keys]
end{document}
The less elegant brute-force methods uses bibchecks, which gets a bit messy as the lists grow, but can be more easily combined with other sorts of test.
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
defbibcheck{keys}{%
iffieldequalstr{entrykey}{sigfridsson}
{}
{iffieldequalstr{entrykey}{nussbaum}
{}
{skipentry}}}
defbibcheck{notkeys}{%
iffieldequalstr{entrykey}{sigfridsson}
{skipentry}
{iffieldequalstr{entrykey}{nussbaum}
{skipentry}
{}}}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[check=keys]
printbibliography[check=notkeys]
end{document}
The output would be the same.
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
add a comment |
The approach of filtering by entry keys is quite non-semantic and it might be possible to find a more elegant solution based on keywords, entry types or other fixed criteria instead of the arbitrary entry key. That is not to say, however, that in some cases splitting or grouping by entry key is not the best or most sensible solution.
A quite elegant solution is to use categories. Bibliography categories were meant to categorise/group entries on the fly from within the .tex
document and not in the (more static) .bib
data (where keywords
would be the right approach).
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
DeclareBibliographyCategory{keys}
addtocategory{keys}{sigfridsson,nussbaum}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[category=keys]
printbibliography[notcategory=keys]
end{document}
The less elegant brute-force methods uses bibchecks, which gets a bit messy as the lists grow, but can be more easily combined with other sorts of test.
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
defbibcheck{keys}{%
iffieldequalstr{entrykey}{sigfridsson}
{}
{iffieldequalstr{entrykey}{nussbaum}
{}
{skipentry}}}
defbibcheck{notkeys}{%
iffieldequalstr{entrykey}{sigfridsson}
{skipentry}
{iffieldequalstr{entrykey}{nussbaum}
{skipentry}
{}}}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[check=keys]
printbibliography[check=notkeys]
end{document}
The output would be the same.
The approach of filtering by entry keys is quite non-semantic and it might be possible to find a more elegant solution based on keywords, entry types or other fixed criteria instead of the arbitrary entry key. That is not to say, however, that in some cases splitting or grouping by entry key is not the best or most sensible solution.
A quite elegant solution is to use categories. Bibliography categories were meant to categorise/group entries on the fly from within the .tex
document and not in the (more static) .bib
data (where keywords
would be the right approach).
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
DeclareBibliographyCategory{keys}
addtocategory{keys}{sigfridsson,nussbaum}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[category=keys]
printbibliography[notcategory=keys]
end{document}
The less elegant brute-force methods uses bibchecks, which gets a bit messy as the lists grow, but can be more easily combined with other sorts of test.
documentclass[british]{article}
usepackage[T1]{fontenc}
usepackage[utf8]{inputenc}
usepackage{babel}
usepackage{csquotes}
usepackage[style=authoryear, backend=biber]{biblatex}
defbibcheck{keys}{%
iffieldequalstr{entrykey}{sigfridsson}
{}
{iffieldequalstr{entrykey}{nussbaum}
{}
{skipentry}}}
defbibcheck{notkeys}{%
iffieldequalstr{entrykey}{sigfridsson}
{skipentry}
{iffieldequalstr{entrykey}{nussbaum}
{skipentry}
{}}}
addbibresource{biblatex-examples.bib}
begin{document}
cite{sigfridsson,worman,nussbaum,geer}
printbibliography[check=keys]
printbibliography[check=notkeys]
end{document}
The output would be the same.
edited Jan 14 at 11:58
answered Jan 14 at 10:11
moewemoewe
97.1k10118363
97.1k10118363
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
add a comment |
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
Awesome!! I really like your first proposition. Thank you !! :-)
– Guuk
Jan 14 at 10:21
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
@Guuk Glad I could help. In almost all cases the first solution with categories is preferable, I guess. I only included the second solution, because that's what came into my mind when I read the title of the question and because it can be slightly more flexible in some cases. (Though the fact that one has to code all keys separately is a nuisance, one could of course try to implement a category like list, but then one could take categories directly.)
– moewe
Jan 14 at 12:00
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f470035%2ffilter-by-a-list-of-bibkey-on-printbibliograhy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown