Discussion :

[Frero67]

Bonjour tout le monde !!

Bon et bien on peut dire que je suis à fond dans LateX en ce moment !!

J'ai réussi à me créer des listes dont les item sont ronds colorés à l'intérieur, plus foncés pour la bordure etc... Des cadres évolués, des tableaux avec des colonnes de largeurs différentes, des supers liens avec tikz entre les noeuds, bref des trucs de malades !!!

Je suis super content, mais du coup mes fichier .tex contiennent bien 2pages de nouvelles commandes ou environnements.
Est ce qu'on peut simplement se faire son propre package en faisant copier coller de notre source ?
Pourriez vous m'indiquer un bon tuto pour faire cela ? ou bien me l'expliquer ?

De tout coeur merci pour votre aide car là, je commence vraiment à prendre plaisir à taper à nouveau mes cours pour mes élèves !!

Frero

[Benoists]

Bonjour,

C'est pas très compliqué, voici deux liens. Le premier est synthétique tandis que le second est le guide ultime. Tous les deux sont en anglais mais arrivé à un moment il n'y a plus que ça…

Je pense que tu devrais t'en sortir mais si tu bloques sur un point, j'essayerai de t'aider

[Winnt]

Bonjour,

En sus des informations fournies par Benoists, il y a la possibilité d'utiliser la commande input.

Je m'explique. Voici un exemple de hiérarchie de répertoires de code sources :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Latex
 |--modeles
 |--travail

Et voici un exemple de squelette d'un nouveau document Latex situé dans le répertoire travail :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
\documentclass[10pt,a4paper,french]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[dvipsnames,x11names,svgnames,table]{xcolor}
\usepackage{hyperref}
\usepackage{babel}
% ici on appelle les modèles de code
\input{../modeles/modele_liste}
\input{../modeles/modele_tikz}

Chaque fichier du répertoire modèle étant un fichier tex ne contenant que le code source d'une commande comme par exemple "modele_liste" (pour reprendre l'idée d'un modèle de liste personnalisée cité plus haut).
L'avantage est de ne charger que ce dont on a besoin et de facilement inclure les différents modèles.

Personnellement, j'utilise cette façon de faire pour mes modèles de boîtes conçues avec tcolorbox (les définitions pouvant être très chargées parfois).

[Frero67]

Et ben voilà mes sauveurs !!

Alors déjà Ok pour les liens !! c'est exactement ce que je cherchais. Je pense que le synthétique sera suffisant pour moi ! thanks (t"as vu je me suis mis à l'anglais )

Pour l'astuce de input, c'est excellent, si j'ai bien compris, je mets dans les différents fichiers ou modèles les déclarations et commandes que j'utilise. Ça veut dire que dans le modèle liste je peux mettre les modèles de listes que j'utilise, le modèle box, le modèle de mes box et je peux également classer selon cours. Si c'est un TD, je mets mon fichier modele_td avec les liste, box qui vont bien, si c'est un contrôle idem etc. ? J'ai bien compris ?

A+ !!

Frero

[Benoists]

Pour le lien simpliste, j'en avait un mieux avant mais je n'arrive pas à le trouver, je trouve que celui-ci fait bordélique.

Tu as bien compris, C'est beaucoup plus simple à mettre en place, mais après si tu veux faire des choses comme introduire des options (comme pour charger un package ou une classe), ça devient un peu plus compliqué. Disons que le package permet de cacher la logique interne alors que le simple fichier permet uniquement de déporter. À toi de voir si tu veux quelque chose d'user-friendly (in english ! ) ou juste pratique... Je sais pas si je suis bien compréhensible Un petit exemple, tu as un package permettant de créer des boites avec une option pour modifier la couleur des boites :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

\usepackage[rouge]{boites]

Alors qu'avec le fichier, je ne vois pas comment faire plus simple que définir une commande avant d'appeler le fichier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
\def\couleursboites{rouge}
\input{modeles/boites}

L'autre avantage du package, c'est de pouvoir l'intégrer à ta configuration LaTeX en le plaçant dans le texmf. ça permet de l'appeler depuis n'importe quel document sans avoir à le copier dans le répertoire de travail (je ne pense pas que ce soit possible avec un \input).

[Winnt]

Bonsoir,

Oui Frero67 c'est l'idée en effet.

Alors qu'avec le fichier, je ne vois pas comment faire plus simple que définir une commande avant d'appeler le fichier

Benoists c'est en partie vrai mais cela dépends grandement de la conception de la commande personnelle.
Si, par exemple, elle prend des arguments optionnels ou non...

Personnellement, lors de la création d'une commande personnelle, je commence toujours par créer pile poil celle qui réponds à mon besoin du moment.
Puis, je la retravaille afin de pouvoir utiliser des arguments optionnels ou non (selon mes besoins ou la commande).
Il m'arrive donc parfois de reprendre d'anciens documents suite à une modification profonde d'une commande.
Et dans ce cas là j'apprécie énormément la fonction rechercher de mon éditeur.
Je trouve l'utilisation de la commande input plus souple à l'usage.
Si par exemple, je ne souhaite pas créer une page de titre, je n'inclut pas la ligne \input{modekes/page_titre} qui permet de définir la mise en page de celle-ci et les commandes afférentes.

[Frero67]

Hello !!

Juste encore un petit merci à vous !! j'ai fais mon premier package et j'ai utilisé en fait l'astuce de "input", plus simple je trouve qu'un "vrai" package, et surtout je n'arrivais pas à spécifier le chemin que je voulais pour mes packages : avec input, c'est un jeux d'enfants !!

Big merci !!

[Winnt]

Bonsoir,

Tant mieux si tu a réussi à faire ce que tu voulais.

Ce fil de discussion démontre, s'il en était besoin, qu'il y a plus d'une façon d'obtenir un résultat.
Benoist a parfaitement souligné l'intérêt des classes personnelles avec les possibles désavantages de ma méthode

[Benoists]

Bonsoir,

Tant mieux si tu a réussi à faire ce que tu voulais.

Ce fil de discussion démontre, s'il en était besoin, qu'il y a plus d'une façon d'obtenir un résultat.
Benoist a parfaitement souligné l'intérêt des classes personnelles avec les possibles désavantages de ma méthode

Et inversement, tu as parfaitement montré qu'il y a plusieurs solutions à un problème et qu'il est souvent inutile de se compliquer la vie