texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Longueurs et transformations


From: David Allouche
Subject: [Texmacs-dev] Longueurs et transformations
Date: Thu, 4 Apr 2002 18:01:23 +0200

On Thursday 04 April 2002 17:36, Joris van der Hoeven wrote:
> On Thu, 4 Apr 2002, David Allouche wrote:
> > > Par mise en page, j'entends tout le processus de mis en page, y compris
> > > le "shoving" et le "filling". Dans le futur, toute la mise en page sera
> > > paresseux ; il n'y aura donc plus de veritable distinction entre
> > > la production d'une boite ou de plusieurs boites a etre assemblees
> > > par la suite.
> >
> > Je ne comprends pas bien comment il peut etre possible de faire un
> > typesetting monolithique et lazy dans la mesure ou de nombreux
> > algorithmes (esp. le filling, la cesure, et la pagination) sont globaux.
[snip]
>
> L'idee est d'utiliser des evaluations paresseuses en plusieurs etapes.
> A la premiere etappe on met en page les boites les plus locales et
> lors des etappes suivantes on les dispose successivement dans
> les lignes, pages, tableaux, etc.

Ok, c'est bien ce dont, je parlais: plusieurs etages d'evaluation.

> > > >  -- y a-t-il des cas d'usages ou l'information desiree est plus
> > > > complexe que un 'space' (espace elastique)?
> > >
> > > Probablement non (enfin, on souhaite obtenir une longueur plutot
> > > qu'uneespace), mais je ne suis pas 100% sur. De toute facon, si on
> > > travaille avec des arbres (ou eventuellement des boites), ce n'est pas
> > > vraiment un probleme.
> >
> > Le probleme est de donner acces a l'information de longueur depuis le
> > langage de transformation. C'est pour cela que je ne suis pas tres chaud
> > pour renvoyer directement une boite.
[snip]
>
> Comme je le disais avant, il faudrait une neuvieme methode "force"
> pour forcer la mise en page d'une sous-boite que l'on sait reecrire.
> Il se peut que cette mise en page est incomplete (quand le resultat
> doit encore etre coupee en lignes), mais en general on veut juste
> les longeurs de la structure en tant que boite et alors c'est bon.
>
> Si plusieurs etappes de reecriture se suivent, la methode force appelle
> des methodes force des etappes d'apres.

Je reflechirai a cette methode 'force', il ne me semble pas evident que 
cette fonctionnalite n'ait pas de consequence indesirable.

Je comprends que le fait de retourner une boite permet d'ameliorer la 
souplesse du code si la transformation est implementee en C++. Mais si le 
protocole est materialise par un API vers l'exterieur, il me semble qu'il 
faudra appauvrir l'information (en 'space'). Je ne pense pas que la 
manipulation par script des 'box' soit prevue...

Je n'ai pas d'experience significative dans la definition d'API, et ce genre 
de dissymetrie me met mal a l'aise. C'est une des raisons pour lesquelles je 
publierai mon analyse.
-- 

                                  -- David --



reply via email to

[Prev in Thread] Current Thread [Next in Thread]