Re: comment obtenir le symbole arc (de cercle ) RESOLU
Après essais : il suffit de se mettre en mode TEX (Contrôle L), puis
de taper
le code $\overset{\frown}{AB}$.
À mon avis, cette commande ne donne pas un résultat très esthétique.
Une autre possibilité consiste à utiliser le package yhmath.
S'il n'est pas installé, on le trouve ici:
http://tug.ctan.org/tex-archive/fonts/yhmath/
comme l'archive ne contient pas le fichier yhcmex.pfb (nécéssaire pour
pdflatex), il faut, soit le construire
soi-même à partir du fichier yhcmex.pfa, soit le télécharger ici:
http://forum.mathematex.net/latex-f6/problemes-divers-et-corrections-t8038.html?sid=4a3dff4bc0bb0117a93a0b4d828d8c28
Avec yhmath, on obtient un joli arc au dessus de AB avec la commande
\wideparen{AB}, et on peut aussi écrire \wideparen{ABC}... et bien d'autres
choses, comme par exemple \widering{A\cup B}...
PhC
Re: comment obtenir le symbole arc (de cercle ) RESOLU
>Après essais : il suffit de se mettre en mode TEX (Contrôle L), puis
de taper
>le code $\overset{\frown}{AB}$.
À mon avis, cette commande ne donne pas un résultat très esthétique.
Une autre possibilité consiste à utiliser le package yhmath.
S'il n'est pas installé, on le trouve ici:
http://tug.ctan.org/tex-archive/fonts/yhmath/
comme l'archive ne contient pas le fichier yhcmex.pfb (nécéssaire pour
pdflatex), il faut, soit le construire
soi-même à partir du fichier yhcmex.pfa, soit le télécharger ici:
http://forum.mathematex.net/latex-f6/problemes-divers-et-corrections-t8038.html?sid=4a3dff4bc0bb0117a93a0b4d828d8c28
Avec yhmath, on obtient un joli arc au dessus de AB avec la commande
\wideparen{AB}, et on peut aussi écrire \wideparen{ABC}... et bien d'autres
choses, comme par exemple \widering{A\cup B}...
PhC
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit :
Normalement, les labelstring en utf8 devraient marcher. Sinon, c'est
un bug.
Cela ne plante pas actuellement.
Philippe Il semble, mais il faudrait faire plus de tests, que ce qui
Philippe plante ce sont les noms de style qui ne sont pas en ASCII.
Oui, ca c'est normal, et il va falloir discuter de ce que l'on fait
pour resoudre ca. C'est pour cela que l'avis de quelqu'un qui a des
fichier layout de ce genre est utile.
Je vais faire des essais en ayant tous les styles en ASCII.
J'ai une autre question: peux-t-on avoir la ligne suivante:
\DeclareLaTeXClass[amsart]{article (AMS, Français)}
avec bien sûr un ç , le tout en UTF-8?
Le probleme si je comprends bien est que l'on ne peut passer a gettext
(qui traduit nos menus) que du ascii (a verifier). Il y a donc une
solution a inventer pour quand on veut faire des menus en francais
directement dans les fichiers. Pour que cela arrive, la encore il faut
se manifester.
JMarc
Je veux bien comprendre qu'il y ait des difficultés pour obtenir des menus
suplémentaires en Français. Ce besoin provient de la structure de
l'interface de lyx. Une structure ressemblant à celle de Kile me
semblerait bien meilleure (c'est aussi l'avis de beaucoup de gens
qui, pour cette raison n'utilisent pas lyx): un paneau latéral où
l'on trouverai (entre autres) la palette mathématique et les
layouts de la classe utilisée rangés de façon intelligente (la combobox
des layouts de lyx est difficilement utilisable dans lyx-1.5 avec les
classes
standard et inutilisable avec des classes possédant un nombre
important de layouts) renderait l'utilisation de lyx beaucoup
plus conviviale.
PhC
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : Charpentier Je veux bien comprendre qu'il y ait des difficultés pour Charpentier obtenir des menus suplémentaires en Français. Ce besoin Charpentier provient de la structure de l'interface de lyx. Une Charpentier structure ressemblant à celle de Kile me semblerait bien Charpentier meilleure (c'est aussi l'avis de beaucoup de gens qui, Charpentier pour cette raison n'utilisent pas lyx): un paneau latéral Charpentier où l'on trouverai (entre autres) la palette mathématique Charpentier et les layouts de la classe utilisée rangés de façon Charpentier intelligente (la combobox des layouts de lyx est Charpentier difficilement utilisable dans lyx-1.5 avec les classes Charpentier standard et inutilisable avec des classes possédant un Charpentier nombre important de layouts) renderait l'utilisation de Charpentier lyx beaucoup plus conviviale. Je ne suis pas sur du rapport entre ca et les menus en francais... JMarc Je ne sais pas... Mais je pense qu'une telle structure rendrait nécessaire la lecture des layouts correcte (et donc un encodage sûr) alors que l'on peut toujours discuter sur l'intérêt de menus supplémentaires. Enfin, les menus restant alors ceux de base il n'y aurait plus de problèmes récurrents avec les fichiers ui. PhC
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit :
Normalement, les labelstring en utf8 devraient marcher. Sinon, c'est
un bug.
Cela ne plante pas actuellement.
Philippe> Il semble, mais il faudrait faire plus de tests, que ce qui
Philippe> plante ce sont les noms de style qui ne sont pas en ASCII.
Oui, ca c'est normal, et il va falloir discuter de ce que l'on fait
pour resoudre ca. C'est pour cela que l'avis de quelqu'un qui a des
fichier layout de ce genre est utile.
Je vais faire des essais en ayant tous les styles en ASCII.
J'ai une autre question: peux-t-on avoir la ligne suivante:
\DeclareLaTeXClass[amsart]{article (AMS, Français)}
avec bien sûr un ç , le tout en UTF-8?
Le probleme si je comprends bien est que l'on ne peut passer a gettext
(qui traduit nos menus) que du ascii (a verifier). Il y a donc une
solution a inventer pour quand on veut faire des menus en francais
directement dans les fichiers. Pour que cela arrive, la encore il faut
se manifester.
JMarc
Je veux bien comprendre qu'il y ait des difficultés pour obtenir des menus
suplémentaires en Français. Ce besoin provient de la structure de
l'interface de lyx. Une structure ressemblant à celle de Kile me
semblerait bien meilleure (c'est aussi l'avis de beaucoup de gens
qui, pour cette raison n'utilisent pas lyx): un paneau latéral où
l'on trouverai (entre autres) la palette mathématique et les
layouts de la classe utilisée rangés de façon intelligente (la combobox
des layouts de lyx est difficilement utilisable dans lyx-1.5 avec les
classes
standard et inutilisable avec des classes possédant un nombre
important de layouts) renderait l'utilisation de lyx beaucoup
plus conviviale.
PhC
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : Charpentier> Je veux bien comprendre qu'il y ait des difficultés pour Charpentier> obtenir des menus suplémentaires en Français. Ce besoin Charpentier> provient de la structure de l'interface de lyx. Une Charpentier> structure ressemblant à celle de Kile me semblerait bien Charpentier> meilleure (c'est aussi l'avis de beaucoup de gens qui, Charpentier> pour cette raison n'utilisent pas lyx): un paneau latéral Charpentier> où l'on trouverai (entre autres) la palette mathématique Charpentier> et les layouts de la classe utilisée rangés de façon Charpentier> intelligente (la combobox des layouts de lyx est Charpentier> difficilement utilisable dans lyx-1.5 avec les classes Charpentier> standard et inutilisable avec des classes possédant un Charpentier> nombre important de layouts) renderait l'utilisation de Charpentier> lyx beaucoup plus conviviale. Je ne suis pas sur du rapport entre ca et les menus en francais... JMarc Je ne sais pas... Mais je pense qu'une telle structure rendrait nécessaire la lecture des layouts correcte (et donc un encodage sûr) alors que l'on peut toujours discuter sur l'intérêt de menus supplémentaires. Enfin, les menus restant alors ceux de base il n'y aurait plus de problèmes récurrents avec les fichiers ui. PhC
Re: lyx-1.4.0cvs fedora core 3
On Wed, 12 Jan 2005 15:13:54 +0100 Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote: Philippe == Charpentier Philippe [EMAIL PROTECTED] writes: Philippe Bonjour, depuis que je suis passé à la Fedora Core 3 je ne Philippe peux plus compiler lyx-1.4.0cvs récupéré sur Philippe ftp.sylvan.com/pub/lyx/devel/. Que j'utilise le configure du Philippe package ou que je le reconstruise avec autogen.sh, le Philippe résultat est le même: make s'arrete immédiatement avec Philippe l'erreur suivante: Je n'ai en effet rien vu de semblable. Est-ce que la situation est la meme en recuperant LyX directement par cvs? Il se peut que la distribution de Kayvan ne soit pas correcte... En effet. J'ai récupéré lyx sur cvs et la compilation marche sans problèmes. Malheureusement l'éxécutable construit plante très facilement... PhC
Re: lyx-1.4.0cvs fedora core 3
On Wed, 12 Jan 2005 15:13:54 +0100 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > >>>>> "Philippe" == Charpentier Philippe <[EMAIL PROTECTED]> writes: > > Philippe> Bonjour, depuis que je suis passé à la Fedora Core 3 je ne > Philippe> peux plus compiler lyx-1.4.0cvs récupéré sur > Philippe> ftp.sylvan.com/pub/lyx/devel/. Que j'utilise le configure du > Philippe> package ou que je le reconstruise avec autogen.sh, le > Philippe> résultat est le même: make s'arrete immédiatement avec > Philippe> l'erreur suivante: > > Je n'ai en effet rien vu de semblable. Est-ce que la situation est la > meme en recuperant LyX directement par cvs? Il se peut que la > distribution de Kayvan ne soit pas correcte... En effet. J'ai récupéré lyx sur cvs et la compilation marche sans problèmes. Malheureusement l'éxécutable construit plante très facilement... PhC
Re: Preamble
Donc:
- dans le Preamble/EndPreamble de layouts/foo.layout:
ce qui est inhérent à la classe (pour reprendre une discussion récente
sur lyx-users, \usepackage{slidesec} dans le layout seminar pour
que la définition de \slideheading ait un sens)
- dans le Preamble de template/foo.lyx:
les particularités modifiables
Est-ce une solution ?
--
Jean-Pierre
Oui et non. C'est une solution dans le sens où cela marche, mais c'est, je
trouve,
une mauvaise solution car, dans le modèle TOUS les environnements
théorème que que l'on peut être amené à utiliser doivent être
prédéfinis avec des paramètres par défaut, même si on ne se sert que de
quelque uns.
Il faut alors effacer ceux dont on ne se sert pas une fois le document
écrit...
Avec la solution que je proposais, seuls les environnements utilisés
apparaissent dans le préambule, avec des paramètres par défaut que l'on peut
changer
facilement à la première utilisation.
Pourrais-tu donner un exemple de preambule « complet »
et de préambule « simplifié » (si ce n'est pas trop long) ?
Je vois mal ce que tu entends par « effacer une fois le document écrit ».
--
Jean-Pierre
Plutôt que de donner un exemple je m'explique un peu plus:
Comme un environnement theorem ne peut être modifié une
fois qu'il a été défini, dans mes layouts, aucun environnement theorem
n'est a priori défini. A la place, dans le preambule standard (Preamble...
EndPreamble) je défini une commande ayant trois arguments (pour theorem.sty)
\def\theoreme#1#2#3{... }
qui, lorsquelle est tapée défini un environnement theorem de style #1
dont la police du corps est #2 et dont le label est #3. Lorsque l'on
utilise le layout, il faut donc taper cette commande dans le preambule
(user preamble) en définissant #1 #2 #3.
Naturellement ceci doit être fait pour tous les différents environnements
theorem que possède la classe (théorème, proposition, corollaire etc...)
qui sont utilisés dans le document.
Mon idée était d'avoir un défaut automatique pour la commande
\theoreme{...}{...}{...}
qui s'écrit dans la partie éditable du préambule (UserPreamble...).
De cette façon, on peut, non seulement changer le style de certains
environnements quand on veut (ainsi que la police du corps), mais on
peut utiliser le même layout pour écrire un document dans la langue
de son choix (puisque le label est modifiable). De plus on peut
rajouter un défaut (une commande) pour la police du label.
Ainsi, si on utilise un document modèle, toutes les commandes par défaut
\theoreme{...}{...}{...}, \proposition{...}{...}{...} etc...
correspondant à tous les environnements existant dans le layout
doivent être tapées dans le modèle (il y en a 29 dans article (AMS)),
alors que, généralement, seul un petit nombre est utilisé dans
un même document. Pour avoir un document propre à la fin,
il faut effacer les commandes inutiles.
Au passage, ceci règle le problème de la langue: avec les
layouts standards de LyX, on ne peut écrire qu'en anglais,
alors que ce que je propose permet d'écrire dans n'importe
quelle langue (que ce soit avec theorem.sty ou non): l'utilisateur
change le label par défaut.
Naturellement, ceci comporte aussi un défaut: si l'utilisateur
détruit la commande \theoreme{...}{...}{...}, à la compilation il
y aura une erreur. L'idéal serait que l'utilisateur ne puisse modifier
que ce qu'il y a entre { et }; mais c'est probablement difficile à faire.
Tout cela vient du fait que l'on ne peut pas redéfinir un theorem
déjà défini, et que, la seule possibilité qu'offre LyX est de changer
de classe de document si on veut changer soit la langue, soit un style
soit les compteurs. A mon sens ceci est trop contraignant, d'autant
plus que les classes n'existent pas, par défaut, dans toutes les
langues.
PhC
Re: Preamble
>>> Donc:
>>> - dans le Preamble/EndPreamble de layouts/foo.layout:
>>> ce qui est inhérent à la classe (pour reprendre une discussion récente
>>> sur lyx-users, \usepackage{slidesec} dans le layout seminar pour
>>> que la définition de \slideheading ait un sens)
>>> - dans le Preamble de template/foo.lyx:
>>> les particularités modifiables
>>>
>>> Est-ce une solution ?
>>>
>>> --
>>> Jean-Pierre
>>>
>>Oui et non. C'est une solution dans le sens où cela marche, mais c'est, je
>>trouve,
>>une mauvaise solution car, dans le modèle TOUS les environnements
>>théorème que que l'on peut être amené à utiliser doivent être
>>prédéfinis avec des paramètres par défaut, même si on ne se sert que de
quelque uns.
>>Il faut alors effacer ceux dont on ne se sert pas une fois le document
>>écrit...
>>Avec la solution que je proposais, seuls les environnements utilisés
>>apparaissent dans le préambule, avec des paramètres par défaut que l'on peut
changer
>>facilement à la première utilisation.
>Pourrais-tu donner un exemple de preambule « complet »
>et de préambule « simplifié » (si ce n'est pas trop long) ?
>Je vois mal ce que tu entends par « effacer une fois le document écrit ».
>
>--
>Jean-Pierre
Plutôt que de donner un exemple je m'explique un peu plus:
Comme un environnement theorem ne peut être modifié une
fois qu'il a été défini, dans mes layouts, aucun environnement theorem
n'est a priori défini. A la place, dans le preambule standard (Preamble...
EndPreamble) je défini une commande ayant trois arguments (pour theorem.sty)
\def\theoreme#1#2#3{... }
qui, lorsquelle est tapée défini un environnement theorem de style #1
dont la police du corps est #2 et dont le label est #3. Lorsque l'on
utilise le layout, il faut donc taper cette commande dans le preambule
(user preamble) en définissant #1 #2 #3.
Naturellement ceci doit être fait pour tous les différents environnements
theorem que possède la classe (théorème, proposition, corollaire etc...)
qui sont utilisés dans le document.
Mon idée était d'avoir un défaut automatique pour la commande
\theoreme{...}{...}{...}
qui s'écrit dans la partie éditable du préambule (UserPreamble...).
De cette façon, on peut, non seulement changer le style de certains
environnements quand on veut (ainsi que la police du corps), mais on
peut utiliser le même layout pour écrire un document dans la langue
de son choix (puisque le label est modifiable). De plus on peut
rajouter un défaut (une commande) pour la police du label.
Ainsi, si on utilise un document modèle, toutes les commandes par défaut
\theoreme{...}{...}{...}, \proposition{...}{...}{...} etc...
correspondant à tous les environnements existant dans le layout
doivent être tapées dans le modèle (il y en a 29 dans article (AMS)),
alors que, généralement, seul un petit nombre est utilisé dans
un même document. Pour avoir un document propre à la fin,
il faut effacer les commandes inutiles.
Au passage, ceci règle le problème de la langue: avec les
layouts standards de LyX, on ne peut écrire qu'en anglais,
alors que ce que je propose permet d'écrire dans n'importe
quelle langue (que ce soit avec theorem.sty ou non): l'utilisateur
change le label par défaut.
Naturellement, ceci comporte aussi un défaut: si l'utilisateur
détruit la commande \theoreme{...}{...}{...}, à la compilation il
y aura une erreur. L'idéal serait que l'utilisateur ne puisse modifier
que ce qu'il y a entre { et }; mais c'est probablement difficile à faire.
Tout cela vient du fait que l'on ne peut pas redéfinir un theorem
déjà défini, et que, la seule possibilité qu'offre LyX est de changer
de classe de document si on veut changer soit la langue, soit un style
soit les compteurs. A mon sens ceci est trop contraignant, d'autant
plus que les classes n'existent pas, par défaut, dans toutes les
langues.
PhC
Preamble
Bonjour, ce message s'adresse à ceux qui participent au développement de LyX, mais je l'envoie à cette liste restreinte pour ne pas encombrer lyx-devel par une demande qui peut paraître farfelue... Si cette demande semble raisonnable, je peux la réitérer sur lyx-devel. Dans cetrains layouts de mes classes j'aimerai disposer de deux tags suplémentaires: UserPreamble EndUserPreamble Ces tags serairent tout à fait similaires aux tag Preamble ... EndPreamble à la différence près suivante: lorsque l'on utilise pour la première fois un layout ayant ces nouveaux tags, ce qui se trouve entre est écrit dans la partie éditable (par LyX) du préambule LaTeX (i.e. % User specified LaTeX commands.) et cette partie du préambule est automatiquement éditée, de sorte que l'utilisateur peut la modifier s'il le désire. L'intérêt que j'y vois est le suivant: dans certains layouts, j'utilise theorem.sty pour les environnements theorem de manière à avoir la possibilité de définir de tels environnements avec différents styles. Bien entendu, je veux avoir la possibilité de redéfinir un style à tout moment. Ainsi l'environnement ne peut être défini dans le layout entre Preamble et EndPreamble (sinon on ne peut plus rien changer cette partie du préambule n'étant pas éditable, et c'est normal). Qu'en pensez-vous? PhC
Preamble
Bonjour, ce message s'adresse à ceux qui participent au développement de LyX, mais je l'envoie à cette liste restreinte pour ne pas encombrer lyx-devel par une demande qui peut paraître farfelue... Si cette demande semble raisonnable, je peux la réitérer sur lyx-devel. Dans cetrains layouts de mes classes j'aimerai disposer de deux tags suplémentaires: UserPreamble EndUserPreamble Ces tags serairent tout à fait similaires aux tag Preamble ... EndPreamble à la différence près suivante: lorsque l'on utilise pour la première fois un layout ayant ces nouveaux tags, ce qui se trouve entre est écrit dans la partie éditable (par LyX) du préambule LaTeX (i.e. % User specified LaTeX commands.) et cette partie du préambule est automatiquement éditée, de sorte que l'utilisateur peut la modifier s'il le désire. L'intérêt que j'y vois est le suivant: dans certains layouts, j'utilise theorem.sty pour les environnements theorem de manière à avoir la possibilité de définir de tels environnements avec différents styles. Bien entendu, je veux avoir la possibilité de redéfinir un style à tout moment. Ainsi l'environnement ne peut être défini dans le layout entre Preamble et EndPreamble (sinon on ne peut plus rien changer cette partie du préambule n'étant pas éditable, et c'est normal). Qu'en pensez-vous? PhC
Re: Guillemets
On Wed, 25 Jun 2003 16:41:16 +0200 (MEST)
Jean-Pierre.Chretien [EMAIL PROTECTED] wrote:
Je trouve personnellement que l'abondance des choix nuit considérablement
à la clarté, nous avons donc à mon avis deux options pour l'appel du .ldf
1/ on ne laisse que frenchb (que l'on pourrait appeler Francophone),
pour traiter toutes les installations particulières acadienne, canadienne
et française, et toutes nouvelle langue paramétrée par frenchb.ldf;
ceux qui veulent forcer frenchle peuvent adapter leur install (La)TeX,
soit temporairement par (par exemple sous Unix);
echo '\input{french.ldf}' frenchb.ldf
soit de façon permanente.
2/ on laisse les deux, le nommage pouvant être alors Francophone
et French
Cette dernière solution présente l'inconvénient de ne pas être compatible
avec le nommage antérieur. Quid de French et French(le) pour
enlever le GUTenberg qui apparemment n'a plus de raison d'être ?
Du point de vue strictement LyX, la première solution me paraît nettement
préférable (LyX ne gêre pas l'installation locale de LaTeX,
à partir de ce moment on ne laisse que celle qui est répandue
sur toutes les distributions).
A noter que le problème de varioref est réglé par une option locale
\usepackage[french]{varioref} si frenchb ne force pas french.
Qu'en pensez-vous ?
--
Jean-Pierre
Je suis tout à fait d'accord avec cette analyse. Personnellement,
j'utilise frenchb (j'y suis habitué, et, comme on l'a dit, french
n'est pas distribué par défaut).
Par contre j'insiste sur le problème de pdfscreen: si on compile
le code suivant
\documentclass{book}
\usepackage{times}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[screen,panelleft,sectionbreak,bluelace]{pdfscreen}
\margins{.75in}{.75in}{.75in}{.75in}
\screensize{6in}{8in}
\makeatletter
\usepackage{babel}
\makeatother
\begin{document}
\title{Titre}
\author{Auteur}
\date{Aujourd'hui}
\maketitle
\tableofcontents{}
\section{Une Section}
Test
\section{Une Section}
Test...
\end{document}
avec pdflatex, tout va bien. MAIS, si on rajoute une option
de langue à \documentclass alors le bouton sommaire (contents)
renvoie à la page de titre au lieu de la table ds matières.
Or, si je ne me trompe, LyX rajoute automatiquement cette
option. Ma question était donc: comment faire pour utiliser
pdfscreen avec LyX?
Ph. C.
Re: Guillemets
On Wed, 25 Jun 2003 16:41:16 +0200 (MEST)
"Jean-Pierre.Chretien" <[EMAIL PROTECTED]> wrote:
> Je trouve personnellement que l'abondance des choix nuit considérablement
> à la clarté, nous avons donc à mon avis deux options pour l'appel du .ldf
> 1/ on ne laisse que frenchb (que l'on pourrait appeler Francophone),
> pour traiter toutes les installations particulières acadienne, canadienne
> et française, et toutes nouvelle langue paramétrée par frenchb.ldf;
> ceux qui veulent forcer frenchle peuvent adapter leur install (La)TeX,
> soit temporairement par (par exemple sous Unix);
> echo '\input{french.ldf}' > frenchb.ldf
> soit de façon permanente.
> 2/ on laisse les deux, le nommage pouvant être alors Francophone
> et French
> Cette dernière solution présente l'inconvénient de ne pas être compatible
> avec le nommage antérieur. Quid de French et French(le) pour
> enlever le GUTenberg qui apparemment n'a plus de raison d'être ?
>
> Du point de vue strictement LyX, la première solution me paraît nettement
> préférable (LyX ne gêre pas l'installation locale de LaTeX,
> à partir de ce moment on ne laisse que celle qui est répandue
> sur toutes les distributions).
>
>
> A noter que le problème de varioref est réglé par une option locale
> \usepackage[french]{varioref} si frenchb ne force pas french.
>
> Qu'en pensez-vous ?
>
> --
> Jean-Pierre
>
Je suis tout à fait d'accord avec cette analyse. Personnellement,
j'utilise frenchb (j'y suis habitué, et, comme on l'a dit, french
n'est pas distribué par défaut).
Par contre j'insiste sur le problème de pdfscreen: si on compile
le code suivant
\documentclass{book}
\usepackage{times}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[screen,panelleft,sectionbreak,bluelace]{pdfscreen}
\margins{.75in}{.75in}{.75in}{.75in}
\screensize{6in}{8in}
\makeatletter
\usepackage{babel}
\makeatother
\begin{document}
\title{Titre}
\author{Auteur}
\date{Aujourd'hui}
\maketitle
\tableofcontents{}
\section{Une Section}
Test
\section{Une Section}
Test...
\end{document}
avec pdflatex, tout va bien. MAIS, si on rajoute une option
de langue à \documentclass alors le bouton sommaire (contents)
renvoie à la page de titre au lieu de la table ds matières.
Or, si je ne me trompe, LyX rajoute automatiquement cette
option. Ma question était donc: comment faire pour utiliser
pdfscreen avec LyX?
Ph. C.
Re: Guillemets
On Mon, 23 Jun 2003 12:33:12 +0200
Bernard Gaulle [EMAIL PROTECTED] wrote:
Seul frenchb est installé par défaut.
non, frenchb arrive avec Babel mais il ce n'est pas la seule
option de francisation, comme je l'ai largement expliqué.
Comme certains packages ne reconnaissent pas l'option frenchb (comme
par exemple varioref) il faut rajouter dans les options de la classe
de document french.
Comme cela tout va très bien,
non, cela n'est pas l'idéal de beauté. Dans toutes les distributions
récentes frenchb et frenchle sont en concurrence. Le fait de coder
french en option de \documentclass chargera frenchle si vous oubliez
de charger _explicitement_ babel avec frenchb. Par ailleurs comme je
l'ai dit \usepackage[french]{babel} charge en priorité frenchle.
L'option de francisation par défaut est donc plutot frenchle.
Sur la distribution que j'utilise ici (tetex-1.0.7-83.3) frenchle
n'est pas présent.
\usepackage[english]{babel} devrait suffire, non ?
Non. Cela ne change rien au problème: dès que l'on charge babel,
le bouton Sommaire (ou Contents) ne marche plus, et, avec l'option
paneltoc on obtient une erreur que l'on ne peut corriger qu'en
modifiant le .toc à la main et en recompilant une fois.
d'autant plus que pdfscreen
possède une option french (à peu près) satisfaisante.
ne mélangeons pas, l'option french de pdfscreen permet de franciser
le titrage produit par pdfscreen, alors que l'option
french/frenchb/frenchle/frenchpro s'occupe de bien d'autres choses,
dont la traduction des libellés produits par LaTeX.
C'est juste, mais, je ne sais pas quoi faire, si ce n'est essayer de
modifier pdfscreen.sty, ce qui ne m'enchante pas..., n'étant pas
spécialiste de programation TeX.
Ph. C.
Re: Guillemets
On Mon, 23 Jun 2003 12:33:12 +0200
Bernard Gaulle <[EMAIL PROTECTED]> wrote:
> > Seul frenchb est installé par défaut.
>
> non, frenchb arrive avec Babel mais il ce n'est pas la seule
> option de francisation, comme je l'ai largement expliqué.
>
> > Comme certains packages ne reconnaissent pas l'option frenchb (comme
> > par exemple varioref) il faut rajouter dans les options de la classe
> > de document "french".
> > Comme cela tout va très bien,
>
> non, cela n'est pas l'idéal de beauté. Dans toutes les distributions
> récentes frenchb et frenchle sont en concurrence. Le fait de coder
> "french" en option de \documentclass chargera frenchle si vous oubliez
> de charger _explicitement_ babel avec frenchb. Par ailleurs comme je
> l'ai dit \usepackage[french]{babel} charge en priorité frenchle.
> L'option de francisation par défaut est donc plutot frenchle.
Sur la distribution que j'utilise ici (tetex-1.0.7-83.3) frenchle
n'est pas présent.
>
> \usepackage[english]{babel} devrait suffire, non ?
Non. Cela ne change rien au problème: dès que l'on charge babel,
le bouton Sommaire (ou Contents) ne marche plus, et, avec l'option
paneltoc on obtient une erreur que l'on ne peut corriger qu'en
modifiant le .toc "à la main" et en recompilant une fois.
> > d'autant plus que pdfscreen
> > possède une option french (à peu près) satisfaisante.
>
> ne mélangeons pas, l'option french de pdfscreen permet de franciser
> le titrage produit par pdfscreen, alors que l'option
> french/frenchb/frenchle/frenchpro s'occupe de bien d'autres choses,
> dont la traduction des libellés produits par LaTeX.
>
C'est juste, mais, je ne sais pas quoi faire, si ce n'est essayer de
modifier pdfscreen.sty, ce qui ne m'enchante pas..., n'étant pas
spécialiste de programation TeX.
Ph. C.
RE: lyx-1.2.0
Tout d'abord, la consomation de mémoire semble être beaucoup plus
importante que sur la version 1.1.6 : avec un fichier de 1,8Mo la
consomation de mémoire après chargement est environ de:
-avec la version 1.1.6 : 12Mo
-avec la version 1.2 (et après nétoyage du fichier, le
passage de 1.1.6 à 1.2 ne se faisant pas tout seul...) : 30Mo
Qu'est ce qu'il y a dans ce document? Des tables? Autre chose?
Le seul document de cette taille que j'aie sous la main ne prend que 18Mo.
Je suis sur qu'il est possible d'ameliorer ca.
C'est un cours de math. Il n'y a pas de tableaux ni d'images ni d'objets flottants
insérés par LyX. Par
contre il y a beaucoup d'ert-insert, beaucoup d'étiquettes, de références croisées et
un gros index.
Pourquoi ne
pas avoir utilisé \begin{center} ... \end{center} comme un
environnnement et pas comme s'il s'agissait d'une commande?
Je ne comprends pas.
\begin{center} ... \end{center} est un environnement latex, et on peut l'utiliser
comme tel sous LyX :
toutes les lignes qu'il contient sont centrées. Dans le cas de lyx-1.2, si on centre
deux lignes
consécutives, il écrit deux fois cet environnement, ce qui est inutile.
Personnellement, j'ai
mis cet environnement dans mes layouts.
-Personnellement je trouve plus lourde l'utilisation de
ert-insert et
de PassThru que l'utilisation de Latex des versions
précédente. Mais c'est peut-être une affaire d'habitude.
J'espere que ces problemes vont s'ameliorer plus tard.
Comme je l'ai dit sur lyx-devel ce qui me gêne le plus c'est que l'on ne peut plus
écrire une
formule de math (avec lyx) dans un paragraphe marqué PassThru comme on pouvait le faire
avec le tag Latex. J'avais utilisé cette possibilité pour écrire un layout permettant
de faire, assez facilement, des diagrammes mathématiques en utilisant PSTricks (c'est,
à mon avis, ce qui donne les meilleurs résultats de très loin) sans avoir à se souvenir
de toutes les commandes barbares de pstricks.
Philippe
RE: lyx-1.2.0
>> Tout d'abord, la consomation de mémoire semble être beaucoup plus
>> importante que sur la version 1.1.6 : avec un fichier de 1,8Mo la
>> consomation de mémoire après chargement est environ de:
>> -avec la version 1.1.6 : 12Mo
>> -avec la version 1.2 (et après nétoyage du fichier, le
>> passage de 1.1.6 à 1.2 ne se faisant pas tout seul...) : 30Mo
>Qu'est ce qu'il y a dans ce document? Des tables? Autre chose?
>Le seul document de cette taille que j'aie sous la main ne prend "que" 18Mo.
>Je suis sur qu'il est possible d'ameliorer ca.
C'est un cours de math. Il n'y a pas de tableaux ni d'images ni d'objets flottants
insérés par LyX. Par
contre il y a beaucoup d'ert-insert, beaucoup d'étiquettes, de références croisées et
un gros index.
>> Pourquoi ne
>> pas avoir utilisé \begin{center} ... \end{center} comme un
>> environnnement et pas comme s'il s'agissait d'une commande?
>Je ne comprends pas.
\begin{center} ... \end{center} est un environnement latex, et on peut l'utiliser
comme tel sous LyX :
toutes les lignes qu'il contient sont centrées. Dans le cas de lyx-1.2, si on centre
deux lignes
consécutives, il écrit deux fois cet environnement, ce qui est inutile.
Personnellement, j'ai
mis cet environnement dans mes layouts.
>> -Personnellement je trouve plus lourde l'utilisation de
>> "ert-insert" et
>> de "PassThru" que l'utilisation de "Latex" des versions
>> précédente. Mais c'est peut-être une affaire d'habitude.
>J'espere que ces problemes vont s'ameliorer plus tard.
Comme je l'ai dit sur lyx-devel ce qui me gêne le plus c'est que l'on ne peut plus
écrire une
formule de math (avec lyx) dans un paragraphe marqué PassThru comme on pouvait le faire
avec le tag Latex. J'avais utilisé cette possibilité pour écrire un layout permettant
de faire, assez facilement, des diagrammes mathématiques en utilisant PSTricks (c'est,
à mon avis, ce qui donne les meilleurs résultats de très loin) sans avoir à se souvenir
de toutes les commandes barbares de pstricks.
Philippe
lyx-1.2.0
Bonjour,
j'utilise LyX depuis plusieurs années et j'apprécie beaucoup sa grande
flexibilité. Voyant que la version 1.2 était sortie je l'ai installé sur
ma machine pour la tester. Un premier test rapide m'a tout de suite
montré les améliorations remarquables mais il y a aussi des différences
par rapport aux versions précédentes qui m'ont étonné. Comme il ne
s'agit pas de bugs proprement dit, j'en parle sur cette liste.
Tout d'abord, la consomation de mémoire semble être beaucoup plus
importante que sur la version 1.1.6 : avec un fichier de 1,8Mo la
consomation de mémoire après chargement est environ de:
-avec la version 1.1.6 : 12Mo
-avec la version 1.2 (et après nétoyage du fichier, le passage de 1.1.6
à 1.2 ne se faisant pas tout seul...) : 30Mo
Toutefois, une fois passé le chargement du document, la consomation de
mémoire n'augmente pas quand on travaille sur le fichier.
En second lieu, il y a des différences dans la traduction TeX qui ont
produit des erreurs qui n'ont pu s'arranger qu'en modifiant les classes
de document LyX que je m'était fabriqué. Parmis ces différences en voici
deux qui m'ont ennuyé un certain temps:
-dans la fenêtre Format-Paragraphe le centrage n'est plus traduit par
\centering mais par \begin{center} ... \end{center}. Cela se traduit par
l'ajout d'espaces verticaux qui peuvent être indésirables. Pourquoi ne
pas avoir utilisé \begin{center} ... \end{center} comme un
environnnement et pas comme s'il s'agissait d'une commande? Si je ne
veux pas avoir ces espaces, il me faut utiliser ert-insert ce qui est
plus long surtout si je doit modifier un fichier écrit avec la version
1.1.6.
-Lorsque l'on utilise des layouts comportant un preambule, celui-ci est
écrit par LyX dans le preambule-LaTeX du fichier TeX produit (pour les
layouts utilisés). Sur les versions précédentes de LyX l'ordre dans
lequel ces preambules était écrits respectait l'ordre d'utilisation des
layouts (ce dont je m'était servi). Avec la version 1.2 il semble que
les preambules sont écrits dans l'ordre alphabétique des layouts
correspondants. Avec mes classes cela produit des erreurs TeX non
rectifiables (sauf à réécrire les layouts complètement). Ce changement
est-il voulu.
-Personnellement je trouve plus lourde l'utilisation de ert-insert et
de PassThru que l'utilisation de Latex des versions précédente. Mais
c'est peut-être une affaire d'habitude.
Cela dit je reconnais que cette version est une amélioration
considérable par rapport aux versions antérieures.
Ph. Charpentier
lyx-1.2.0
Bonjour,
j'utilise LyX depuis plusieurs années et j'apprécie beaucoup sa grande
flexibilité. Voyant que la version 1.2 était sortie je l'ai installé sur
ma machine pour la tester. Un premier test rapide m'a tout de suite
montré les améliorations remarquables mais il y a aussi des différences
par rapport aux versions précédentes qui m'ont étonné. Comme il ne
s'agit pas de "bugs" proprement dit, j'en parle sur cette liste.
Tout d'abord, la consomation de mémoire semble être beaucoup plus
importante que sur la version 1.1.6 : avec un fichier de 1,8Mo la
consomation de mémoire après chargement est environ de:
-avec la version 1.1.6 : 12Mo
-avec la version 1.2 (et après nétoyage du fichier, le passage de 1.1.6
à 1.2 ne se faisant pas tout seul...) : 30Mo
Toutefois, une fois passé le chargement du document, la consomation de
mémoire n'augmente pas quand on travaille sur le fichier.
En second lieu, il y a des différences dans la traduction TeX qui ont
produit des erreurs qui n'ont pu s'arranger qu'en modifiant les classes
de document LyX que je m'était fabriqué. Parmis ces différences en voici
deux qui m'ont ennuyé un certain temps:
-dans la fenêtre Format->Paragraphe le centrage n'est plus traduit par
\centering mais par \begin{center} ... \end{center}. Cela se traduit par
l'ajout d'espaces verticaux qui peuvent être indésirables. Pourquoi ne
pas avoir utilisé \begin{center} ... \end{center} comme un
environnnement et pas comme s'il s'agissait d'une commande? Si je ne
veux pas avoir ces espaces, il me faut utiliser "ert-insert" ce qui est
plus long surtout si je doit modifier un fichier écrit avec la version
1.1.6.
-Lorsque l'on utilise des layouts comportant un preambule, celui-ci est
écrit par LyX dans le preambule-LaTeX du fichier TeX produit (pour les
layouts utilisés). Sur les versions précédentes de LyX l'ordre dans
lequel ces preambules était écrits respectait l'ordre d'utilisation des
layouts (ce dont je m'était servi). Avec la version 1.2 il semble que
les preambules sont écrits dans l'ordre alphabétique des layouts
correspondants. Avec mes classes cela produit des erreurs TeX non
rectifiables (sauf à réécrire les layouts complètement). Ce changement
est-il voulu.
-Personnellement je trouve plus lourde l'utilisation de "ert-insert" et
de "PassThru" que l'utilisation de "Latex" des versions précédente. Mais
c'est peut-être une affaire d'habitude.
Cela dit je reconnais que cette version est une amélioration
considérable par rapport aux versions antérieures.
Ph. Charpentier
Re: Traduction des noms d'environnements
Lasgouttes, J.M. wrote: Bonjour, je ne vois pas comment babel peut traduire les labels des environnements théorèmes. Si cela est possible comment fait-on? Ph. C. A ma connaissance, c'est en effet impossible (ce qui est bien dommage...) JMarc Ne pourrait-on pas avoir alors des amsmathfr.inc (ou d'une autre langue) qui seraient chargés à la place des amsmath.inc lorsque que la langue du document est le français? Cela règlerait tout. Ph. C.
Re: Traduction des noms d'environnements
Lasgouttes, J.M. wrote: > Bonjour, > >>je ne vois pas comment babel peut traduire les labels des >>environnements théorèmes. Si cela est possible comment fait-on? >>Ph. C. >> > >A ma connaissance, c'est en effet impossible (ce qui est bien dommage...) > >JMarc > Ne pourrait-on pas avoir alors des amsmathfr.inc (ou d'une autre langue) qui seraient chargés à la place des amsmath.inc lorsque que la langue du document est le français? Cela règlerait tout. Ph. C.
Re: Traduction des noms d'environnements
adrien.rebollo à écrit: En modifiant LyX les environnements insérant un en-tête (comme Chapitre ou Théorème) pourraient être automatiquement référencés sous ce nom dans la boîte de sélection d'environnements. Emmanuel GUREGHIAN à écrit: Pour chaque environnement il y a 3 noms : 1°) le nom LaTeX - ce qui sera engendré par lyx dans le fichier latex correspondant, 2°) le nom LyX - ce qui est sauvegardé dans le fichier lyx, et permet donc le changement de langue à la volée 3°) le nom LyX WYSIWYM a) ce qui apparait à l'écran b) et in-fine dans le fichier DVI. Normalement seuls les 2 premiers doivent rester en anglais et 3a doit être traduit dans le fichier layout et 3b doit être traduit automatiquement par babel. Bonjour, je ne vois pas comment babel peut traduire les labels des environnements théorèmes. Si cela est possible comment fait-on? Ph. C.
Re: Traduction des noms d'environnements
adrien.rebollo à écrit: >En modifiant LyX les environnements insérant un en-tête (comme "Chapitre" >ou "Théorème") pourraient être automatiquement référencés sous ce nom >dans la >boîte de sélection d'environnements. Emmanuel GUREGHIAN à écrit: >Pour chaque environnement il y a 3 noms : >1°) le nom LaTeX -> ce qui sera engendré par lyx dans le fichier latex >correspondant, >2°) le nom LyX -> ce qui est sauvegardé dans le fichier lyx, et permet >donc le changement de langue à la volée >3°) le nom LyX WYSIWYM >a) ce qui apparait à l'écran >b) et in-fine dans le fichier DVI. Normalement seuls les 2 >premiers doivent >rester en anglais et 3a doit >être traduit dans le fichier layout et 3b doit être traduit >automatiquement par babel. Bonjour, je ne vois pas comment babel peut traduire les labels des environnements théorèmes. Si cela est possible comment fait-on? Ph. C.
