Upgrade StorageWord Plugin/Zotero Feature Request: Flexible Commentary in Footnotes (via Flexible Fonts)
The following request seems rather non-trivial from a non-developer point of view but is nevertheless incredibly useful for researchers hoping to use the Zotero Plugin to Word (or OOo) for works requiring some variety of differing languages in footnotes connected to citations (or in the work title itself):
The following scenario is at issue: As there is no readily available Unicode font (so as not to break the bank -- particularly if a good looking non-serif font is desired -- and no, MS Arial Unicode is sadly insufficient ;) ) to properly represent languages such as Greek and Hebrew with diacritics in citation prefixes or suffixes (as in development in Zotero Ticket #462) some other means of representing these languages is necessary.
Several options present themselves -- at least to a non-developer like myself -- some better than others:
1. Allow disconnected commentary in footnotes that contain citations. Cons: This likely presents significant problems for properly dealing with such commentary in changing/reformatting to in-text citation styles. Even EndNote X1 handles this situation insufficiently well (when no reformatting occurs) for it assumes that each footnote contains a citation (even when it does not) and so formats the following footnote citation -- even if it references the same source as the last preceding citation -- as a regular citation rather than the correct ibid. citation (EndNote loses track of citations if any commentary only footnote is inserted). Nota Bene/Ibidem/Archiva do handle this correctly but do so because they handle fonts differently. This approach also does not allow for consistency with fonts in the title of the citation itself.
2. Require that all citations be from Zotero (as a rule so as not to confuse Zotero as EndNote can be confused) and at the same time allow specific font information to be 'hard-coded' into all aspects of a Zotero citation including prefixes and suffixes. This information would best be presented as a selection of a special font for a subselection as well as a special font size adjustment (such as: adjust font size by X points | where X=+/-1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 [this should be enough to account for most of the font size discrepancies]). Providing absolute/non-relative font adjustments like EndNote does is a inferior solution because it results in fonts being too small in the bibliography and too big in the footnotes. Cons: requires the implementation of a font selection framework in Zotero so that both an independant/non-standard font and relative font size can be chosen for a section of the input text* (and the corresponding display ability with perhaps a clue system to show that such special formating is present -- such as changing that section's font color to red [or some other indicator]). Removal of the special formatting may be accomplished by deleting the specially formatted text or perhaps in a right click menu: "remove (all) special (font) formatting."
3. [Additional ideas/approaches go here ;)]
Of the two approaches presented above, I strongly favor option 2 -- even though it very likely requires more coding it nevertheless appears to be the future-proofed way to handle these issues. Text without special formatting adopts the formating of the (Word/OOo) document and the specially formatted text retains its 'hard-coded' format when the citation is inserted. In this manner a specific font for Hebrew could always be employed etc...
Future versions of the implementation could allow a special font toolbar with 5 (or some options selected number -- within usability limits) presets that would allow for quick special formatting of text in Zotero (highlight text to be special formatted > click preset format '1' > done). While I'm still dreaming ;), changing the format of "preset format '1'" at some later point in time (in the options that come up when one right clicks on it's icon in the toolbar) would adjust all Zotero text which uses this special preset format. Such an implementation would future-proof the approach even further by enabling the user to quickly change such fonts as better typefaces are developed (specifically for Unicode rendered text).
I recognize this enhancement is not necessary for monolingual research but it nevertheless is absolutely indispensable for anyone trying to use Zotero in a scholarly way in a multilingual field.
In hope that Zotero continues to develop as a truly useful scholarly product -- and that a creative and sufficiently powerful solution is found to this issue -- thanks again for all the work that has been accomplished already,
An interested Zotero user.
* Some of this may be readily available in the Mozilla framework due to 'Composer.'
The following scenario is at issue: As there is no readily available Unicode font (so as not to break the bank -- particularly if a good looking non-serif font is desired -- and no, MS Arial Unicode is sadly insufficient ;) ) to properly represent languages such as Greek and Hebrew with diacritics in citation prefixes or suffixes (as in development in Zotero Ticket #462) some other means of representing these languages is necessary.
Several options present themselves -- at least to a non-developer like myself -- some better than others:
1. Allow disconnected commentary in footnotes that contain citations. Cons: This likely presents significant problems for properly dealing with such commentary in changing/reformatting to in-text citation styles. Even EndNote X1 handles this situation insufficiently well (when no reformatting occurs) for it assumes that each footnote contains a citation (even when it does not) and so formats the following footnote citation -- even if it references the same source as the last preceding citation -- as a regular citation rather than the correct ibid. citation (EndNote loses track of citations if any commentary only footnote is inserted). Nota Bene/Ibidem/Archiva do handle this correctly but do so because they handle fonts differently. This approach also does not allow for consistency with fonts in the title of the citation itself.
2. Require that all citations be from Zotero (as a rule so as not to confuse Zotero as EndNote can be confused) and at the same time allow specific font information to be 'hard-coded' into all aspects of a Zotero citation including prefixes and suffixes. This information would best be presented as a selection of a special font for a subselection as well as a special font size adjustment (such as: adjust font size by X points | where X=+/-1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 [this should be enough to account for most of the font size discrepancies]). Providing absolute/non-relative font adjustments like EndNote does is a inferior solution because it results in fonts being too small in the bibliography and too big in the footnotes. Cons: requires the implementation of a font selection framework in Zotero so that both an independant/non-standard font and relative font size can be chosen for a section of the input text* (and the corresponding display ability with perhaps a clue system to show that such special formating is present -- such as changing that section's font color to red [or some other indicator]). Removal of the special formatting may be accomplished by deleting the specially formatted text or perhaps in a right click menu: "remove (all) special (font) formatting."
3. [Additional ideas/approaches go here ;)]
Of the two approaches presented above, I strongly favor option 2 -- even though it very likely requires more coding it nevertheless appears to be the future-proofed way to handle these issues. Text without special formatting adopts the formating of the (Word/OOo) document and the specially formatted text retains its 'hard-coded' format when the citation is inserted. In this manner a specific font for Hebrew could always be employed etc...
Future versions of the implementation could allow a special font toolbar with 5 (or some options selected number -- within usability limits) presets that would allow for quick special formatting of text in Zotero (highlight text to be special formatted > click preset format '1' > done). While I'm still dreaming ;), changing the format of "preset format '1'" at some later point in time (in the options that come up when one right clicks on it's icon in the toolbar) would adjust all Zotero text which uses this special preset format. Such an implementation would future-proof the approach even further by enabling the user to quickly change such fonts as better typefaces are developed (specifically for Unicode rendered text).
I recognize this enhancement is not necessary for monolingual research but it nevertheless is absolutely indispensable for anyone trying to use Zotero in a scholarly way in a multilingual field.
In hope that Zotero continues to develop as a truly useful scholarly product -- and that a creative and sufficiently powerful solution is found to this issue -- thanks again for all the work that has been accomplished already,
An interested Zotero user.
* Some of this may be readily available in the Mozilla framework due to 'Composer.'
The limited coverage, inflexibility and stylistically limited nature of contemporary fonts (Unicode and otherwise) is the real issue here. Nevertheless, a good font solution (as in the affordable availability of serif and non-serif fonts with sufficient Unicode coverage) is still far away at this point (from my research). Consequently, in my view, all bibliographic contemporary solutions must grapple with these important and pragmatic issues in some way.
An interested Zotero user.
If I guess what you are saying, you are asking for ways to enter non-Western scripts in your citations. Further, you are saying these characters are sometimes not even supported in Unicode?
If I'm close to right, then I don't see how any of this is Zotero's responsibility. It is your word-processor's, or operating system's, or fonts, or even unicode.
The only connection I really see is the need to add commentary to citations. That's coming.
I'd have to agree with Bruce that this isn't Zotero's responsibility. It'd require a tremendous amount of work and added complexity to achieve something that—if I'm understanding the issue—would be solved automatically if there was just a font that covered more of Unicode.
clip: Am I interpreting this correctly?
I'll try to be a bit more clear.
The problem is with Unicode/font coverage and font size. It is currently not possible to output a sufficiently good-looking citation from Zotero to Word (and OOo too I assume) because:
1. Even if Unicode does cover the diacritics correctly (and no one font does them all well) the font size discrepancy in the same font (for example Hebrew in MS Arial Unicode) makes the output non-ideal.
2. furthermore, even though the user may want Arial (or some non-serif font for the Western text), the same user is likely to want to use another font to display Hebrew, Greek, Coptic, Syriac, etc... for readability's and common convention's (journal usage's) sake.
3. Because this is a recognized weakness of OSs, fonts and current Unicode implementations, software such as Nota Bene must resort to utilizing its own internal representation of non-Western scripts -- connected to the transposing of all copied texts into this unique internal representation -- which is furthermore dependent on proprietary sub-fonts which are not licensed so as to permit embedding (even in something as pragmatic as PDF output -- even though the company appears to offer a PDF output solution which bypasses the font license restrictions -- unlike Adobe Acrobat). This approach means that the text cannot even be exported to any other word processor (such as Word) without data and format loss. Despite these tremendous weaknesses, Nota Bene appears to be the only solution which is trying to tackle these current (OSs/fonts) issues.
4. Simply reformatting or otherwise specially adjusting the Zotero output text in the word processor (Word) results in all such changes being removed upon the next Zoter update/style change -- and hence such an approach is not a viable solution.
I hope this is a bit more clear. In summary: specifying multiple fonts is needed to allow for good looking/journal ready citations & commentary in the current OS/font environments -- hence Nota Bene's solution (suboptimal as it is in some respects). Disclaimer: I only have Windows & Linux experience.
Just to be clear: the necessary mix of fonts exist to accomplish this (by using them in multiplicity) it is just that no one font can do it all and hence the need for this 'mixing and matching' in citations & commentary.
Hope that helps ...
Re: 1st Post:
I would agree in part: greater coverage would be good but journals usually use a separate font for the main text and another for the special non-Western text (due to looks conventions -- for example: people are not used to reading Hb. or Gk. in Arial). Hence even greater Unicode coverage would not be enough until such a mixed scholarly Unicode font was developed (not something that is likely anytime soon by my limited research).
Re: 2nd Post:
This would be a viable solution (it is not present in the current plugin as per my trials of it). The only con. I can see here is that the text will be represented as unreadable within Zotero and then become readable when the correct format was applied in Word. If Zotero was indeed able to maintain these distinct formats for sections of citations and commentary during updates and style changes this would be acceptable. Maybe not the most pretty/intuitive (or perhaps as future proof as some of my 'lay' imaginings) --on the Zotero side -- but definitely sufficient for the job.
But in any case ... I really don't think it's practical to edit formatted citations (the fields, which are designed to be updated) and preserve that across updates. If you're now so dependent on specific fonts *within* citations (say a title uses font x, a year uses font y, and so forth; or even worse, that specific characters within a field might need different fonts), then I think you're going to be stuck doing a lot of manual formatting.
Come to think of it, one thing that might make this easier is if the citations and bibliographic entries Zotero generates are all tagged with styles. Perhaps, then, one could globally change the styles and that might be preserved across updates?
I really don't know; I'm still unsure of all the details.
Preserving formatting across content updates seems considerably trickier. Word itself attempts to preserve formatting to a certain degree: if I create a time field with the "Preserve formatting during updates" switch on, Word will set the formatting of the different parts of the time string based on the formatting of the first character in each part. For example, if I bold the "7" in the string "7:46", "7:47" will be bold when I update. Likewise, if I make the "P" in "PM" italic, it will set "PM" to italic on update.
The first part (no-change updates) seems like it should be doable. Something resembling the second part—say, preserving the formatting for the different parts of the citations (title, author, year) based on the first letter—seems like it might be possible and might at least reduce the number of manual edits that were necessary after a change of the field's content. I also like Bruce's idea of adding styles to the various parts, which would provide some general customizability (though I imagine it would be pretty insufficient for the issue at hand).
Some way of locking a field (or all Zotero fields) from updates altogether might also be helpful.
I'll see if John, Ian or Simon can comment on any of these issues.
First, as mentioned, the ability to have freely formatted text in a note around a citation is already under development. This would be (close to) proposed solution #1 in the original post. This does not address the problem of having separate fonts within a citation.
clip, a couple times you hint that if you were willing to spend the money, you could in fact get a font that solves your problem. Is that right? You may just need to shell out the cash. Specialized fonts are expensive to develop. No way around that.
Alternatively, instead of kicking the problem over to the providers of free software, maybe the solution is to get people who care about this problem to pitch in and build free Unicode fonts.
A font to do what you need would also enable a solution that worked both within Zotero and in the word processor.
I don't see any problem with Dan's proposal that the plugin not update a field if its text has not changed, thus allowing manual changes to stick across updates. The plugin doesn't work this way now, but I think it would be a straightforward enhancement.
But if these changes were being made in the word processor instead of in Zotero, the resulting citation would appear different from one in the Zotero pane. Again, if you just had one font that did the needed work, this wouldn't happen.
If you are willing to have a solution just in the word processor, there are a few workarounds that could get you want you need.
The plugin currently italicizes text that appears between underscores in the Zotero repository. This is not ideal. As with the above idea, it formats text in the word-processor without changing how it looks in the Zotero pane. But it works.
A similar hack could be inserted into the plugin by which an alternate font is encoded and decoded in the string. Currently, the underscores in _arete_ tell the plugin to display arete in italics. You could have the ^ marks in ^arete^ tell the plugin to display arete in an alternate font (or style).
This functionality for italicizing is a short-term hack, and there have been discussions about putting wiki formatting into the Zotero base. If that's done, the hack in the plugin can be removed. I don't see font/style tagging getting incorporated into the base anytime soon. But something like the italics hack could be done.
Where to put this hack? The plugin people could add it to the released version, but not without adding a lot more than got added for italics. Where, for example, does the user specific the alternate font? Is it just typeface or font size as well? Is one alternate enough?
Instead, the user could just hack the plugin and hardcode in the alternate font.
Or if the user is uncomfortable hacking the plugin, he or she could handle the transformation in a small macro. Just write a macro that searches a document for ^xxxx^ and changes the font of xxxx. Run the macro after doing a Zotero update (you could even customize the Zotero update button so that this macros always runs after the update).
I've long done this sort of thing to get around limitations in Endnote. Endnote inserts my citations with tags, and my clean-up macro replaces tagged code with what is needed. It's a kludge, but it works.
Building intrafield font selection into the repository should, in my opinion, be a low priority. Much else needs to get done first. In the meantime, I'd say (1) use a search-and-replace macro, (2) hack the plugin to format tagged text with an alternate font, or (3) buy/build a suitable font.
Perhaps an example may be helpful. We could imagine something akin to the following for a citation and commentary (initially as part of a Chicago footnote):
Though the relatively flexible δικαιοσύνην is sometimes used to translate חֶסֶד (chesed) in the LXX, it does not sufficiently represent its range of meaning. For further discussion of these Themen see: {imagine a citation here which possesses a title that incorporates both Gk. & Hb. script}
What is usually further required (for example) is that the Hebrew script here be formatted in Ezra SIL Unicode Font (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=EzraSIL_Home) and the Greek in something like the Doulos SIL Unicode Font (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=DoulosSILfont). Hence just using MS Arial Unicode does not suffice. In addition, sometimes the size of one font has to be adjusted to ‘fit’ size-wise with the default text font (and other utilized fonts).
To bdarcus & Dan Stillman,
Something which I also realized: as in the above made up example, italics is sometimes also needed in commentary. This is why EndNote X1 (for example) has a UI which allows for font selection (though painfully limited) and font size selection (regrettably in absolute rather than relative sizes) in citation elements. It does a much worse job of allowing such (and italics) in commentary prefixes and suffixes. As unwieldy and insufficient as it currently is, EndNote has nevertheless slowly begun to tackle these issues. To be fair to EndNote, it (unlike the current Zotero plugin) allows for commentary to exist completely separately from citations in footnotes (as per option 1 in my initial posting). As noted earlier, this approach has its strengths and limitations.
Bdarcus wrote: “or even worse, that specific characters within a field might need different fonts” – this is indeed the issue. “Come to think of it, one thing that might make this easier is if the citations and bibliographic entries Zotero generates are all tagged with styles. Perhaps, then, one could globally change the styles and that might be preserved across updates?” – this would be great if it would work.
Stillman: “Something resembling the second part—say, preserving the formatting for the different parts of the citations (title, author, year) based on the first letter—seems like it might be possible and might at least reduce the number of manual edits that were necessary after a change of the field's content.” – a step in the right direction but would still cause significant post-reformatting in the situation of the example above. “Some way of locking a field (or all Zotero fields) from updates altogether might also be helpful.” – this however will not future-proof the approach for applying a later change in citation styles (at least without more complex logic – and even then such a citation style change would result in the need to reformat – hence my original option 2 suggestion).
To mccaskey,
“clip, a couple times you hint that if you were willing to spend the money, you could in fact get a font that solves your problem. Is that right? You may just need to shell out the cash. Specialized fonts are expensive to develop. No way around that.” To my knowledge, no such font exist as yet (I’d have to shell out the cash for creating a whole new comprehensive Unicode font for scholars – beyond even what organizations like SIL and SBL have been able to accomplish – thus the problem is being addressed and organizations/individuals are pitching in but the solution that Zotero requires is still significantly far off [I estimate in the order of years]), and unfortunately the corollary is that journal/publication grade output therefore requires a mixing of the currently available fonts (see the start of this post).
“If you are willing to have a solution just in the word processor, there are a few workarounds that could get you want you need.” Thanks – that would definitely be a step in the right direction :)!
I started writing this post before yours appeared: “The plugin currently italicizes text that appears between underscores in the Zotero repository. This is not ideal. As with the above idea, it formats text in the word-processor without changing how it looks in the Zotero pane. But it works.” This solves the italics issue I noted above – great!
Let me respond to your other suggestions in a following post ...
Clip.
“Where to put this hack? The plugin people could add it to the released version, but not without adding a lot more than got added for italics. Where, for example, does the user specific the alternate font? Is it just typeface or font size as well? Is one alternate enough?” One alternative is not enough. A general, html-like approach could be provided for specifying font though the relative increase or decrease of font size may be a bit more tricky to control in this manner – don’t know.
“Or if the user is uncomfortable hacking the plugin, he or she could handle the transformation in a small macro. Just write a macro that searches a document for ^xxxx^ and changes the font of xxxx. Run the macro after doing a Zotero update (you could even customize the Zotero update button so that this macros always runs after the update).” This is indeed a viable solution (though not too friendly for Zotero’s technophobe users ;) -- to be clear: those users that are not as tech saavy).
“Building intrafield font selection into the repository should, in my opinion, be a low priority. Much else needs to get done first. In the meantime, I'd say (1) use a search-and-replace macro, (2) hack the plugin to format tagged text with an alternate font, or (3) buy/build a suitable font.” Suggestion 1 seems to be the most user-friendly (suggestion 3, as noted earlier is not, to my knowledge, a current or soon coming possibility [while, as mentioned earlier, scholarly fonts are being worked on, I am not aware of any appropriately {so as to fit Zotero as it is now} 'unified' font project* or project plan {hence Nota Bene's approach} -- it could be years, possibly even a decade -- again: no concrete idea surfaces despite my Unicode font info search]).
My hope in starting this thread was to make Zotero/OOo Bibliographic developers aware of this need (just in case they weren’t already). While an efficient UI-driven solution (in Zotero/plugin itself) would be really nice for myself and others having similar requirements, I recognize that such capabilities are possibly quite intrusive to the codebase and may need to be left to the future. If another solution can germinate from Bruce’s and Dan’s comments, that would be great! Nevertheless, if an (original post) option 2-like solution is what is needed long-term (as you appear to assent) – then here’s to the future ;)!
Thanks for your detailed reply,
Clip.
* 'Unified' in the sense of bringing together typefaces which will fit general/journal font style requirements which are currently met via employing a multiplicity of fonts.
I can envisage two enhancements to the plug-in:
1. Have a way of changing the 'field' name, to say "ZOTERO_KEEP", so that any changes, either font or text, within the field remain. An approach could be that when a 'field' is selected and the user clicks the insert button, an option is to change the field name so that it doesn't get updated. But, what if the user changes the citation style? Should the macro check with the user for each citation that has this "KEEP" 'property'?
2. Extending or replacing John's (mccaskey) italic concept for character styles. Thus in Zotero a user could edit a citation so that it included style information like "^arete^", where "arete" is a character style that gets created if it doesn't already exist. If the style needs to be created the macro could display the relevant dialog for setting the attributes. In OOo Writer it is possible to have relative font sizes (e.g. 90%, 110%) but not in Microsoft Word.
Have I understood correctly? Would these enhancements meet the need?
Your perception is correct and your suggestions are very good. They would get me to 80% on Word (to pick a perceived percentage out of the efficiency hat) and to 100% on OOo (I currently prefer my copy of Word XP until OOo with the planned next-gen. Bibliographic Management [yes, I think it deserves capitals ;)] comes out).
Allow me to also respond in terms of some details:
With respect to 1.: This may be advantageous for some users but, from what I understand, would require additional reformatting after changes in citation style as the “KEEP” formats would not be brought forward without implementing additional logic. From my non-developer perspective and as far as the issue I presented is concerned, your solution 2 would be enough by itself. My perception is that it would just “do the right thing” even after a citation style change (without the need to mark a citation as “KEEP”).*
With respect to 2.: As mentioned, from my perspective this “extending” is the way to go — your suggestion is very elegant and efficient.** This approach does not suffer from the problem issues that would occur with attempting to employ approach 1 (see footnote *).
Some additional future ideas (while we're at it): Dreaming concerning the last 20% for Word [I have left my initial suggestion, though not so good, here to clarify my developing thought process > this paragraph should be mentally adjusted as per the conceptually clearer thoughts of footnote *** {which was added later} > specifically: it is footnotes that would need a "FN_DECREASE"-like 'tagging'/adjusting rather than the here suggested “BIB_INCREASE” tag]:
OOo is great, for the Word plugin it would also really be nice if a bit of logic could be added that did something akin to the following (what I gather OOo accomplishes with relative size settings): in the bibliography increase the “BIB_INCREASE” tagged text*** by 2 points (this is the usual point size difference between footnotes and the bibliography).**** This tag would be ignored in generating the footnotes (which would use the otherwise ^tagged^ style [ex: ‘appropriate Hebrew font’ @ 14 points]) and adjust the Bibliography output by 2 points [ex: to ‘appropriate Hebrew font’ @ 16 points]. There may be a more elegant solution for this in Word — no clue — but you get my aim.***** Something such as this would bring Word up to OOo’s 100% user efficiency level (with your proposal 2).
Eagerly looking forward to the implementation of your ideas,
Clip.
_________________
* Hence I would not use this “KEEP” property to format my citations but only to solve another theoretical issue: instances where Zotero does not format a citation to my liking on other grounds (perhaps it hasn’t implemented that particular blog citation style just right yet [to make up an example]). Consequently, solution 1 may be useful for other issues — though I would try to avoid its use and rather urge for ‘upstream’ correction/expansion. It is nevertheless a very convenient stop-gap measure if citation conversions are not likely to be required. It will likely have its share of issues too (without additional logic) like not converting to ibid. when it should if an identical citation source is later inserted immediately in front of it. It is for reasons such as these that I would try to avoid it like the plague unless there was just no other way (for the sake of future-proofing the document).
** Using the word processor to process this side of things has only one, though in my view insignificant, drawback: the citation will look convoluted in Zotero. This is likely why Bruce and others suggested the more complex solution of font format/style tagging in Zotero itself (assuming I understood those suggestions correctly). This would return us to an initial-post-option-2-like suggestion. This more user-friendly development can certainly wait for some future release — from my point of view — as long as users are made aware of the word-processor-side power available to them through your proposed extension (your solution 2).
*** Come to think of it: All ^tagged^ font formats (I can currently think of no exception cases) will need to undergo this transition in Word from a footnote to a bibliography citation — unless the citations are inline citations. This leads me to think that another form of logic would be much better: The user’s ^tagged^ and defined font should always (in Word) be defined at the in-text and bibliography size (this is the size the user should select in the Word style dialogue — this could/would be made a rule and explained in the usage notes). Additionally, anytime the style comes up in a footnote: it should/would be reduced by two points. Whether it is best to accomplish this by the Plugin simultaneously defining a second style which is derived from the first (and named something like stylename_FN where “stylename” is the name of the parent style) and using it in footnotes or choosing another implementation is out of my ken. My hastily proposed implementation here would likely cause round trip issues between Word and OOo and thus another more automated (less dependant on a secondary font format/style definition) would be preferable for the future — no idea really how to do this best.
**** From my experience, more flexibility here is not (immediately) required due to the very common/rarely broken difference of 2 points.
***** Okay maybe this is being too perfectionistic (for a simple final, macro or hand-done, reformatting of the affected bibliography citations would also work) — I only mention it as a future-looking conception/goal so that things “just work.”
Don't implement option 1 as there too many problems with the "keep" concept.
Implement creating, when necessary, and applying character styles to text that comes from Zotero that contains ^charstylename^.
On getting text that has ^charstylename^, check if the styles ("charstylename" and "charstylename_fn") already exist in the document and if not create them. Display a dialog for the user to define the styles attributes. charstylename_fn is identical to charstylename but with the font size being to points smaller, and is applied only in footnotes.
Pending any other comments I will try and implement this.
From where I'm standing:
1. Yeah that's great -- just as you suggest: no to option 1 and yes to ^charstylename^ (I'll assume you meant "2 points smaller").
2. I also assume that the user only has to define "charstylename" (in the dialogue) and "charstylename_fn" is created automatically. This would be ideal -- but, if not so automated: the user could step through two dialogues if need be (not as elegant but I'd personally be okay with it if necessary).
3. Please also retain the _italics_ function/definition. Particularly for the coming commentary (especially if it is designed in terms of Zotero/plugin controlled prefixes and suffixes).
Sounds really good -- can't wait,
clip.
RE: Fonts. I second clip's judgment about fonts. Even in a Unicode world, we will have to deal with different fonts in documents which used more than one script, particularly for documents destined for printing. The reason is that the visual conventions and typographic traditions of the reading communities are so different, and so exacting, that for any font publisher to make a quality font for more than a few scripts is a herculean feat. No one has managed it at any price so far for the combination of Latin scripts, Greek and Hebrew. And what if you need Arabic or Coptic? Even if you managed to get the letter forms right, there would still be the issue of relative sizing. Hebrew letters generally need to be bigger than Latin letters for the same degree of readability, (a requirement which eases as the end product gets bigger) and languages with heavy dependance on diacritics just can't get too small, or they become invisible.
All that is just to say that I appreciate the discussion. My solution just now (since my thesis can't wait) is just to use Zotero to keep my data, and copy it into my document without fields in plain text. No bibliographic style switching possible, which is a shame, but not enough of one to keep me waiting.
If we're going to support anything on the Zotero side, it'd probably be HTML—that is, something like <span class="hebrew">חֶסֶד</span>. Having the plugin automatically create a second style for footnotes probably makes sense, at least for Word users. (Does Word 2007 offer relative sizing in styles? If so, we could forget about the separate footnote styles.)
In addition to the familiarity for users, HTML would also be much easier to handle within Mozilla (say, to toggle between raw and rendered modes), and down the line we could potentially allow users to use the classes when displaying the citations in Zotero as well, either through a style interface or just a user-created CSS file that was applied to the rendering.
I didn't really follow all of clip's suggestions, so maybe I'm missing something, but I don't think having Zotero or the plugin do much more than that is necessary. Presumably you just have a few styles that you put in your default template, so once you've set them up, it's just a question of tagging things properly in Zotero, and you don't need to worry about it any more.
My apologies for not being clearer. Yes the codes "^xxxx^ would need to enclose the text in the same way that we currently have underscores enclosing text to be italicized.
As I understand it John implemented the underscore feature to get around the problem of titles requiring some of the text to italicized so this is an extension of that concept for even more generic use.
In ^xxxx^example^xxxx^, xxxx = character style name and "example" = the text to have that character style.
Currently Zotero passes RTF text to the plugin. The only RTF tags implemented are:
i for italics
b for bold
scaps for small capitals.
Dan are you saying that Zotero will use HTML instead of RTF?
Or should we extend the RTF tags to include Font and (relative?) font size information?
I see the character style concept as being a hack to get around current limitations in Zotero, but provide users with the level of flexibility they require.
To Ian: from personal frustration experience: if you are using Firefox (2.x) you can hit "Add ..." then sign in and then press "Go back one page" (2x or so) in FF and okay the repost dialog and your comments will be posted. Anyway, worked for me... Don't mean to say a better/more discoverable system wouldn't be appreciated ;) (I had to rewrite the 1st post three times before I stumbled across this) ...
As for what to pass to word processors, I'd defer to someone who knows the RTF spec better, but it looks like RTF does support styles. From my quick tests, it seems we could just pass empty styles matching the HTML class names and then A) if there already was a document style with the same name, update the empty-styled contents so that they took on any formatting in the existing document style or B) if there was no matching document style but there was a matching style from the default template, overwrite the auto-created empty document style with the global one. Or some variation on that? Note that I don't know how the RTF passed from Zotero is integrated into the document, so maybe this is all crazy talk, but I've been able to replicate this procedure by loading a hand-edited RTF file with empty styles and using the Organizer in Word to overwrite the document style with one from the default template (as well as just by editing the auto-created empty style).
The other option would be to add the ability within the Zotero prefs to define fonts and font sizes for classes and have those be passed along with the styles, but I'm trying to think of this more broadly than just for the original use case, and I'm not crazy about starting to add all the various possible formatting options to Zotero and generating proper RTF for them. The benefit would be that exported RTFs would "just work," even in non-Zotero-enabled readers, and unless we were going to go the user-created CSS file route I mentioned above, we'd need an interface to set how the classes would be rendered in Zotero itself anyway. At any rate, we'd probably have to do the style updating on the plugin side anyway to support formatting options that hadn't been added to Zotero, so we could do the empty style part first and perhaps consider adding an interface like this to Zotero itself down the line...
Please don't make us all upgrade to Word 2007 ;) -- I have no idea if it can handle relative font sizes -- even if it does, there is something to be said for enabling a little backwards compatibility.
"In addition to the familiarity for users, HTML would also be much easier to handle within Mozilla (say, to toggle between raw and rendered modes), and down the line we could potentially allow users to use the classes when displaying the citations in Zotero as well, either through a style interface or just a user-created CSS file that was applied to the rendering." Something like this is what I was aiming at in thinking about the future in my post 1 option 2 -- namely: providing a style interface in Zotero (font, relative font size [plus a Word-suitable plugin implementation], italics, [bold])* which is friendly even for non-techies.
Having said this I nevertheless deeply appreciate Ian's approach to tackling these needs in the shorter term.
________________
* This could either be implemented as: [1] a style toolbar: Font; Rel. Size; Italics; [Bold], or [2] as a "Format Painter" toolbar [think Word's apply format tool] with a user-defined number of icons which are left-clicked to apply and right-clicked to bring up a style dialogue with the above [1] settings plus a setting for choosing a representative icon for the toolbar (as per the "Future versions of the implementation ..." paragraph of post 1 {in-Zotero rendering would remove the need for some kind of "clue" system}. Personally I favor option [2] even though it is less discoverable for it is more efficient/practical usage-wise and also future-proof (as per my thoughts on global font change in post 1).
For example: my "Format Painter" bar {at the top of the right Zotero pane} would include (among others) an italics icon, Greek icon, Hebrew icon, Coptic icon, Syriac Icon ... several cuneiform icons ... etc.
It would look something like this (imagine icons chosen from the right-clicked style dialogue):
[I] [ά] [א] ...
Aside: if one would prefer to simplify the right-clicked style dialogue so as to remove the icon selection setting (and thus default icons), the following would also be viable: merely create an icon-like 'space' on the toolbar which would have within it the first 'a-equivalent' letter in the applied font/style. Usability bonus: Color could be automatically added for easier distinguishing/better user friendliness/efficiency (choose color blind appropriate colors if such a thing is possible). My toolbar would subsequently look approximately so:
[a] [α] [א] ...
{U+0061 italicized; U+03B1; etc...}
Not sure how easy this is to do -- may require another right-clicked style dialogue setting (to select the right display character) such as: "The script this font uses is:" followed by a drop-down menu (which would also include Asiatic scripts, etc.). Not sure what the best UI idea/implementation here is ...
Just saw your last post. If you are thinking of applying styles to Zotero notes, etc... too then option "[1] a style toolbar: Font; Rel. Size; Italics; [Bold]" etc. may be a better way to go ... No, let me change my mind here: I still think adding a bold 'icon' (etc.) to a "Format Painter" bar may be superior. This is because defining styles -- rather than randomly mish-mashing font attributes to achieve the same thing -- is elegantly future proof (for later exchanging fonts for another journal or a better future font). A 'defining styles' approach saves a lot of work with updating/changing a big bibliography database.
Consider that:
1. Word 2007 actually does its citation and bibliographic formatting in HTML (the XSLT actually generates HTML; not RTF)
2. the OpenDoucment style and formatting system is based on FO, itself based on CSS
3. CSL adopts the FO/CSS model for fonts and such
4. Firefox and the web
Its not that critical now and for this particular piece of functionality whether it's passing RTF to Word or whatever, but WRT to the big picture and long-term design issues, I agree with Dan that the focus ought to be web-oriented standards.
And WRT to the issues clip is concerned about, wouldn't using X(HT)ML have benefits like ...
<x:span xml:lang="iw_IL">[some hebrew text]</x:span>
...? In other words, tag the text with a language, rather than just worrying about the font information.
[edit: for support for this position, see http://www.w3.org/International/tutorials/bidi-xhtml/.]