On Sep 24, 2010, at 2:11, JiHO wrote:
> On Fri, Sep 24, 2010 at 00:36, Christiaan Hofman <[email protected]> wrote:
>>> 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.
>
> I understand that they are not the same thing conceptually. But
> practically they look almost the same in the file: they are just ASCII
> characters.
Uhm, no, one is human readable text, the other is proprietary gibberish, from
the POV of most humans.
> Maybe I know too little about the parser to really
> understand, but, since a RTF file is actually just a collection of
> ASCII character, I imagined that this parser just does some
> find-and-replace operations on the template tags, probably based on a
> regular expression that looks something like:
> \<\$.*?\\\>
> So I imagined that it would be equally able to perform these
> operations on other regular expressions too.
>
> To reuse my example above, a minimalist RTF file with just the DOI as
> a link to the resolved DOI online would be:
>
> {\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf320
> {\fonttbl\f0\froman\fcharset0 Palatino-Roman;}
> {\colortbl;\red255\green255\blue255;}
> {\info
> {\author
> Foo}}\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
> \pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
> {\field{\*\fldinst{HYPERLINK "%3C$urls.Doi/%3E"}}{\fldrslt
> \f0\fs22 \cf0 <$fields.Doi/>}}}
>
> The first template tag is %3C$urls.Doi/%3E is the destination of the
> link, which should be expanded to http://dx.doi.org/value-of-doi, and
> the second is <$fields.Doi/>, which should be expanded to
> value-of-doi.
>
> So, in the end, what I am saying is: can the parser recognise both
> <$***/> and %3C$***/%3E as tag delimiters?
>
No, we don't even know whether occurrences of these pattern should come from
template tags. Apart from that, we never see them.
>>> 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.
>
> I am displaying the raw RTF data above for the sole purpose of showing
> that a tag in the text and a tag within the hyperlink are not so
> different. But I actually created everything in TextEdit. Just select
> a piece of text, select Edit > Add Link..., and, in the pane that
> opens, write the destination address, possibly including template
> tags.
>
> I acknowledge that it would be more difficult that letting .linkedText
> do the work but it would allow for finer configuration where needed
> (the custom google scholar search I did in HTML turns out to be quite
> useful).
>
> Anyhow, thanks for all your work on the rest. I'm just trying to
> better understand how things are working under the hood but maybe I
> just shouldn't ;)
>
> JiHO
> ---
> http://maururu.net
The raw RTF data is just a proprietary format used to save the data of the rich
text. It could also have been some other format (html, doc, docx, odt.) In
code, we don't see any of these details. What we have in code is a
string-with-attributes (NSAttributedString). We parse the string (looking for
template tags), trying to keep the attributes intact, and possibly adding
attributes (depending on the replacement.) So the template tags are in the
text, not in the attributes, and certainly not in some underlying raw data
representation that was used to save the template. This also makes it possible
to edit in the template tags, because the text is what the person editing the
template actually sees.
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
