Re: [Gzz] PEG: canvas_text--mudyc

[Tuomas Lukka]

On Fri, May 02, 2003 at 07:19:10PM +0300, Matti Katila wrote:
> On Fri, 2 May 2003, Tuomas Lukka wrote:
> > On Fri, May 02, 2003 at 03:39:45AM +0300, Matti Katila wrote:
> >> There are at least three disagreeing circumtances:
> >> wysiwyg, text editability, spatial positions.
> > I think wysiwyg is the least important of the three..
> 
> I agree. Otoh, many people doesn't understand why does something look 
> different in computer screen than in paper found from printers.
> This is not important now.
> 
> >> Issues
> >> ------
> >> 
> >> - If we generate rst to pdf does it brake the 
> >>   xanalogical link doesn't it?
> >> 
> >>     RESOLVED:
> >>     Yes, if we *replace* the text canvas with
> >>     page canvas. Currently idea is to use pdfs from outside 
> >>     and annotate those. So the question is why can't we 
> >>     build a new article from annotations and link xanalogically
> >>     the annotation canvas to pdf generated from it?
> > 
> > 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?

Who will need to know what?

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

> >> What's it all about?
> >> --------------------
> >> 
> >> This proposal is all about:
> >> 
> >>     - spatial placing of different paragraphs into one canvas.
> >>     - one paragraph includes sentences one after the other.
> >>     - sentence includes nodes(as words) one after the other.
> > What, a node is a word?
> 
> A Node is a node.

An RDF node?

> As it currently is, isn't it? A node is a key for 
> enfilade. 

"Key"?

> In gzz's pp node is a note and that can be for any length and 
> contain any content from a letter or empty to whole book. 

Yes?

> 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 :( 

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

> > Please explain a lot more detail. This description doesn't.. 
> > What is the underlying structure, and what are the things the user sees?
> 
> Pp currently:
> () -node
> 
>     (Paper)  --PAPER.contains---> (A note)
> 
>     (A note) --SPATIAL.coordsX--> literal
>     (A note) --SPATIAL.coordsY--> literal
>  
> This proposal adds additional information to this:
> "RST" is only for the idea, also short name. 
> 
>     (Paper) --RST.beginParagraph--> (RST.Paragraph)
> 
>     (RST.Paragraph) --SPATIAL.coordsX--> literal
>     (RST.Paragraph) --SPATIAL.coordsY--> literal
> 
>     (RST.Paragraph) --RST.firstSentence--> (RST.Sentence)
> 
>     (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 ;)

> >> PDF generating from rst converted to latex. This would make FenPDF
> >> also as a article productive wholeness.
> > Yes, this would be good. It still doesn't explain why you
> > then want to import the *generated* article into FenPDF?
> 
> 1) Why should we see them with other readers?
>     - Is FenPDF worse than other readers?

No, in FenPDF we can use the *BETTER* thing, the *original* article content!
That's the point!

> 2) It brakes xanalogical model!

breaks

>     - Yes, but say a application where we currently use true xanalogical 
>       system.
>     - 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). 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?".

Brushing it aside "we can just make a link" doesn't suffice - I for
one don't see that you can really make it work well enough.


>     - You said that in fenfire should not be a system which doesn't use 
>       xanalogical manner. So, one issue is that would we need transitional 
>       period when we allow, i.e. one link travel to original content - 
>       to the xanalogical world.

Sorry, I don't understand that paragraph.

> 3) Why outworld pdfs are better than our generated pdfs?
>     - We still need to communicate to outside of xanalogical world.

What??? What's "better"? 

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.

        Tuomas