On Sep 24, 2010, at 11:37, Christiaan Hofman wrote:
>
> On Sep 24, 2010, at 2:11, JiHO wrote:
>
>> On Fri, Sep 24, 2010 at 00:36, Christiaan Hofman <cmhof...@gmail.com> 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
>
In tomorrow's nightly we will also parse the link attributes in an extra parser
run.
Christiaan
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
