On Sep 24, 2010, at 0:02, JiHO wrote: > On Thu, Sep 23, 2010 at 18:55, Christiaan Hofman <[email protected]> wrote: >>>>> Ok. An I guess DeTeXifying means removing those commands without >>>>> affecting the output while TeXifying is converting those commands into >>>>> their RTF equivalent. i.e.: >>>>> {\'e} -- DeTeX --> e >>>>> {\'e} -- TeX --> é >>>>> Is that right? >>>> >>>> That's correct. >> >> Sorry, that's NOT correct. >> >> DeTeX: {\'e} -> é >> TeX: é -> {\'e} > > OK, that makes more sense indeed. > >> They're not the same at all, they don't even overlap, certainly not in this >> particular example. The first gives "é", the second "\'e". In general, >> stringByRemovingTeX removes TeX commands and curly braces, while >> stringByDeTeXifyingString converts TeX accents and TeX specials to >> accented/special characters. > > Thanks to the new explanation. I understand now that they are > completely different indeed. It was the previous explanation that > confused me. > >> Values you get through the "fields" key in a template are already >> DeTeXified. We use stringByRemovingTeX for display values of strings like >> the title in the main table as well as in the default RTF template. > > So I don't need <$fields.Title.stringByDeTeXifyingString/> for > example, <$fields.Title/> is enough. Is that right?
That's correct. And you may also consider <$title/>, which handles the inbook type better, and <$displayTitle/>, which uses stringByRemovingTeX. > Now, even with fields. (or with .stringByDeTeXifyingString) there is > some TeX left (because, as you say, you would not want to build a > complete TeX parser). Now, if I do: > <$fields.Title.stringByRemovingTeX/> > Is the title is *first* filtered to convert known tex values into > unicode and *then* the remaining tex is removed, or is all tex removed > before having a chance to be converted? It's first converted, because that's implicit in fields.Title. Key paths are applied in order, so stringByRemovingTeX is applied to the result of fields.Title. > >> I know, but with RTF it is not possible to do exactly what you want, because >> there's no way to pass an extra argument (the URL or displayed string) to a >> template key. What I said is the closest you can get. > > OK. I'll just use .linkedText and be happy with it in RTF then. But > overall, I think I'll move to HTML. > > I know nothing of the implementation of course, but I imagined that > the RTF file was going through a parser of some sort which replaced > the <$???/> bits by the appropriate values of the fields. I was > thinking that maybe this parser could be made to also replace those > strings within a HYPERLINK construct (where they are delimited by %3C > and %3E). Again, no, the hyperlinks are in the underlying /data/, while the parser replaces template tags in the /text/. The hyperlinks are not text, they're attributes. > This way, all imaginable link would be possible, as they are > in HTML. One would only have to create the link manually in the RTF > editor (rather than have the templating system create it for him with > .linkedText). > But it wouldn't be manageable for most, because it would require editing template tags into the underlying RTF data, which most people (including me) would not be able to do. The point is that now you just include the tags in the rich text as text, and you don't bother with the underlying RTF data format. It's either one or the other, you can't mix things up. >> Also, for HTML you should <$urls.Doi/> for the linked URL, not >> http://dx.doi.org/<$fields.Doi/>, because we do some more validation and >> cleaning that you may otherwise not get. > > OK. I'll correct that. > >> If you use some value as part of a URL you should also always use >> stringByAddingPercentEscapes or >> stringByAddingPercentEscapesIncludingReserved (in this case the latter, >> because you want to escape everything including characters like /&=). And as >> noted above, you can only add links in RTF with the text equal to the full >> URL or path. > > I'll correct that also. > >> You cannot include images in a HTML preview. As I noted before, you cannot >> have external files (like css or images), as it is based on data, not on >> files. You can also not link to remote images, because a text view also does >> not download anything. > > Actually, remote images worked today, on the latest stable version of BibDesk. > I'm somewhat surprised NSAttributedStrings downloads those, that can even be potentially problematic because creating the attributed string is synchronous. On the other hand, I know it is still based on WebKit (which actually gave us serious problems on 10.5.) >> In tomorrow's nightly you can add images and external .css files as >> accessory files, and they will be used for the template based preview. Refer >> to them by the filename (relative path). > > That's very cool thanks! It helps to have the CSS separate, and the > possibility of adding pictures makes for more creative templates. > > Thanks a lot, > > JiHO > --- > http://maururu.net And the default html template (which has a separate css file) will also work fully. Christiaan ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
