On Thu, Nov 21, 2013 at 8:42 AM, Frank Bennett <[email protected]> wrote: > 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
(Oops, sorry, typo: I should have written "when title case or sentence case are applied to the field".) > (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
