Re: [Gzz] PEG: canvas_text--mudyc

[Tuomas Lukka]

On Fri, May 02, 2003 at 11:38:31PM +0300, Matti Katila wrote:
> 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. 

Why? Transclusion is not a directed relationship, is it?
Possibly the time the transclusion was made would be appropriate, but
otherwise I think it's undirected.

> One 
> possibility is to place this information in rdf graph.

As a property of what?

> And I don't understand why xuLink can't be used. 

Can't be used for what? Hmm, if the link types were introduced
I suppose it *could* be used, but generating the right xulinks
is not a trivial task at all.

Hmmm, here's a nice pro gradu for someone...

> You should also explain 
> what to do if xuLink links textSpan and pageSpan? 

Show them both? Just normally?

> Also you need to explain 
> how for example email is shown if one use textspans from there in 
> defferent place. 

As a buoy.

> How email text differ from any text? Do we make EmailSpan 
> because of it?

No. It's just text. 

The difference is that when looking at where the text is transcluded,
the system notices, from the context, "Oh, this is an *email*.. let's
use *this* view."

> >>> 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.

And that's the point. We *want* xanalogical media to work. Connectedness.
Losing it is akin to Ted's comparison of ripping the wings of a 747
and driving it as a bus.

> Otoh, we would get usefull information of usefulness of FenPDF because
> we would use it. Using FenPDF might be faster than using another reader. 

What? I don't understand what that has to do with anything, when
we're starting with our own stuff.

We'll get plenty of ideas about the usefulness of fenpdf when we read
others' articles on it.

Why are you set on reading our own stuff on it, without seeing 
the connections? I don't understand.

> 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.

Ok, that could be acceptable - if used e.g. for checking out whether
the layout of the article is right &c, and the generated stuff
would not be made into permanent blocks.

Another point is that you can't put your own links, because
the pageimagescroll id isn't permanent: whenever you change anything,
the generated .pdf file and thus the block bitprint changes!

> [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, 

See, again I'm understanding far better when you start using an actual
example - maybe you should consider doing that in the first place;
it really helps.

> () -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).

But I still don't *quite* understand.
First node1 = a whole note, then suddenly it's only a part -
what do you want to link, note1+note2+note3? 

So, one more step to direction of the clearer example, ok? ;)

> >> 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. 

No, a xulink can be *implemented* as two enfilades which the system
knows are linked by the xulink.

> Currently in pp we do that, kindly.

Do what?

> 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. 

You've lost me completely again. 

> >>> 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. 

Why not include this in the original proposal? 

> Writing is hard work for me :-(

Like coding, the best way to learn is by doing. You're making wonderful
progress.

> [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."

The problem is actually what I said above: if modifiable, the pageimagescroll
isn't permanent: it won't stay the same!

> > 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?-)

We can view the canvas it is generated from, along with all its links
and buoys. How would that not be superior? Not wysiwyg but possibly better!

        Tuomas