On 8 Oct 2007, at 2:36 PM, jiho wrote: > > On 2007-October-08 , at 13:20 , Christiaan Hofman wrote: >> On 8 Oct 2007, at 12:57 PM, jiho wrote: >>> On 2007-October-08 , at 11:38 , Christiaan Hofman wrote: >>>> On 8 Oct 2007, at 9:16 AM, jiho wrote: >>>>> On 2007-October-08 , at 08:38 , Simon Spiegel wrote: >>>>>>> Just out of curiosity, what would help the non-LaTeX users the >>>>>>> most? >>>>>>> People have mentioned integration with word processors. What >>>>>>> would it >>>>>>> look like? Basic RTF scanning wouldn't be too hard. A UI for >>>>>>> templates would be nice, too. >>>>>> >>>>>> An UI would certainly be a good idea. I don't think that many >>>>>> users >>>>>> would use BibDesk with its current template system even if it had >>>>>> RTF >>>>>> scanning. [...] >>>>> I also think a GUI to build bibliography styles would be very >>>>> welcome. I suggested this in back in 2005: >>>>> http://sourceforge.net/mailarchive/message.php? >>>>> msg_id=9787bb9212cc90ffa59662781198cb8a%40gmail.com >>>>> [NB: sorry the links to the images are broken, I lost them] >>>>> and it was considered too big to be in the scope of BibDesk at >>>>> that >>>>> time. The context seems to be the same today: people want tighter >>>>> integration between bibdesk and their word processors and, to do >>>>> that, a way to scan the document for citations as well as to >>>>> format >>>>> the references list is needed. >>>>> If such a UI is build, I would love it to output rtf templates as >>>>> well as something more LaTeX related (since apparently most >>>>> current >>>>> users of BD use LaTeX). At the time of my first post, I thought >>>>> about >>>>> writing .bst files, with BibTeX code, but the fact that it is a >>>>> new >>>>> language, and a not very user-friendly one, adds some complexity. >>>>> Now, if this UI could output files suitable for biblatex, which is >>>>> much easier to use than bibtex, it would be great. >>>> I personally have trouble imagining a workable UI to build >>>> templates. >>>> The template syntax is quite complex, and the only UIs I can >>>> think of >>>> would either be able to handle only simple templates, or they would >>>> be more bothersome to work with than the raw template itself. I >>>> don't >>>> know how the other managers (like Bookends and Sente) work with >>>> their >>>> "template" UI, but I guess they only use a much simplified syntax >>>> (in >>>> our terms, the equivalent of only value tags). >>> >>> I don't know the RTF template mechanism well but I was thinking at a >>> UI like this (very quick draft): >>> http://jo.irisson.free.fr/dropbox/bd_styles_ui.png >>> - On the left, a list of publication types, taken from BibDesk >>> - On the right: >>> . a list of fields, which changes according to the pub type, with >>> mandatory bibtex fields in red. The list of fields is also taken >>> from >>> bibdesk (custom fields appear here) >>> . an "Inline citations" and a "References list" fields in which >>> tokens can be drag and dropped to select what will be printed in >>> each >>> case. Plus, one can also write in these sections (but I cannot find >>> how to do this in interface builder). Therefore one can write: >>> [Author], [Year]. [Title], In: [Journal] etc. >>> . an option view, with options depending on each token (here some >>> possible options are shown for the [Author] token, which is probably >>> the most complex to print). >>> . a preview of what the output will look like >>> I think such a UI would be quite straightforward to use and could be >>> interfaced to many template mechanisms (BD own templates, biblatex, >>> bibtex etc.) >>> The cumbersome part with such a UI would be to do the templating for >>> all publication types. There are two solutions I can think of: >>> - never start from scratch: BD provides two of three templates to >>> start from, e.g. an author-year one, a numbered one etc. maybe from >>> the three or four classic bibtex styles >>> - define one reference type as a master (as shown here). The >>> modifications done on this master propagates the all other pub types >>> and then one only modifies them. >>> >>>> [...] > >> Yes, something like this is basically the only workable UI I can >> think of myself. But it only scratches the tip of the iceberg of the >> capability of our templating mechanism. It only allows for value >> tags, no collection and condition tags. Also it does not allow >> modifiers (like cleaning, capitalization, adding commas after non- >> empty fields, etc). Most, if not all, example templates on the Wiki >> contain both features. And moreover the token fields do not allow for >> rich text, so you can't for example put the volume number in bold >> (which is standard in my field). So it would be a huge simplification >> of our templates. > > I think this quick try was probably also only scratching what is > possible with such a UI. Formating is indeed missing from the image I > sent, it was in my previous try 2 year ago if I remember well. There > are two ways of doing it: > 1- have two option tabs: one general with things such abbreviate, > bold, italics, capitalize etc., and one with field specific options > (ie. kind of the one I showed) > 2- keep only one tab and to the editing directly in the field where > tokens are dropped: select a token and hit a button or command+B to > make it bold etc. This would call for a new token class, or a > subclass of Apple's tokens. basically one only needs special words to > be recognized as tokens, in an otherwise RTF field, so that they can > be dragged easily and people do not make typing errors (e.g. authors > or autor instead of [author]). > As for collections and conditions, I am not sure what you are > referring to since I am not familiar with the templating mechanism. > Some obvious things such as not putting parentheses around the volume > number when volume does not exist should be dealt with by the > machinery creating the output (BibDesk, BibTeX etc.) rather than at > the template design level IMHO. > Anyway, I am aware that designing such an application would be very > challenging and would require much time but I really think it would > be worth it. Too bad summer has passed, it would have been a nice > Summer Of Code project to start such a UI ;) > >> Also, citations and reference lists are just different templates. And >> sorting is not done by the template but by bibdesk, or some script >> generating this. So those parts should not be part of the UI. > > OK I see. Once again, I am familiar with BibTeX rather than with > BibDesk templates (though I heavily use BibDesk for everything else) > so this is why I included the options there. > > JiHO > --- > http://jo.irisson.free.fr/ >
I've created a little template composer app along these lines. It can be downloaded from the Wiki. Please try it out and say what you think. We might at some point include it in BibDesk. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
