Dear All, On Sun, 18 Apr 2021 at 15:11, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> I am also leaning towards removing the possibility to include Org syntax > (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly > useful (you can move the bold part outside of the citation object), and > yet, adds a layer of complexity on top of the citation object. > > Can we assume (global)prefix/suffix are just plain text? > well, I think there might be some legitimate use cases, e.g., (see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103) here one might want cf. to be set in italics, and I can imagine situations in which emphasizing a phrase in a prefix/suffix can be useful, but IMHO we can certainly start with assuming just plain text. > In any case, Org has no clue about the "location" of the citation. It > can provide the suffix associated to the citation key, but it is up to > the citation processor to extract page information out of it. If this is > desirable, we need to provide the full citation object instead of the > key. I don't know if it is worth the trouble. It would definitely be useful for making possible more sophisticated opening actions. > > Am I correct in assuming that the returned bibliography should be > > rendered as a legitimate Org fragment regardless of the back-end? > > I think it should be rendered as target format, to be on par with > citation handling. > > You may, however, use Org format as an intermediate step, and then, call > `org-export-data-with-backend' (from "ox.el") on it. If this is > desirable, I need to also provide a fifth `info' argument to the list > above. This is a crucial point: when a note CSL style is used, the export has to generate footnotes "around" those citations which are not already in a footnote. Since citeproc-org generates only Org fragments, this is very simple to do (with anonymous footnotes), but for other formats it can be rather complicated. Would calling `org-export-data-with-backend' handle this? If yes then adding an argument to request this call would be very useful. > > > > This might not be an important point, but citeproc-el is rather > > citation list oriented in the sense that it processes the list of all > > citations and returns a list of their formatted counterparts, so it > > might be useful to provide this "bulk" API as well, at least as an > > optional addition. > > I don't think any addition to the suggested API is required. If you > cannot split citation processing, you may fill a temporary cache holding > all exports on first citation (the full list of citations objects is > provided right from the start), then read from that cache on subsequent > citations. > > WDYT? Basically I agree, it would probably be premature optimization to provide anything else at this point. > I don't understand what you call the "identity of the notes". Could you > provide an example? I meant only that knowing whether a citation is in a footnote or not is not enough -- if a numerical note index is available which specifies the precise position of the note among the footnotes then this is exactly the information what is needed. > Situation in nested footnotes can be ambiguous, tho. In the following > example, is the expected order @a then @b then @c? --8<---------------cut here---------------start------------->8--- Text[fn:1] [@cite:@c] [fn:1] This[fn:2] is [cite:@b]. [fn:2] [cite:@a] --8<---------------cut here---------------end--------------->8--- Yes, I think the order here is @a @b and @c. >> there is CSL-JSON and a CSL-YAML etc. If different "display" >> and "follow" processors will be able to handle different formats then >> the users might want to change those settings locally as well, based >> on the bibliography format, but I'm not sure what kind of >> infrastructure would be the best way of supporting this. (E.g., >> registering format support information about the processors and >> choosing on this basis?) >I don't have an idea about it either. This is not a blocker, tho. We can >revisit it later, once we have "something" working. Absolutely, in the long run probably a way of explicitly specifying the bibliography format/type will be needed, but just a (file)name is a good starting point. thanks & best regards, András > > infrastructure would be the best way of supporting this. (E.g., > > registering format support information about the processors and > > choosing on this basis?) > > I don't have an idea about it either. This is not a blocker, tho. We can > revisit it later, once we have "something" working. > > Thanks for your feedback. > > Regards, > -- > Nicolas Goaziou
