Roman Text in Italicized Titles

[dstark]

It's sometimes necessary to have roman text in otherwise italic titles as, for instance, when a book title contains a book title.

Zotero's citeproc-js handles this reversal wherever <i> tags appear (i.e., <i> reverses the italic state, whether roman to italic or italic to roman; e.g., Understanding <i>BHS</i>: a manual for the users of <i>Biblia Hebraica Stuttgartensia</i> renders BHS and Biblia Hebraica Stuttgartensia in roman if the title itself is italicized or in italic if the title is otherwise in roman).

Is this a useful quirk of citeproc-js where Pandoc citeproc doesn't intend to produce similar output? A limitation in Pandoc citeproc that could stand to be built out? Or a case where Pandoc citeproc already handles this use case but simply needs the input a bit differently than in the example above?

Thanks so much for the clarification!

N.B.: <em> rather than <i> simply gets <em> passed through as if it's part of the title.

[DahanItamar]

I reproduced this with Pandoc 3.12.1. For CSL JSON input, your <i>...</i> markup is recognised, but the result depends on the output format.

With a minimal CSL style that renders the title using font-style="italic", your example produces nested emphasis in Pandoc's AST:

Emph [ ..., Emph [Str "BHS"], ..., Emph [ ... ] ]

The HTML writer emits:

<em>Understanding <em>BHS</em>: a manual for the users of <em>Biblia Hebraica Stuttgartensia</em></em>

A browser's default styling leaves those inner words italic. In contrast, the LaTeX writer emits nested \emph{...} commands, which normally reverse emphasis inside an emphasised passage. So changing <i> to <em> in the bibliography isn't the solution: <em> isn't one of the supported CSL JSON formatting tags.

For HTML output, you can keep the CSL JSON title as written and apply CSS for this nesting level:

em em { font-style: normal; }

If your titles contain a third emphasis level, add em em em { font-style: italic; }. Scope these rules to the relevant bibliography or notes container if you don't want them applied elsewhere.

One separate input-format detail: YAML bibliography fields and inline YAML references use Pandoc Markdown, so use *BHS* there instead of literal HTML tags.

The citeproc library's CSL JSON renderer implements flip-flopping, while its Pandoc output instance represents italics as emphasis. That distinction explains why the same library can pass its HTML flip-flop tests while Pandoc's HTML output still contains nested <em> elements.

[jgm]

If I recall, the reason I went with nested Emph in the Pandoc output of citeproc is that the flip-flopping can be handled at the writer level. Indeed, if you process

\emph{hi \emph{inner} outer}

with latex, you'll see that it takes care of this automatically. Similarly, as noted above, you can achieve flip-flopping in HTML with CSS (I thought we had something like this in the default style, but I don't see it).

However, support for this is uneven across writers, and it might be worth thinking about what it would take to implement flip-flopping in the Pandoc instance for citeproc. In HTML, we simply use <span style="font-style:normal">; nothing needs to change in the nesting. We could do something similar in pandoc, using a Span with a class, but the problem is then that the writers would all have to be adjusted to react to this Span. A more radical and complex change would lead to pandoc code like

[Emph [Str "hi"], Space, Str "inner", Space, Emph [Str "outer"]] 

for the case above. But this tends to lead to pretty ugly output; keeping the nested structure and dealing with it in writers or with styles may be a better approach.

[jgm]

I see that we do have this in the default epub.css:

em, em em em, em em em em em {
  font-style: italic;
}
em em, em em em em {
  font-style: normal;
}

[dstark]

Thank you both. And my apologies for the delay in getting back to this thread. The particular scenario behind the example above is rendering Pandoc Markdown to DOCX.

Is this something that looks like a good candidate for adjustment in the DOCX writer? Just to be sure, I've double checked that the output is the same in v3.13.

If not, I'll take a stab at a LUA filter to adjust the italics in the DOCX.

Thanks so much!

[jgm]

I'm going to push a fix to the docx writer that implements flip-flopping for nested emph.
I'll also add the snippet above (in the epub.css) to the default HTML css.
After these changes, both docx and HTML should behave properly with no need for a filter.