In the exact sciences often only part of a word has special mark up, so I don't know if that counts as a 'kind of text'. The uses of special markup that I'm aware of (note that the mark up of most of this stuff doesn't change from style to style):

Smallcaps are commonly used to indicate the structure of certain chemicals, e.g. the "L" in "L-malic acid".

Numeric superscripts are very common to indicate isotopes (e.g. "13" in 13C-analysis), while numeric subscripts are used to indicate the position of certain atoms within molecules (e.g. "2" in "C2-malate"). In addition to numeric sub and superscript, non-numeric subscript and superscript are often used in abbreviations/symbols (e.g. "vmax" with "max" in subscript, the "+" in superscript in the abbreviated compound name "NAD+").

This kind of markup is also very common in abstracts, but support for title markup is infinitely higher on my wishlist.

Smallcaps are commonly used to indicate the structure of certain chemicals

Also sometimes used for names of software.

Numeric superscripts are very common to indicate isotopes

Note that numeric subscripts are already possible (via unicode input).

WRT to your question, I would expect that titles may in some cases be rendered as italic, but in other cases as normal, or bold, or small caps. I have no data on how common those variations are though.

Underline as well. And sometimes the text style may be used as-is in all citation formats. In other cases, it might need to be changed in some formats. I've seen the same article (a review, errata, or some other article that references another work by title) have either italics or underline in a part of the title, depending on the referencing style.

http://www.google.com/search?q=filetype%3Abib+\textsc

gives several examples of smallcaps in software titles and in chemical names.

I don't know of style guides that mandate the use of smallcaps in software titles & I'm more accustomed to encountering the markup in the abstract or body of an article (where one is more likely to encounter software names).

One interesting example is:
http://dx.doi.org/10.1016/j.pmcj.2005.08.003
That actually mixes smallcaps and normal (title case) text for program names in both the article title and in the bibliography (where the well-used program "Lime" is always set in smallcaps, but additions/frontends/etc. are mixed, as in "Tiny_LIME_").

Any news on this issue?

Thanks, Rintze. Very helpful. Although, I do hope that a better solution is forthcoming soon.

Macro available at:
https://docs.google.com/uc?export=download&id=0B4KgWUjfrk4_NGMwOGFjMTYtMWY4Mi00OTdlLTk5OWEtNjE4ZThjNWMzNmM5

I don't have a lot of experience writing Word macros, so the macro doesn't have a shortcut or button. Just select the macro from the macro menu and run it, and it will convert all the HTML-tag enclosed text to its specified formatting. The .dot file can probably be best installed in the Startup folder of Word, see:
http://www.zotero.org/support/windows_word_plugin_manual_installation_instructions

jonEP,

At the citation processor level, the weather report says "pretty far along". There is now code in the processor to handle markup, which works on some sample data; but it's not quite robust, there are some things that it won't handle correctly, so my initial code needs to be rewriitten. This part will be done by the end of the summer. After that, deployment will depend on the work burden and priorities of Team Zotero.

Rintze's markup-and-macro solution is a good workaround for now, but not ideal given that many titles, etc will have to be-reentered when a fix is finally settled upon.

The 'fix' in the upcoming updated CSL processor will be based on the same set of tags, so there won't be a need to re-enter data. Eventually Zotero might provide some elegant way to apply these tags, but initially they will have to be added by hand, just as with my work-around.

The 'fix' in the upcoming updated CSL processor will be based on the same set of tags, so there won't be a need to re-enter data. Eventually Zotero might provide some elegant way to apply these tags, but initially they will have to be added by hand, just as with my work-around.

It would be ideal if, along the top row of the zotero interface there were an icon for a drop-down rich-text editor--the same features that are available in the "Note" entry window (ie., when you are in the note tab and click on "Add", you then have the ability to enter text in italics, bold, etc.). If this sort of interface were available for entering titles, secondary titles, short titles, etc., it would really help.

As a bit of an aside, I suppose it is obvious, but the use of typed tags and other programming code (as in creating block quotes in the Vanilla forum, for instance!) is second-nature to many of those involved in the zotero project/community, but it is quite offputting to average users. It is a bit like asking them to go back to Wordperfect, circa 1991 (do you remember the "reveal codes" panel, where users saw all of those [tab] and [indent] markers?). Well, it will be good to have a way to put italics in titles, in any event, and I'm sure that the clunk will fall out of the mix in due time...

But adding that interface to such a tight interface is, I don't think, such an obvious thing. There's just not much space.

Maybe shortcuts could be used? E.g. ctrl-i would italicize selected text in the metadata panel? Or perhaps a customized menu could show up if you right-clicked selected text?

What I personally would like to see is rendering of HTML tags (at least in the metadata-column) in Zotero, perhaps with a toggle to show the tags. Tags could be stripped from the fields displayed in the middle column. That would prevent items from being sorted by tags instead of by real field content.

the use of typed tags ... is quite offputting to average users.

Note that this isn't done out of malice or ignorance. It's important to acknowledge that the new CSL processor written by Frank Bennett and Zotero are separate projects. For the CSL processor, the decision was made to support a number of HTML-tags as means of indicating rich text formatting. How programs like Zotero offer support for applying those tags is entirely beyond the CSL processor's scope. It would of course be possible to synchronize development of the CSL processor and Zotero (i.e. not announcing or including support for rich text markup in the CSL processor until Zotero has introduced a nicer way to apply tags), but a) the CSL processor is likely to be used in other projects, so its deployment shouldn't be delayed for Zotero, and b) although a bit rough, rich text support in the proposed form would already be very valuable for many users (including myself). And early adopters might be able to generate valuable feedback, which would benefit the 'average users' in the long run.

I like the idea of shortcuts like ctrl-i, as per Rintze's suggestion.

Another option would be a floating menu bar (like those found in Adobe photoshop, Acrobat, etc.)--that would allow the user to clog or unclog the interface as necessary. It could pop up only during the data-entry, or even perhaps only when you are entering data into a field that accommodates rich text.

Then again, while agreeing that the interface is a bit tight, one more icon along the top row, for turning on or turning off the rich-text entry tools, would not be so bad?

Geoffrey,

Thanks for your thoughtful input. The solution that is currently coded into the new CSL processor addresses your second issue, relating to nesting. Double-quotes inside a title will become single quotes if themselves enclosed in double-quotes supplied by the style. Italics will become normal typeface if themselves enclosed in italics. Same for boldface. So that one is covered.

There was extensive discussion of semantic markup while the current implementation was in the cooker, and titles were the primary example of where it might be useful. An elaborate scheme was proposed involving a full semantic layer, and a clean separation of semantics and presentation. After looking at the shape of that plan, however, everyone involved in the discussion, including its original proposer (me), concluded that it was excessively complicated, and likely to cause more pain than it was worth.

The largest consumer of in-field markup, by volume, will be the life sciences, especially for gene and chemical names. Because the formatting conventions in this case are uniform across the entire field, there is no practical need for semantic markup in this important use case. We therefore decided that the solution should at least permit presentational markup.

Titles may be a case where semantic markup is required, but we're still not quite sure how strong the demand will be. In any case, though, if it is to be implemented, we'll need to have a more clear and concrete idea of the use cases than we do just now. Once in-field markup is out there and available, users who need a little more flexibility to fully cover their needs will provide that feedback, and we'll be able to build something that targets known immediate requirements. There's a lot we don't know about actual practice. Re the MLA rule you cite on underlining ... my understanding is that it is affirmatively discouraged in the current edition. Re style-driven formatting for inner titles generally, some journals apparently display titles in the formatting used in the original publication, treating the title as a literal formatted string ... but we don't yet know how common that practice is.

As the requirements are clarified, though, we'll be able to tune things to meet them. The main thing at the moment is to get the existing solution out there so we can get some feedback.

IMO, whatever the styling and markup of the title&abstract is going to be, it should allow for a simplified search: e.g. "H2O" should be able to find "H₂O". Cheers, M

I can't find those lines in zotero.dot. are you using winword integration 3.0a3?

Is anyone else finding Ritnze's google doc filled with wingdings?

Has a way to insert Ritnze's macros into the Zoterorefresh macro been discovered yet?

The HTML-like tags for italics etc. are recognized by the CSL processor in the 2.1 beta. In the user interface, you'll need to type the tags in by hand, and Zotero will not ignore the tag markup for on-screen sorting (as far as I know). But the basic functionality should work. The 2.1 beta will also do flip-flopping where necessary, both for markup (setting an "italic" species name to roman when the title is in italics), and for quotation marks (from double to single, when quotes are nested).

This all works splendidly on the drawing board. Now that 2.1 beta is out, we'll find out how the feature copes with real-world formatting requirements ...

Not an answer to your question, but why are you including italics in that title? That looks like a book chapter to me, but that you're entering both item and book title in the same title field?

no - real world examples of reversing italics aren't rare at all - any time a book title includes a foreign language word or another book title, for example - and this should absolutely work, but since some users don't use the book section item type correctly I think bdarcus wanted to make sure that you're not misunderstanding something (which you're not - lack of volume titles is indeed an issue, though hopefully one we can resolve before hierarchical item types).
So with that cleared, back to the real issue - this has come up at least once before, I think, but I'm not sure with what results... anyone can test this in a branch xpi to see if recent updates have happened to fix this?

Yes, this works in general. Hard to say where you are going wrong. Two possible sources: The data or something in Word.
To see if the data is the problem, manually create a new item and write in the tags (in unicode - i.e. <i> and </i>.
To see if Word is the problem, see how it looks in the test pane:
chrome://zotero/content/tools/csledit.xul

excellent. FYI someone is working on a fix for the Springer translator, but there are some bumps on the way.

Is it possible to have the Zotero Info Pane italicize <i>words</i> once out of editing (ie, once we hit enter and are no longer editing the field)? That is, show the markup codes when editing a field, but have them visualized/implemented when out of editing?

Is there some way to petition development? It would make my library look much tidier and give me confidence that I'm not screwing things up.

Well, the real fix would be to get rid of the visible markup—which works because the citation processor supports it, not Zotero itself—and just use a stripped down rich-text interface for titles. People shouldn't have to enter HTML themselves.

That will probably happen eventually, but there are no immediate plans to work on it.