LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Sun, 8 Jan 2012 20:23:04 +0000
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Type: multipart/alternative; boundary="-905591047-894188226-1326054184=:54660"
From: Chris A Rowley <[log in to unmask]>
Parts/Attachments: text/plain (3884 bytes) , text/html (6 kB)
Frank

It is certainly true that when generated text depends (in more or less complex ways) 
on the formatting, then trials will need to be more extensive, and information from the trials
needs to be collected; but most, possibly all, of this can be specified in ’tags’ that are not 
embedded in the text segments. 

In this particular example, the fact that a certain number of 'varioref  tags’ occur is a property 
of the whole text segment and so this information does not need to be embedded.

The generation of the actual text from the ‘varioref tag’ is possibly different as generated text 
may need information about immediately surrounding text: for example auto-typesetting: 

  the next word, when typeset in the current font, <FONT>, uses <N> positioned glyphs: field-office

This suggests that ‘generated text’ should be of a different type and ‘text’ must contain 'text-segments’ 
of different types (at least) ‘explicit’ and ‘generated’.  Then in those cases when it is not possible to replace the 
‘generated segments’ by 'explicit segments' without typesetting the whole text, this process becomes another trial.

Then any side-effects of the ’text generation’ can be simply confined to be outputs from this trial and thus they 
will not ‘directly effect' any ‘global machine’ that is used by the ‘text generation’.  (Which is probably an 
obfuscated way of saying what others have suggested.)

Thus the generated text need not and should not be treated very differently when doing typesetting, except in 
the ‘text generation trials’ and even then the ‘generation machine’ and the ‘typesetter’ should communicate
only via the ‘trial mechanism’ of these trials.

It is thus true that general methods need to be developed to provide and deal with all types of such feedback 
from trials.including their effects on other machines, such as the 'varioref document database’.

I know that this has not really addressed Frank’s concerns; I regret that my problem is that I am not thinking of
a model in which either characters or tags actually 'do anything’ (or ‘are evaluated’) beyond signifying their 
'positions in a document'.

So ‘generated text’ is  Text but the generating mechanism is not so, to stick to the principle, 
the generator should not be typeset (which is roughly where we came in). 

chris


>________________________________
> From: Frank Mittelbach <[log in to unmask]>
>To: [log in to unmask] 
>Sent: Sunday, 8 January 2012, 15:03
>Subject: Re: trial typesetting support
> 
>Chris
>
>> Of course, the most general solution, for the future, would be to move to:
>> 
>> Full separation of ‘text input’ (data, pure character strings) from ‘tags’
>> (non-typesetting process directions, typesetting hints, etc), so that
>> Only the Text gets Typeset — Always ** The OTTA Principle.
>
>I don't see how this would help here. Can you explain?
>
>The issue is that you do have conditional "input text" that depends on tags around it so you can't necessarily just typeset the text and leave the tags alone. For a small isolated piece of text that might be true but any larger portion might rely on the evaluation of tags inside to typeset itself correctly.
>
>So how would this work?
>
>frank
>
>
>

ATOM RSS1 RSS2