Hi Oliver,
Thanks for this.
On Feb 2, 2006, at 2:58 AM, Oliver Specht wrote:
The first is the text field (com.sun.star.text.TextField). A generic
field service could be added to the API of the Writer that would have a
property that contains a DOM tree. This DOM tree contains the
citation-element. The bibliography creates the DOM tree of those fields
and inserts them into the text together with a string that contains the
presentation text.
This sounds great.
Such fields can only be formatted as a whole. It is not possible to
have
e.g. parts of this presentation printed in bold.
Hmm .. this would be a show-stopped unfortunately. The content of the
new cite:citation-body element needs to be able to hold any standard
paragraph content, including spans, and footnotes. You can see this as
an example of note-based citations:
<http://xbiblio.sourceforge.net/citeproc/examples/chicago-note-a-
en.html>
As you can see, that is rendered as a note, but it also contains inline
styling.
For comparison, the in-text author-year equivalent is here:
<http://xbiblio.sourceforge.net/citeproc/examples/apa-en.html>
This text can not be spanned over paragraphs. The text cannot be
changed manually.
Another possible solution is to add a new object that is similar to
bookmarks (com.sun.star.text.Bookmark). This extended bookmark would
also carry a DOM tree property. This 'bookmark' can span over formatted
text longer than a paragraph.
And therefore would also allow standard paragraph markup (spans,
footnotes, etc.)?
In both cases an interface to access the new elements needs to be
implemented (sorted by document position).
Your parenthetical point here: this is to allow correct sorting of the
reference list (bibliography) according to the "cited" sort-algorithm;
correct?
The DOM interfaces are in com.sun.star.xml.dom.
(e.g. XDocument.idl, XNode.idl, XElement.idl)
There's also a service com.sun.star.xml.dom.DocumentBuilder available
that supports the creation of DOM trees.
OK, hopefully CPH can have a look.
The bibliography component works on the DOM tree and can manipulate it
independently. In case of using a field the component has to set the
resulting string representation of the reference at this field.
I'm a little unclear here. Can you explain?
The way I have been thinking about the process is:
1) collect citations
2) use 1 to construct a list of reference objects, based on external
metadata
3) process 2
Citation formatting is partly dependent on reference list processing.
For example, year formatting in author-year styles can only happen
after this, to get correct suffixes; like "2000b". That is generated by
sorting and grouping the reference list by author, then data. The rule,
then, is typically that:
- where more than one in author group, use full author names for first,
but substitute "———." for rest
- where more than one in author-date group, assign suffix to each
This would be configurable, of course, but the processing needs to
support it.
4) render reference objects to bibliography (if the style requires it),
and write back rendered citation to citation-body.
Is there any particular problems we would run into doing that? Put
differently, do you have any further suggestions?
Using the field is a bit easier and using the bookmark is more
powerful.
Right.
Final question: how possible would it be to enhance the field object?
Or would there be no point? Perhaps this new object could be called
something like richField?
Aside: I have made the argument that things like captions for figures
and tables could, in the future, work similar to citations, where the
content is generated from external metadata (think rights and other
information associated with images, for example).
Thanks!
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
