On Thu, Nov 21, 2013 at 6:00 AM, Gregory Jordan <[email protected]> wrote: > Hi all, > > Sorry for the potential thread break — I'm a new member to the list so I > can't reply to this thread in a nice way... > > My apologies in advance if this idea has previously been proposed and > decided against. I've only kept up with the list for a short while now. > > I'm a developer for Paperpile, a new(ish) reference manager making use of > CSL and citeproc-js. > > Personally, I'd love to see CSL move toward widespread support for the > solution that Bibtex has used for years, which is to allow users to surround > words with braces to protect the capitalization as-is. This would go very > far towards giving a user the power to force de-capitalization (or > capitalization) of things that they know should be a certain way in their > bibliography, despite the CSL style and/or the processor's best attempts to > do the right thing. > > It seems clear that no matter how smart one is about trying to title-case, > there will always be edge cases where a single item is improperly > capitalized. Without any user-facing way to protect these edge cases, we're > stuck either (a) avoiding title case like the plague in CSL styles and just > using strings as-is from the input, or (b) embracing title case in the > styles and dealing with frustrated users who can't tweak things the way they > want. > > Some benefits to a bibtex-like syntax for protecting capitalization would > be: > - It's immediately familiar to anyone who's ever used bibtex. > - It's directly interoperable with existing bibtex data. > - It's simple enough for many users to learn and remember. (I don't think > an HTML syntax would ever have this benefit.) > - It easily generalizes to all variable outputs, not just titles. > > (For context, we recently had a user contact us about incorrect > capitalization of journal names in APA style: > https://github.com/citation-style-language/styles/issues/759 which brought > this issue to our attention.) > > I think any type of HTML-based syntax would be misdirected toward > capitalization, since the issues of formatting (e.g. italics, superscript) > and capitalization are not one and the same. Formatting is specific to only > non-plain-text outputs, while capitalization is relevant no matter how a > citation is ultimately being displayed. > > All that said, maybe there's some obvious problem with this approach, or > maybe it's something that should be left up to each processor to decided. > However, I have a feeling it would be best in the long term to have > something clearly spelled out in a processor-agnostic document to both > improve clarity and aid widespread adoption. > > If there's interest, we'd be happy to help implement this in citeproc-js. > > greg
Some processor-specific syntax for this currently coded into citeproc-js: <span class="nocase">qwerty</span> The "nocase" form has the effect of squiggly braces in BibTeX (as I understand it): it prevents changes to the case of the enclosed text when title case or text case are applied to the field. The idea was (and I guess I would say is) to use a markup syntax that can be easily represented in a UI without additional levels of external parsing by the client. As far as I know the syntax isn't supported in the UI of any clients out there, though, and it hasn't seen much use for the obvious-enough reason that it's quite an awkward thing to type, and distracting when displayed verbatim. It should be a simple thing to add a spec line to the parser that applies the same methods to squiggly-brace-enclosed text. Backslash escaping should just work, without additional coding. in citeproc-js, mixing "plain text" and "html" approaches isn't particularly a problem, but smooth operation with other tools might require greater consistency. It would be good to have input from other processor developers and consumers of CSL; and in the interest of data exchange, it would be good to have a description of preferred markup set in an adjunct to the CSL specification before making further changes. > > On Fri, Nov 15, 2013 at 4:13pm, Aurimas Vinckevicius wrote: > >>Clearly, string formatting (mostly in titles) is necessary and is getting >>implemented whether CSL specifies it or not. IMO HTML (or XML, which would >>probably be more work for everyone) is the most elegant and broadly >> supported >>approach. > >>If CSL really wants to remain format-agnostic in this regard, then it could >> just >>specify that substrings can be marked (with possible nesting) for various >>formatting (italics, superscript, forced title-casing, etc.) and leave the >> language >>of the formatting up to the citeproc developers. CSL can then go on to >> specify >>how such substrings are handled when producing citations. > > On Thu, Nov 14, 2013 at 9:52 PM, Bruce D'Arcus <[hidden email]> wrote: >> >> I haven't looked at this issue, but putting html in json files feels >> really wrong as a general proposition. >> >> On Thu, Nov 14, 2013 at 10:02 PM, Rintze Zelle <[hidden email]> wrote: >> > So far the CSL spec is rather format-agnostic when it comes to input. >> > It's >> > one of the reasons why citeproc-js's support for inline rich text >> > formatting >> > of titles (http://www.zotero.org/support/kb/rich_text_bibliography) >> > isn't >> > included in the spec. >> > >> > I see the use of what you're proposing, but it is rather HTML-oriented. >> > Are >> > we comfortable including something like this in the spec, or would it be >> > better to have a separate (sub)document that focuses on CSL input (which >> > could also be used to describe the CSL JSON data model)? >> > >> > Rintze > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
