[citeproc] display=block not working correctly in RTF

http://forums.zotero.org/discussion/25203?page=1#Item_8

steps to replicate:
Install the CMoS (note, annotated bibliography) style
Create a Bibliography of an item with anything in the "Extra" field and save as RTF. Open with Libre Office.
--> the content of "Extra" starts immediately after the end of the bib entry, not on the next line.
Same behavior when using the Libre Office plugin.

This works correctly using "Copy to Clipboard" and pasting to LO.
  • edited September 9, 2012
    I may be off base with this response, but here goes.
    • I think that "Copy to Clipboard" uses QuickCopy internally, and that QuickCopy generates HTML in citeproc-js, which is then converted (whether by the OS, by the word processor or by Zotero, I'm not sure) into RTF when it is inserted into a word processor document.
    but
    • A direct insert into the document via the plugins generates RTF directly in citeproc-js.
    From the symptoms, it looks like there is a difference in the RTF that results from these two processing chains.

    It looks as though the current citeproc-js RTF format does not implement display="block" via stylesheets. This 2007 post by Dan suggests that RTF supports stylesheets (and if I read the RTF 1.5 spec correctly, it does, although how easy they are to manipulate I have no idea).

    The RTF format for citeproc-js was originally provided by Simon at an early stage in the project (I only know enough about RTF to cause mischief). Simon will know whether this is indeed the source of the problem, and may have ideas on how to go about fixing it.
  • AFAIK, there's no formatting you can do with RTF stylesheets that you can't do without them, since they're just aliases for paragraph formatting commands. (Also, as I recall, using styles in the word processor plugins will cause Word to add duplicate styles to the document every time the bibliography gets updated, which is bad.) The easy solution is to change

    "@display/block":"%%STRING%%\\line\r\n",
    to

    "@display/block":"\\line%%STRING%%\\line\r\n",

    Ideally, to mimic display:block in HTML, we'd want to squash the first \line if there's already a linebreak and the second \line if there's a linebreak after. I'm not sure how to do that in citeproc-js, though.
  • Sounds good. Shall I make it:
    "@display/block":"\\line{}%%STRING%%\\line\r\n",
    to avoid corruption by the trailing string characters?
  • It might be enough to control the appearance of the first \line, if I'm reading things correctly. It looks like the only linebreaks inserted into RTF output by citeproc-js or Zotero are in this function, so tracking whether it was the last-issued output may do the trick.
  • edited September 9, 2012
    \line{} is definitely better.

    There are paragraph breaks inserted into RTF output by Zotero when entries are joined together. I think that if we remove \line{} at the beginning of the string and \line\r\n at the end of the string in @bibliography/entry, that should give correct output in most circumstances. However, if a style renders two consecutive elements with display=block sequentially, there would still be a mismatch between the HTML and RTF versions. If this is difficult to handle, we can probably ignore it for now, since it seems like it would be uncommon and simple to work around in the style.
Sign In or Register to comment.