Rich Text in Titles
We have had several threads, and several discussions about rich text in titles, but I am hopeful that we can come to a straightforward solution for at least most prevalent use cases.
As previously discussed there are several known situations where italics in titles are important.
Are there other kinds of text that we need inside titles, or for that matter any of the data fields? Does the mark up for these things actually change from style to style much, or could we simply allow some basic mark up like inside title fields?
As previously discussed there are several known situations where italics in titles are important.
- Genus/species names
- Names of genes
- Foreign words
- Names of ships
- Titles inside titles
Are there other kinds of text that we need inside titles, or for that matter any of the data fields? Does the mark up for these things actually change from style to style much, or could we simply allow some basic mark up like inside title fields?
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.
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.
Also, WRT to this notion of being forward-looking, anything you do needs to be compatible with import/export data formats. I gave an example or two in the thread you link to that I think covers both of these issues, though admit it would suggest UI support that is more complex than dumb bold and italic support.
gives several examples of smallcaps in software titles and in chemical 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_").
http://aem.asm.org/cgi/content/full/74/1/1#NOMENCLATURE
Just some excerpts:
"Wild-type characteristics can be designated with a superscript plus (Pol+), and, when necessary for clarity, negative superscripts (Pol–) can be used to designate mutant characteristics. Lowercase superscript letters may be used to further delineate phenotypes (e.g., Strr for streptomycin resistance)."
"Wild-type alleles are indicated with a superscript plus (ara+ his+)."
"Subscripts may be used in two situations. Subscripts may be used to distinguish between genes (having the same name) from different organisms or strains; e.g., hisE. coli or hisK-12 for the his gene of E. coli or strain K-12, respectively, may be used to distinguish this gene from the his gene in another species or strain. An abbreviation may also be used if it is explained. Similarly, a subscript is also used to distinguish between genetic elements that have the same name. For example, the promoters of the gln operon can be designated glnAp1 and glnAp2."
"L-[methyl-14C]methionine"
So here superscripts are used for either designating characteristics, the presence of genes or for isotopes. Subscripts are used to indicate gene origin or to give more information about genetic elements (these extend beyond genes). Italics are also not only used for genes, but also for other genetic elements, and also within names of chemicals (I don't know the rules about the latter). The use of smallcaps seems limited here to indicate chiral information (so you could make a class "Chemistry > D/L chirality"). You would have to distinguish it from another way to mark up chirality, namely the R/S system, which uses italics: http://en.wikipedia.org/wiki/Chirality_(chemistry)#Naming_conventions
<sc>L</sc>-malic acid production using immobilized <i>Saccharomyces cerevisiae</i>
Once I've completed my manuscript, I use the find & replace function of Word to remove the tags and add the required formatting. The set of tags I have devised, together with the search phrase and shortcuts to get the right layout:
Italics, <i>text</i>
Search phrase: [\<](i[\>])(*)[\<]/\1
Replace by \2, use the shortcut ctrl+i
Bold, <b>text</b>
Search phrase: [\<](b[\>])(*)[\<]/\1
Replace by \2, use the shortcut ctrl+b
Superscript, <sup></sup>
Search phrase: [\<](sup[\>])(*)[\<]/\1
Replace by \2, use the shortcut ctrl+shift++
Subscript, <sub></sub>
Search phrase: [\<](sub[\>])(*)[\<]/\1
Replace by \2, use the shortcut ctrl++
Smallcaps, <sc></sc>
Search phrase: [\<](sc[\>])(*)[\<]/\1
Replace by \2, use the shortcut ctrl+shift+k
For instance, to convert all the <i>text</i> elements in the manuscript to 'text' (in italics), I open the find & replace window, enable the option "Use wildcards", paste the search phrase "[\<](i[\>])(*)[\<]/\1" in the find text box, and put "\2" in the replace text box. Then I press the shortcut ctrl+i while the cursor is still in the replace box to get italic output and select the "Replace All"-button. Rinse and repeat for all the different kinds of markup you have used, and you're done. The only thing I don't know if I'll be able to transfer this HTML-tag-based markup to any future rich text support implemented by Zotero, but at least it solves my problem in the meantime.
P.S. I found this documentation very useful in dealing with Word wildcards:
http://word.mvps.org/FAQs/General/UsingWildcards.htm
[edit: see also my later comment a few posts below for a Word macro, which automates these find & replace operations]
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
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.
Thanks.
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.
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...
As for your other comments, the conventions are much simpler than adding HTML tags. This is not to say I don't recognize it may not be the ideal solution for many, but it's still, as you say, better than nothing.
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. 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.
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?
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.
I'm not sure how far off the update is. In the meantime I have found it convenient to adopt Rintze's solution.
With some editing of Zotero's macros, the HTMLtagconversion macro can be run automatically.
This is accomplished by opening zotero.dot, going to the visual basic editor, pasting in the HTMLtagconversion macro code, and adding the two lines to fnUpdate(). The code I show below starts at line 461, and the added lines are marked.
If (mResultArray(0) <> "!") Then
For i = 0 To (j - 1)
Call subInsertFormattedText(mMarks(mBibliographies(i)), (mResultArray(0)), bUpdateTemp)
**add** subSelect (mMarks(mBibliographies(i)))
**add** HTMLtagconversion
Next i
Andras
I took a quick look at the code in 3.0a3 and it is quite different. You can still paste in the HTMLtagconversion code in the ZoteroRefresh subroutine, but you will need to make sure that the bibliography is selected for the code to work. There is a lot of code in 1.0b3 that allows that to happen easily, and it all seems to be gone from the macro code in 3.0a3.
Anyhow, if you need to manually select the bibliography, then it's easy enough to assign a button to the HTMLtagconversion macro.