> 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.
Papers allows BibTeX-like escaping for nocase support, which is also supported in our CSL engine. Ths strings are however not stored quite with the same markup, but with a custom markup similar to XML (e.g. using <b>, <i>, <sup>, <nc> etc…). Charles On Nov 21, 2013, at 12: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 > (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 -- Charles Parnot [email protected] http://app.net/cparnot twitter: @cparnot ------------------------------------------------------------------------------ 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
