-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More control over date formats #863
Comments
Just a short update and a reminder for me in case I forget anything. I thought that the first MWE could be helped with something like
that is, So I went down the rabbit hole of trying to consolidate option handling on the three levels The implementation of the date format options, as it turns out, does not really lend itself to a natural extension to per-type and per-entry scope, so that would need extra work. (If I understand correctly the issue is as follows: The options just set the internal macro I haven't yet looked at something like Please let me know if I missed of misunderstood anything. |
No @moewew , I don't think you've missed or misunderstood anything. And I sympathize and appreciate the idea of consolidating option handling on each level, though it's no mean task. I did miss the possibility of using As to something like Still, my suggestion here is to extend an equivalent flexibility in formatting dates as there are to other field types, in general, for I believe it makes sense (again, from an user's perspective). I do see you concur on that, given you not only bought the idea, but are considering generalizing it. |
* Add new \DeclareBiblatexOption to declare option for multiple scopes at once. * Extend some options to new scopes. * Related to plk#863.
While working on something else, I came up with another kind of flexibility which might be desirable with respect to dates: For example, it might be desirable to have "circa" and "?" (for uncertain) in the bibliography, while leaving those out from a citation ( A MWE for this case:
|
Consolidate option handling * Add new \DeclareBiblatexOption to declare option for multiple scopes at once. * Extend some options to new scopes. * Tighten (max|min)(bib|cite)?names options. * Related to #863.
... at least the easy ones...
I have a commit lined up that generalises all date options to per-type and per-entry scopes. It took a bit of fiddling, but should hopefully be working. Currently, I'm looking at other ways to control the date format. It should be possible to add an optional argument to |
@moewew I'm very glad to see this going forward. And, as usual, for a request which was already bold, you deliver plenty more than was asked. What you already have there, and what you are looking into, seems very promising and interesting indeed. Thank you very much. I understand your comment was not "just for the OP", but for everyone. Still, I thought it worth mentioning it is much appreciated, and to lend myself at your disposal for some testing. When you think its time for such, let me know. |
You can have a first look at https://github.com/moewew/biblatex/tree/localdateoptions (changes to current I'm still thinking about more granular control for |
@moewe As promised, I went for a spin of the The first thing here is regarding the namespace of date related options and the strain that every new feature/option inevitably brings in this area. I tried to find some sort of way around the namespace for this, but as you can imagine, I stumbled. And in doing so, I'm convinced the user interface for date options might benefit from a more systematic implementation. I tried to come up with something -- in line with what you were already thinking, taking from your comments -- and suggest one possible interface for discussion. (Using the "working title", I'm not arguing here for the macro name, just the UI). We could have a preamble \DeclareDateOptions[<entrytype>]{<datetype>}{<keyvalue options>}
\DeclareDateOptions*{<datetype>}{<keyvalue options>} The starred version applying to all entrytypes. If desired, the availability of such an interface could be used to curb down the global option namespace with time, and due warning ("could", if it "should" is another matter). This is enough to allow full global, entrytype and datetype scopes flexibility for dates options. Per-entry scope is not covered though, and would still rely on the global names of options. It might be enough, but if full flexibility is desired also at this level, some more handles would be required. In this case, entryfields named Regarding testing properly, I came up with some issues, some of which are more general than the new functionality of the branch, but are within the broad scope of this issue. Also, a number of them are not necessarily "problems", but things that called my attention while testing, and the only thing I mean in bringing them here is to check with you if those are really expected results.
MWE to illustrate: \documentclass{article}
\usepackage[
style=authoryear,
block=par,
]{biblatex}
\begin{filecontents}[overwrite]{\jobname.bib}
@customa{myentry,
author = {Buthor},
title = {My entry's title},
date = {2017-04-05T14:34:04~},
options = {date=long},
}
\end{filecontents}
\addbibresource{\jobname.bib}
\DeclareBibliographyDriver{customa}{%
\printnames{author}%
\setunit{\printdelim{nametitledelim}}%
\printfield{title}%
\setunit{\subtitlepunct}%
\printfield{subtitle}%
\newunit\newblock
\printtext{\mkbibbold{date:}}
\newblock
\printtext{d:}
\printdate[dateformat=ymd]
\newblock
\printdate
\newblock
}
\begin{document}
\cite{myentry}
\printbibliography
\end{document}
Consider the following two cases. An user chooses to set all of their datetypes to format The second case is probably not of great consequence and is likely intended result anyway. It is also understandable, as it is much harder to check option consistency for things which are being set in the MWEs to illustrate: \documentclass{article}
\usepackage[
style=authoryear,
date=terse,
labeldate=terse,
urldate=iso,
eventdate=terse,
origdate=terse,
datezeros=false,
block=par,
]{biblatex}
\begin{filecontents}[overwrite]{\jobname.bib}
@customa{myentry,
author = {Buthor},
title = {My entry's title},
date = {2017-04-05T14:34:04~},
urldate = {2003-06-08T12:54:07?},
eventdate = {1994-02-09T03:23:17/1994-04-10T07:02:53},
origdate = {1456-11-03T08:39:34%},
}
\end{filecontents}
\addbibresource{\jobname.bib}
\DeclareBibliographyDriver{customa}{%
\printnames{author}%
\setunit{\printdelim{nametitledelim}}%
\printfield{title}%
\setunit{\subtitlepunct}%
\printfield{subtitle}%
\newunit\newblock
\printtext{\mkbibbold{date:}}
\newblock
\printtext{d:}
\printdate
\newblock
\printtext{de:}
\printdateextra
\newblock
\printtext{ld:}
\printlabeldate
\newblock
\printtext{lde:}
\printlabeldateextra
\newblock
\printtext{\mkbibbold{url date:}}
\newblock
\printtext{d:}
\printurldate
\newblock
\printtext{\mkbibbold{event date:}}
\newblock
\printtext{d:}
\printeventdate
\newblock
\printtext{\mkbibbold{orig date:}}
\newblock
\printtext{d:}
\printorigdate
\newblock
}
\begin{document}
\cite{myentry}
\printbibliography
\end{document} \documentclass{article}
\usepackage[
style=authoryear,
date=comp,
labeldate=comp,
urldate=comp,
eventdate=comp,
origdate=comp,
datezeros=true,
block=par,
]{biblatex}
\begin{filecontents}[overwrite]{\jobname.bib}
@customa{myentry,
author = {Buthor},
title = {My entry's title},
date = {2017-04-05T14:34:04~},
urldate = {2003-06-08T12:54:07?},
eventdate = {1994-02-09T03:23:17/1994-04-10T07:02:53},
origdate = {1456-11-03T08:39:34%},
}
\end{filecontents}
\addbibresource{\jobname.bib}
\DeclareBibliographyDriver{customa}{%
\printnames{author}%
\setunit{\printdelim{nametitledelim}}%
\printfield{title}%
\setunit{\subtitlepunct}%
\printfield{subtitle}%
\newunit\newblock
\printtext{\mkbibbold{date:}}
\newblock
\printtext{d:}
\printdate
\newblock
\printtext{de:}
\printdateextra
\newblock
\printtext{ld:}
\printlabeldate
\newblock
\printtext{lde:}
\printlabeldateextra
\newblock
\printtext{\mkbibbold{url date:}}
\newblock
\printtext{d:}
\printurldate
\newblock
\printtext{\mkbibbold{event date:}}
\newblock
\printtext{d:}
\printeventdate
\newblock
\printtext{\mkbibbold{orig date:}}
\newblock
\printtext{d:}
\printorigdate
\newblock
}
\begin{document}
\cite{myentry}
\printbibliography
\end{document}
But if this is what is at play here, why then are these times showing for MWE: \documentclass{article}
% Loading babel with german times appear for '\printdateextra' for all
% datetypes, except for 'year'.
% \usepackage[german]{babel}
% \usepackage{csquotes}
\usepackage[
style=authoryear,
alldatesusetime=true,
block=par,
]{biblatex}
\begin{filecontents}[overwrite]{\jobname.bib}
@customa{myentry,
author = {Buthor},
title = {My entry's title},
date = {2017-04-05T14:34:04~},
}
\end{filecontents}
\addbibresource{\jobname.bib}
\DeclareBibliographyDriver{customa}{%
\printnames{author}%
\setunit{\printdelim{nametitledelim}}%
\printfield{title}%
\setunit{\subtitlepunct}%
\printfield{subtitle}%
\newunit\newblock
\printtext{\mkbibbold{date:}}
\newblock
\printtext{d:}
\printdate[dateformat=year]
\newblock
\printdate[dateformat=short]
\newblock
\printdate[dateformat=long]
\newblock
\printdate[dateformat=terse]
\newblock
\printdate[dateformat=comp]
\newblock
\printdate[dateformat=ymd]
\newblock
\printdate[dateformat=iso]
\newblock
\printtext{de:}
\printdateextra[dateformat=year]
\newblock
\printdateextra[dateformat=short]
\newblock
\printdateextra[dateformat=long]
\newblock
\printdateextra[dateformat=terse]
\newblock
\printdateextra[dateformat=comp]
\newblock
\printdateextra[dateformat=ymd]
\newblock
\printdateextra[dateformat=iso]
\newblock
}
\begin{document}
\cite{myentry}
\printbibliography
\end{document}
MWE: \documentclass{article}
\usepackage[german]{babel}
\usepackage{csquotes}
\usepackage[
style=authoryear,
alldatesusetime=true, % to emphasize the effect
block=par,
]{biblatex}
\begin{filecontents}[overwrite]{\jobname.bib}
@customa{myentry,
author = {Buthor},
title = {My entry's title},
date = {2017-04-05T05:27:00},
}
@customa{myentry2,
author = {Buthor},
title = {My entry's title to trigger dateextra},
date = {2017-05-08T22:45:00},
}
\end{filecontents}
\addbibresource{\jobname.bib}
\DeclareBibliographyDriver{customa}{%
\printnames{author}%
\setunit{\printdelim{nametitledelim}}%
\printfield{title}%
\setunit{\subtitlepunct}%
\printfield{subtitle}%
\newunit\newblock
\printtext{\mkbibbold{date:}}
\newblock
\printtext{de:}
\printdateextra[dateformat=year]
\newblock
\printdateextra[dateformat=short]
\newblock
\printdateextra[dateformat=long]
\newblock
\printdateextra[dateformat=terse]
\newblock
\printdateextra[dateformat=comp]
\newblock
\printdateextra[dateformat=ymd]
\newblock
\printdateextra[dateformat=iso]
\newblock
}
\begin{document}
\cite{myentry,myentry2}
\printbibliography
\end{document} That's what I could gather from my testing session, and thus report. And I reiterate this effort around date options is very welcome and appreciated. So, thank you very much. And I hope this report is useful in polishing it. PS: I may falter in response time for the next couple of weeks, as they promise to be busy. But I'll be following attentively, and will catch up eventually. |
Thank you very much for the extensive testing and feedback. I will have a look at your reply in detail at some point, but probably not before the coming weekend. |
The low-hanging fruits first.
I'll need to have a think about items 1 and 2. |
Fortunately indeed. Thanks for the fix.
I didn't mean to make any claims about it. What caught my attention was the different handling for it across date types, not the placement per se, and that's why I included it. So, beyond the "just checking" intended, further discussion as you see fit.
Sure, and I guess the most delicate is the UI. And, of course, it will be very, very difficult for you to do anything about item 4. ;-) |
Mhh, while I like the idea of The date options this would apply to don't appear to be used all that much and are quite specialist anyway (except maybe for Some data points from the styles installed on my machine (which should hopefully be all styles on CTAN, if I haven't forgotten one: This time I did check OSCOLA).
|
Do you mean here on the technical/implementation side, or on the side of devising a set of rules for their relation? If the later, could you expand the kind of problem is raising your concerns? (If the former, I defer to you, as it is out of my league anyway). |
I guess both. I was mainly thinking of the set of rules for their relation, but I had a particular implementation in mind that would make it quite hard to negotiate between the two levels of global options and the per-date option. But I jut realised how Still if you can walk me through your ideas on the rules of how the options should interact, that would be grand. (In particular how should the different per-type levels interact?) |
You are probably seeing things that I don't (this is known to have happened in the past ;-), and I also haven't made up my mind on how this should behave, as this is indeed hard to think all the way through. But I can try to come up with something more systematic and bring it here to help you think it over. (I'll prepare it, but I'll need some days to do so). Besides that, I feel further deepening this namespace for date options will probably bring even more problems down the road. You probably know that better than I do, and if that is the only alternative, than it's chosen. But, do you think it would be also useful if I extended on why a more sophisticated option interface would be a better long term choice for this task? (even if "for the record"). Or would I be "raining on the wet"? (to use a local expression, hopefully understandable). |
@moewe As promised, I tried to systematize my thoughts on this issue, and share them with you. Please read them as meaning "what I would try to do if I was attempting to tackle the problem", which I think is mainly one of user interface design. I do not intend to be "normative" in any way whatsoever. I admittedly don't have a perspective as wide as yours, specially not on the implementation side. So, just pick whatever makes sense to you out of the bunch. I do hope there is something useful there, though. Combinatorics and option namespaceThere are two main dimensions through which date related options vary in The "base options" currently comprise: (Btw, "Scopes" either existent or currently being considered in the
It is clear that any definition date behavior at the Still, considering only "base options" accross datetypes, the potential set of date related options would mount to 84 options (14 "base options" x (5 default datetypes + a catch "all" value)). Not currently handled (as far as I can tell) are (total 55): It is true that a number of those options may be argued to be meant to be global only, thus reducing the size of the set. However, it seems clear that at least some of those deserve to be more flexible as to the scope they apply. And, once we are at it, why not solve it for all of them? Anyway, if this is the argument, it would also beg the question as to why allow the flexibility at entrytype and entry scopes, but not across datetypes. So, current state of these new scope flexibility would increase total options in 55 (and, as mentioned, this leaves aside entrytype, entry, or Scopes and precedence rulesThe case of the entrytype scope already implies that the interface for date options must rely, at least partially, on some other interface which is not exclusively reliant on "options names combinations" (anyone for 84x36?). Besides that, the fact that it is already possible to use If this presumption is correct, it seems to me that the trickiest part of the problem lies not so much in how to "set" these options at different scopes, and more in how to "query" them at the appropriate times. And, of course, also how to establish and enforce proper precedence rules along the different scopes. Furthermore, given entry scope and print time scope are being considered here, there is really only one place where full context information will be available to decide on scope precedence, which is at
Any other precedence rule could be used in similar fashion here, as long as we are at the right place to "query" the options which are relevant to the context in which a given date is being printed. I'm making a number of assumptions here, and this might well turn up to be naïve when the actual current implementation of date options (code-wise), of which I'm mostly ignorant, is considered. But this is the best version of what you asked me: "[my] ideas on the rules of how the options should interact". I'm not sure I got what you meant by:
But, if I did, the above should also be a possible answer to that. If the scope precedence decision is done at print time, as suggested above, the different per-type levels simply don't interact. At that point, we know the entrytype of entrykey, so have only one type to consider. We have only to decide among different options' scopes. Still there are more nuances and elements worth discussing, to which I turn. Indeed, we might well consider the possibility of handling more scopes in this list. Note that I'm not proposing or suggesting this should be done at this point. I'm just considering what this possibility implies to the user interface design. For if the user interface is prepared to accommodate for some flexibility which we conceivably might need in the future, it is better, for changes in the user interface are bound to be painful. Cases I could conceive: Some small adjustments to the interface I had initially suggested should be enough to handle this much flexibility. The revised version: We could have a preamble and document-body \DeclareDateOptions[<entrytype>]{<datetype>}{<keyvalue options>}
\DeclareDateOptions*{<datetype>}{<keyvalue options>}
Current options and backward compatibility in face of the new flexibilityAs far as I understand, if these macros existed, they could be directly used to set the current load-time/preamble options (which are the only ones currently released, if I'm not mistaken), filling the "code" argument in This is trivial for all options which already grant a datetype scope. Let's tackle this first then:
It is also not complicated to translate current meaning of "
This means full backwards compatibility with current existing options is easy to achieve. The issue does not arise here, because we don't need these options to refer to a specific datetype scope ("date") as opposed to "alldates", which is the meaning they actually currently carry. But things do get more interesting for " For example, setting
But it is easy to argue as preferable:
Of course, as things stand, this is not possible. But with added scope flexibility (either with Conversely, things set in the localized dateformats (defined in the Well, I guess those were my thoughts on the matter. Again, I hope they are somehow useful. |
Currently, date formats (year, short, long, terse etc.) are preamble only options which affect any given datetype globally in the document. It would be interesting, from an user’s perspective, to be able to have more flexibility than that.
Consider two possibilities:
(Conceptually, the situation could be extended to time too. Though I see less relevance there.)
As it stands, the only way around this, that I know of, is to extend the datamodel and create, e.g.
shortdate
, use a sourcemap to copy the contents ofdate
toshortdate
and, then, use\printdate
or\printshortdate
as required.I envisage two (non-excluding?) possible interfaces for this. One would be to add an optional argument to the
\printdate
s commands, as in e.g.\printdate[long]
. The other, more interesting, I think, but probably more complicated to implement, is to incorporate the date format as an additional optional argument in the formatting directives for date fields. Or provide an equivalent mechanism for the date format in particular (\DeclareDateFormat
?).I’m well aware date fields are “special” (and tricky). I make the request from an user’s perspective, not knowing if this might be technically viable. I’ve argued though the reasons I think this could be desirable.
Below, I leave two MWEs which may serve as test bases for each of the use cases mentioned above.
MWE1:
MWE2:
The text was updated successfully, but these errors were encountered: