Re: [Gzz] PEG: canvas_text--mudyc

[Matti Katila]

On Fri, 2 May 2003, Tuomas Lukka wrote:
>>> If I cut&paste a sentence from an email to an article, I'd like that
>>> xanalogical connection to remain to the actual *text*. (ISSUE: does it?)
>> In text canvas or in rst generated canvas(differs basicly by text 
>> formatting from text canvas) - yes, but in generated pdf pages - no.
>> It can be made - just putting xuLink from *text* to *pdf page* - but I 
>> don't know how we can get coordinates from latex for that.
> 
> No is not an acceptable answer. 
> 
> If you really want to do this, I *require* that you'll have the
> xanalogical links properly in place right away. Does the xuLink even
> suffice, since it should be treated as a transclusion?

Yes?
One of the things we were wondering with Janne at buoyoing-deadlline, why 
is a transclusion buoy only on left side? Actually I know this but we 
should be able to define the direction of the transclusion buoy. One 
possibility is to place this information in rdf graph.

And I don't understand why xuLink can't be used. You should also explain 
what to do if xuLink links textSpan and pageSpan? Also you need to explain 
how for example email is shown if one use textspans from there in 
defferent place. How email text differ from any text? Do we make EmailSpan 
because of it?

>>> I think the question is: why is it that you want people using fenfire
>>> to read the PDF file generated at all? (ISSUE: why?).
>> 
>> Umh!?  Why do people use fenfire at all for reading PDF files?
>> Because it should be one of the bests for it and provide xanalogical 
>> links. If it isn't enough good for our own purpose how could others use 
>> it?
>> 
>> And if we can almoust write one article with fenfire why shouldn't we 
>> able to see the result in fenfire? I see this very natural.
> 
> There are two environments here: the rich environment (Fenfire, having
> xu stuff), and the poor environment (pdf files).
> 
> Exporting from rich to poor works - generate a PDF file.
> Importing from poor to rich work - import a pageimagescroll.
> 
> BUT DOING BOTH THOSE OPERATIONS FOR THE SAME DATA IS DISASTROUS.
> 
> Exporting something and then importing it, losing the connectivity,
> kills what we're trying to achieve.

Yes, I fully understand the issue but I don't understand your strong 
reply against the idea. Xanalogically it would be suicide, I agree.
Otoh, we would get usefull information of usefulness of FenPDF because
we would use it. Using FenPDF might be faster than using another reader. 

I'm still talking about viewing generated media. Usually there is text to 
inform user for generation, i.e. "This is generated - do not edit!".
We can put that in the background texture. It's like printing the article 
but not using a paper for that.


[current pp]
>> Argh, unbelievable. If you want to associate two words from different 
>> papers it might not be possible if they belongs in bigger note.
> 
> What? I don't understand a single word of what you mean here...
> I don't understand at all more than after reading what you first wrote :( 

Ok, 
() -node
note1 = (This is a note)

I want to link 'note' to another paper, like:

note1 = (This is a)
note2 = ( )
note3 = (note) and link this.

I can't do it with current ppactions. So I wrote rstactions where it is 
easier to add just nodes but not strings (and added some hopefully useful 
information also).

>> Pp association is poor man's way to make xuLinks ;)
> No, PP assoc is a different type of link, not between fluid media but
> between nodes.

Hmm, partially true.

Before hand you were talking about xuLink is transclusion between 
enfilades linked to each other. Currently in pp we do that, kindly.
With association we show buoys as transclusion of canvas ;)
Instead of node linking to node we could xuLink textEnfilades to 
textEnfilades. I raise the question again which I wrote before:
how this should be handled. How we know that we have written the enfilade 
in canvas or in email or something else. 

>>> Please explain a lot more detail. This description doesn't.. 
>>> What is the underlying structure, and what are the things the user sees?

...

>> 
>>     (RST.Sentence)  --RST.nextSentence-->  (RST.Sentence)
>>     (RST.Sentence)  --RST.nextNode-->      (A note)
>>     
>>     (A note)        --RST.nextNode-->      (A note)
>> 
>> (A note)s' coordinates are generated because of they are additive to 
>> RST.Paragraph's coordinates. Also think notes as words or letters or 
>> numbers. At least not as a one ugly big note.
> 
> So, what you're suggesting is that we store the sentence and word structure
> of the text as RDF nodes??? 
> 
> Your original proposal didn't explain this at all ;)

Yes, it was the thing I was trying to say. That's all. 
Writing is hard work for me :-(


[importing generated pdf] 
>>     - We can provide link to canvas where it is constructed from.
>>     - We can provide xuLinks between PermaScrolls (this is not very easy 
>>       task unfortunately, I think(coordinates from latex)) 
> 
> We might be able to. But this sounds like handwaving: "yes, sure, we can
> do this" (implying that we probably won't).

=)

To me this option sounds like: "Finally I'm able to use one application to 
view and write. Finally I can use fenfire for that."

> If you want to do this 
> export-import stuff, you should make a CENTRAL part of your proposal and
> explanations the part "how do we make it work with the xu stuff in fenfire?".

Yes, it was my mistake to give an attention at all for it. 


> The point is that for outworld PDFs we have no other option than
> PageImageScrolls. However, for things *we* write, we *HAVE* other options -
> better ones.
> 
> *THAT* is the point.

Can you shine my imagination and tell those other and better options?
Pdf definitely is wysiwyg and you already told that it is least important 
for us and I agreed that. How the situation has changed from the 
morning?-)


   -Matti