[QXP] empêcher les saut de ligne en fin de bloc

[ccciolll]

Bonjour, la question est peut-être un peu surprenante, mais j'aimerais savoir, dans le cadre d'un import de texte, s'il existe un moyen dans xpress pour qu'il n'autorise pas un texte à passer à la ligne s'il est plus long que la largeur du bloc, ou plus précisément qu'il mette un message d'alerte quand le cas se présente.
Si un retour chariot est existant dans le texte importé, il faudrait l'accepter par contre.

L'import de texte devrait se faire via Xdata, si ça peut apporter une solution alternative.

Dans le même ordre d'idée, serait-il possible d'appliquer à une ligne de texte une étroitisation pour le faire tenir dans la largeur du bloc dans le cas où il dépasse.

Pour moi, ces deux demandes sont rigoureusement impossibles, mais je m'aperçois parfois que ce que je croyais impossible sur la base de ma connaissance de Xpress 3.32 ne l'est plus vraiment avec les versions plus récentes… La couche de poussière sur mon cerveau, probablement.

 

[CMYK]

Ça dépend beaucoup de la config de ton doc. Si tu as affaire à un texte sur plusieurs pages, ça me paraît compliqué. Si c’est un texte de quelques lignes, tu peux t’arranger, peut-être, pour avoir autant de blocs que de lignes… mais même comme ça, je ne vois pas comment «*forcer*» le texte à tenir dans le bloc. (Ou alors se pencher sur l’AppleScript… ?)
Quant à la question de faire tenir une ligne dans la largeur du bloc, on le fait tous les jours : sélection de la ligne et on joue (adroitement et intelligemment !) sur les approches et l’échelle horizontale des lettres. Les raccourcis clavier font que c’est un véritable jeu d’enfant, voire une réflexe que l’on applique sans même s’en rendre compte. Si par contre tu vises une solution «*automatique*», encore une fois l’AppleScript serait sans doute ton ami.

 

[Vieux Mac-User]

Bonjour, la question est peut-être un peu surprenante, mais j'aimerais savoir, dans le cadre d'un import de texte, s'il existe un moyen dans xpress pour qu'il n'autorise pas un texte à passer à la ligne s'il est plus long que la largeur du bloc, ou plus précisément qu'il mette un message d'alerte quand le cas se présente.
Si un retour chariot est existant dans le texte importé, il faudrait l'accepter par contre.

L'import de texte devrait se faire via Xdata, si ça peut apporter une solution alternative.

Dans le même ordre d'idée, serait-il possible d'appliquer à une ligne de texte une étroitisation pour le faire tenir dans la largeur du bloc dans le cas où il dépasse.

Pour moi, ces deux demandes sont rigoureusement impossibles, mais je m'aperçois parfois que ce que je croyais impossible sur la base de ma connaissance de Xpress 3.32 ne l'est plus vraiment avec les versions plus récentes… La couche de poussière sur mon cerveau, probablement.

Pour le retour ligne, la solution c'est peut-être d'utiliser un tableau plutôt qu'un bloc texte tout bête ?
L'étroitisation, ça doit pouvoir se scripter mais ça risque d'être fastidieux

 

[magicPDF]

Au risque de me faire huer, saches que si jamais tu as le choix du logiciel, avec InDesign c'est du gâteau pour ajuster les lignes automatiquement. J'ai fait ça sur des kilomètres de tableaux de références de produits pharmaceutiques.

- Quel que soit le logiciel utilisé (XPress ou InDesign) j'utiliserais un tableau (1 colonne), car c'est un bon moyen (sinon le seul) pour empêcher le texte de passer à la ligne, sauf retour de paragraphe.

- Avec InDesign, ensuite il faut créer plusieurs styles de caractères plus ou moins étroitisés qui seront appliqués dynamiquement via des styles GREP (ou via le rechercher-remplacer mais ce n'est pas dynamique) en fonction du nombres de caractères de chaque ligne.
(Voir l'exemple ci-joint, c'est particulièrement visible dans les colonnes Etage et Laboratoire. Ce n'est pas toujours très heureux ni très lisible, mais ça rentre…)

- Avec XPress, faute de pouvoir détecter le nombre de caractères de chaque ligne automatiquement ou via le rechercher-remplacer (à moins que cela ne fasse partie des nouveautés de la version 9 ?) il faudra plutôt faire comme indiqué par CMYK.

 

[Toum'aï]

Voir l'exemple ci-joint

le lien, le lien :siffle:

 

[magicPDF]

le lien, le lien :siffle:

Attend, il m'a fallu faire maigrir le PDF, on n'a pas droit à plus de 97 Ko pour les pièces jointes…

 

[ccciolll]

Super, j'ai les noms de plein de gens du CNRS maintenant ! Yé !

Bon, plus sérieusement, dans l'immédiat je suis contraint de rester sur Xpress (et même sur 7 voire 8) donc je me contente des solutions xpress s'il en existe.

L'utilisation de tableau ne pourra probablement pas fonctionner car les textes doivent pouvoir remonter ou descendre selon le nombre de ligne.
Compter le nombre de caractères, ça je peux le faire avec xdata, en liaison avec plusieurs FdS (feuilles de style), ça marche. Mais c'est bâtard (jillij et wammaw font tous les deux 6 lettres et pourtant pas la même largeur, vous voyez ce que je veux dire).

Concrètement, on a des cartes de visite remplies automatiquement via xdata, et on jette un œil pour voir si du texte déborde (un nom un peu long, un e-mail à rallonge, une zone industrielle au nom à coucher dehors, parfois juste un +33 inattendu dans un téléphone). Quand c'est le cas, on applique une étoritisation (assez rapide avec les raccourcis claviers et les FdS pour les cas fréquents, en effet, ça va assez vite). Mais bon, quand on goûte à l'automatisation, on se prend pour Frankeinstein…
Voilà, donc je me disais "et si…"

Bon, ben dans Xpress, en tout cas, je peux remballer mes espoirs.

Je me doutais du résultat, mais qui ne tente rien…

 

[CMYK]

Bon, ben dans Xpress, en tout cas, je peux remballer mes espoirs.

Je me doutais du résultat, mais qui ne tente rien…

Reste l’AppleScript… je ne dis pas que c’est du gâteau à coder, mais qui ne tente rien…

 

[magicPDF]

Compter le nombre de caractères, ça je peux le faire avec xdata, en liaison avec plusieurs FdS (feuilles de style), ça marche. Mais c'est bâtard (jillij et wammaw font tous les deux 6 lettres et pourtant pas la même largeur, vous voyez ce que je veux dire).

Bien sur, l'idéal serait d'avoir une police non-proportionnelle (à chasse fixe) mais jusqu'ici je n'ai pas eu de clients qui accepte ça.

Pour l'exemple joint, et dans la vraie vie, j'utilise une estimation "large"*, donc il peut arriver que certains mots (comme jillij) soient étroitisés alors qu'ils seraient rentrés quand même, mais bon…




* En général je me base sur des mots comme minimum ou maximum, qui sont plus larges que la moyenne.

---------- Nouveau message ajouté à 12h26 ---------- Le message précédent a été envoyé à 12h24 ----------

je peux remballer mes espoirs.

Tu peux toujours sous-traiter, je fais des promos en ce moment…

 

[Vieux Mac-User]

Tu peux le faire avec un style conditionnel dans Xpress 9.x
Puis exporter vers Xpress 8, il conservera les styles appliqués

Je me suis basé sur une longueur de 5 mots mais tu peux aussi choisir un nombre de caractères

[EDIT] J'ai essayé d'expliquer un peu mieux la démarche ici

 

[CMYK]

Excellent, VMU ! 2 thumbs up!

 

[magicPDF]

(à moins que cela ne fasse partie des nouveautés de la version 9 ?)

 

[ccciolll]

SI je ne m'abuse, ça correspond à ce que je sais faire avec Xdata :
- condition : nbre de caractère
- action : choix d'une FdS plus étroitisée (ou approche serrée dans ton exemple, mais c'est kifkif)
et cela reste valable avec des très vieux xpress (du moment qu'un vieil xdata lui corresponde)