Options de soulignement dans Illustrator CS5

[Goliath]

... 6 mots ou 3 paragraphes quelle importance si tout le reste de mon travail c'est du vecteur!

 

[ccciolll]

L'ennui c'est que tu as besoin d'une fonction qui, l'air de rien, est assez pointue.

Et là, ça dépasse la notion de « 3 mots à ajouter » (notion dans laquelle, on devine bien qu'on ne va pas faire des paragraphes, avec tout ce que ça sous-entend de fonctionnalités (césure, feuille de style, espace avant, etc.))

Mais je peux comprendre que ça soit agaçant d'utiliser 2 logiciels pour ça. On a tellement pris l'habitude que Xpress/InDesign puisse importer du PSD et gérer des transparence et des ombrages à la volée (je ne me compte pas dans ce « on ») que naviguer d'un logiciel à l'autre semble une contrainte énorme.

 

[claude72]

... 6 mots ou 3 paragraphes quelle importance si tout le reste de mon travail c'est du vecteur!

L'importance, c'est que pour 3 mots, genre "Conseil Général de la Marne" ou "Ministère de la recherche", ça se fait avec un simple départ de texte centré et tu as rarement besoin de fonctions typographiques pointues, donc ça reste du domaine basique gérable par Illustrator...

... alors que dans 3 paragraphes tu as souvent besoin de fonctions typos plus évoluées qui dépassent les possibilités (limitées) d'Illustrator : la preuve, tu as seulement 1 paragraphe à écrire et tu ne peux pas faire ce que tu as besoin de faire dans Illustrator. :siffle:

Et apparemment, tu n'as pas bien compris ce que j'écris : ce n'est pas de faire du texte dans Illustrator qui est ridicule, c'est de vouloir faire un travail dans un logiciel pas prévu pour cet usage et ensuite de râler contre l'éditeur qui n'a pas mis dedans la fonction dont TU aurais besoin...

En clair, soit tu VEUX faire du texte dans Illustrator et dans ce cas tu te contentes de ce qu'il sait faire, soit tu veux quelquechose de plus pointu et tu utilises l'outil qui est prévu pour ça et qui te permettra de faire ce que tu veux... mais je trouve ridicule de râler parceque l'outil inadapté que tu as décidé d'utiliser ne peut pas faire ce qu'il n'est pas prévu pour faire...

... et je trouve ça à peu près aussi ridicule que de râler contre le fabricant d'un marteau parceque son marteau ne peut pas devisser une vis, ou d'écrire à Renault pour te plaindre qu'il n'est pas possible de mettre une armoire normande en chêne massif dans une Twingo !

Il ne fallait pas beaucoup pour comprendre qu'avec une page entièrement en vectoriel avec à côté juste quelques paragraphes on ne passe pas par InDesign, ...

Il ne faut pas beaucoup pour comprendre que quel que soit le contenu de la page, ça ne change pas l'indigence des outils texte d'Illustrator... tiens, par exemple, où est l'espace fine insécable dans Illustrator ??? (et ne me répond pas qu'il suffit de diminuer le corps d'une espace normale... parceque d'abord je sais faire ce genre de bidouillage, et ensuite ce n'est pas une fine insécable).


Donc, quel que soit le contenu de la page, moi je passe par InDesign pour le texte, parceque je sais que dans InDesign j'ai TOUT ce qu'il faut (ou du moins le maximum existant) pour gérer facilement les quelques paragraphes correctement (notament des espaces adaptées à la typo française et les fonctions avancées du genre soulignement qui n'existent pas dans Illustrator) et de plus j'ai un plug-in correcteur orthographique puissant et performant qui ne fonctionne pas avec Illustrator, parceque je sais aussi que dans InDesign je vais pouvoir changer la largeur d'un bloc de texte sans que ça contracte/dilate le texte contenu dans le bloc... et je sais que dans Illustrator je vais me faire ch...r et je vais perdre mon temps.

Et je le sais parceque j'ai déjà fait l'essai et plusieurs fois même : j'ai fais l'erreur d'écouter des conseils mal avisés sur les forums, et je me suis dis un truc du genre : boh, allez, il y a juste 1 ou 2 paragraphes, il y a des gens qui le font sous Illustrator, alors bon, puisque ça se fait je vais essayer et les faire directement dans Illustrator... et à chaque fois je me suis fait avoir et j'ai eu des soucis que je n'aurai pas eu dans InDesign !!!

Par exemple, sur un groupe de docs (des étiquettes de bouteilles) j'ai été emmerdé par 2 paragraphes de texte à chaque fois qu'il a fallu faire des modifs pour remettre chaque doc à jour. Et je suis sûr que sur ce travail j'aurais eu moins de problème si j'avais fait le dessin vectoriel (relativement simple) dans InDesign (voire faire ce dessin dans Illustrator et le copier/coller dans InDesign), plutôt que de faire le texte dans Illustrator...

Alors PLUS JAMAIS je ne ferais la connerie de faire du texte dans Illustrator !!!

(surtout qu'en plus ces docs ont été créé sous Illustrator 10, et ensuite il a fallu que je les modifie avec Illustrator CS3...)



---------- Nouveau message ajouté à 17h30 ---------- Le message précédent a été envoyé à 16h19 ----------

On n'a pas besoin d'Illustrator pour ajouter 3 carrés et un cercle de couleur dans une mise en page, de même qu'on n'a pas besoin de InDesign pour ajouter 3 mots dans une illustration.

3 mots dans Illustrator ou 3 carrés et un cercle dans InDesign, c'est la même chose, c'est aussi rudimentaire, et là je suis d'accord avec toi : les fonctions basiques de dépannage du logiciel-pas-prévu-pour-ça sont suffisantes...

... mais je ne parlais pas de faire seulement "3 carrés et un cercle de couleur", je parlais de dessin vectoriel : quelquechose d'un peu plus complexe, avec une différence par rapport à "3 carrés et un cercle de couleur" dans la même proportion que celle qu'il y a entre 3 mots centrés sous un logo et 3 vrais paragraphes de texte (ou même un seul), avec des justifications, des césures, des soulignements, des espaces fines, des fautes d'orthographes potentielles, etc.

 

[Goliath]

...bon ben c’est ton avis, désolé mais je ne suis pas d’accord avec toi.
C’est quand même fou qu’on ne puisse plus donner son avis sans se faire taper sur les doigts par quelqu’un qui veut absolument me faire changer d’avis par rapport a une simple fonctionnalité qui à mon avis aurait été intéressante d’avoir aussi sous Illustrator.
Je le répète pour la millième fois, je sais qu’Illustrator n’est pas un logiciel de mise en page! Ce n’est pas pour cela que certaines fonctions typographiques de base ne peuvent pas s’y retrouver.
Relis le titre de mon post. Options de soulignement dans Illustrator CS5. Point.
Qui n’a jamais parlé d’espace insécable? Il n’y a que toi qui en parles... et de toute façon si tu regardes de près les options de texte d’Illustrator ce n’est déjà pas mal: césure, crénage, décalages des lignes, l’approche, les feuilles de styles de paragraphe et de caractères, ... et j’en passe sûrement, donc pourquoi pas l’option de gestion des filets?
Pour retourner à mon caprice d’enfant gâté, je suppose que tu vas me dire que quand tu as quelques paragraphes et une illustration vectorielle qui fait plusieurs milliers de points d’encrages tu passes par InDesign? Donc logiquement tu importes ton illustration en eps, car de toute façon InDesign refuse de la copier, et à chaque fois que tu dois faire une modification à ton illustration "allez hop!" on repasse par Illustrator? Bravo, mais moi ce n’est pas ma méthode de travail.
Là où par contre je suis d’accord avec toi c’est qu’un jour Adobe fusionnera InDesign et Illustrator en un seul logiciel, ... et là ça sera une vraie usine à gas

Bonne soirée.

Au fait l’astuce pour l’espace insécable dans Illustrator: remplacer l’espace insécable par un tiret (ou autre caractère) et mettre l’opacité à 0%

 

[magicPDF]

Donc logiquement tu importes ton illustration en eps, car de toute façon InDesign refuse de la copier, et à chaque fois que tu dois faire une modification à ton illustration "allez hop!" on repasse par Illustrator?

C'est un non négatif !
Tu enregistres ton fichier Illustrator au format AI hybride* ou au format PDF hybride* (c'est pareil*) et ensuite tu importes dans InDesign.
Les mises-à-jour sont automatiques en cas de modification.


Quand à l'EPSosaurus Rex, je préfère ne pas en parler, c'est mauvais pour mon cœur.



* ==> http://abracadabrapdf.net/articles.php?lng=fr&pg=961

 

[Goliath]

C'est un non négatif !
Tu enregistres ton fichier Illustrator au format AI hybride* ou au format PDF hybride* (c'est pareil*) et ensuite tu importes dans InDesign.
Les mises-à-jour sont automatiques en cas de modification.


Quand à l'EPSosaurus Rex, je préfère ne pas en parler, c'est mauvais pour mon cœur.



* ==> http://abracadabrapdf.net/articles.php?lng=fr&pg=961

... ok pour l'.ai, mais on est toujours dans un "aller-retour"... :hein:

 

[claude72]

Je le répète pour la millième fois, je sais qu’Illustrator n’est pas un logiciel de mise en page! Ce n’est pas pour cela que certaines fonctions typographiques de base ne peuvent pas s’y retrouver.

Ce que tu n'as pas l'air de (vouloir) réaliser et comprendre, outre la contradiction de base dans tes propos ("je sais qu’Illustrator n’est pas un logiciel de mise en page" VS "je veux des fonctions typo avancées") c'est que le souligné que tu demandes n'est pas une fonction de base, mais c'est au contraire une fonction avancée (qui n'est d'ailleurs apparue que dans les versions récentes de XPress/InDesign) et il est tout à fait logique (voire normal) que cette fonction avancée n'existe pas dans un logiciel dont ce n'est tout simplement pas le rôle !


Perso, je trouve qu'il est normal qu'Adobe ne s'emmmerde pas à implémenter des fonctions avancées dans des domaines qui ne sont pas le domaine principal du logiciel !!! Et ce n'est pas pour t'emmerder et t'empêcher de souligner tes mots, c'est tout simplement pour ne pas avoir 3 logiciels qui font quasiment les mêmes choses (il faut bien continuer à vendre les 3 !!!), et qui deviennent inutilisables tellement ils sont complexes...

... ou dont certaines fonctions "greffées" fonctionnent mal, comme les textes dans Photoshop (ça c'était une belle erreur !!!) ou comme les fonctions de dessins vectoriel et les fonctions de retouche d'image dans XPress.

... je suppose que tu vas me dire que quand tu as quelques paragraphes et une illustration vectorielle qui fait plusieurs milliers de points d’encrages tu passes par InDesign?

Bien-sûr ! et tu n'as pas besoin de le supposer, car je l'ai écrit noir sur blanc dans mon post précédent :rateau:
(j'ai même ecris que, suite à des expériences malheureuses, "PLUS JAMAIS je ne ferais la connerie de faire du texte dans Illustrator" : ça me paraît suffisament clair ! non ?)

Donc logiquement tu importes ton illustration en eps...

En EPS ??? tu plaisantes ? tu es tellement fâché que tu ne sais plus ce que tu dis ? ou tu bosses vraiment avec de l'EPS-Illustrator dans InDesign ???

Edit : @ Magic : je me doutais que tu allais réagir !!! c'est pour ça que je te l'ai laissé... désolé pour ton coeur.

car de toute façon InDesign refuse de la copier, et à chaque fois que tu dois faire une modification à ton illustration "allez hop!" on repasse par Illustrator?

Oui : je clique sur la petite icone "Modifier dans le logiciel original", et ça m'ouvre automatiquement mon import dans Illustrator ensuite, la modif faite, l'enregistrement final renvoie automatiquement dans ID... donc, au final, la légère perte de temps du passage de l'un à l'autre est insignifiante par rapport au gain qu'apporte la gestion du texte dans InDesign... (j'ai testé !)

Là où par contre je suis d’accord avec toi c’est qu’un jour Adobe fusionnera InDesign et Illustrator en un seul logiciel, ... et là ça sera une vraie usine à gas

Les deux logiciels ont déjà beaucoup de fonctions communes... et sont déjà des usines à gaz ! ça ne ferait que quelques palettes et quelques outils de plus : on n'est plus à ça près !!!
Et pour ne pas trop encombrer l'écran, on peut par exemple facilement imaginer deux espaces de travail différents (texte / dessin) et switcher d'un espace à l'autre en fonction de ce qu'on fait sur le doc.

Et ça règlerait bien des problèmes de mauvais choix d'utilisation de l'un ou l'autre des logiciels, en évitant notament les conneries des brèles qui sortent un livre de 48 pages en 48 fichiers Illustrator PDF hybrides avec texte vectorisé !

En fait, le plus gros problème risque d'être le format de sortie : chacun a son propre format de données natif, et quel que soit celui qui sera retenu pour le combiné "InStrator" ou "IlluDesign", ça posera certainement des problèmes de compatibilité avec les documents déjà existants !!!

Au fait l’astuce pour l’espace insécable dans Illustrator: remplacer l’espace insécable par un tiret (ou autre caractère) et mettre l’opacité à 0%

bof... insécable, certes, mais pas fine... donc il faut encore bidouiller un peu plus pour la fine
Quant à l'opacité à 0%, il y a assez de problèmes avec toutes ces transparences pour éviter de les utiliser quand elles ne sont pas indispensables... surtout si tu veux bosser avec de l'EPS.

Dans InDesign c'est "pomme+alt+shift m"...




---------- Nouveau message ajouté à 19h36 ---------- Le message précédent a été envoyé à 19h17 ----------

... ok pour l'.ai, mais on est toujours dans un "aller-retour"... :hein:

En fait, il y a effectivement quelquechose qui me gène dans ce système "aller-retour", c'est l'obligation pour que l'aller-retour fonctionne de façon automatique d'utiliser des imports hybrides... soit du .AI, soit de l'EPS, ce qui sur des gros fichiers est source de perte de place et donc de temps, et m'énerve particulièrement parceque je déteste m'encombrer de données inutiles... en plus des problèmes avec l'EPS.

Perso, je prèfère plutôt travailler sur un fichier Illustrator .AI pur (non-hybride), et créer un fichier d'import final PDF non-hybride pour importer dans InDesign... mais alors l'aller-retour automatique ne fonctionne plus... c'est embêtant !

 

[Vieux Mac-User]

Pourquoi vectoriser un texte ???

Quand je fais du packaging, il m'arrive très souvent de DEVOIR vectoriser. Moi j'ai pas d'états d'âmes, je fais ce que l'imprimeur me demande (et pourtant j'utilise souvent des polices otf compatibles Mac/PC)

Quand j'ai traité mon fichier avec XPress, pas de soucis mais avec Indy les filets de soulignement dégagent (Si quelqu'un a une astuce je suis preneur).

En général je fais un pdf normal, je récupère les filets dans illustrator et je les réimporte dans Indy avant de vectoriser l'ensemble. Mais quelquefois des corrections surviennent à ce moment-là et ça devient très pénible.

 

[claude72]

... je fais ce que l'imprimeur me demande...

Et l'imprimeur, il te demande des EPS avec fontes vectorisées ? (ce qui est un peu antique/obsolète/dépassée !!! mais encore compréhensible)...

... ou des PDF avec fontes vectorisées ?...

... parceque dans ce cas il y a deux possibilités, toutes les deux pas très reluisantes :

- soit l'imprimeur est une brèle qui ne sait pas traiter correctement des PDF, et/ou qui n'a pas compris que la différence essentielle entre les EPS du siècle dernier et les PDF c'est que le PDF incorpore les polices et qu'il n'y a pas besoin de les vectoriser !!! (et dans ce cas je change d'imprimeur)

- soit l'imprimeur te prend pour une brèle qui n'est pas capable de faire un travail correct avec des fontes correctes ! et il demande la vectorisation pour être tranquille et être sûr de ne pas avoir de problème de polices avec tes fichiers...
D'un côté, c'est vrai que c'est une sécurité... mais d'un autre ça abime les caractères, surtout pour les petits corps (fréquent dans les packaging, il me semble ?), et dans les fichiers qu'il reçoit il y en a certainement qui sont faits par des graphistes consciencieux et compétents et qui n'ont pas besoin de vectorisation !!!

Dans les deux cas, vectoriser des fontes est toujours une mauvaise idée !!!


(Perso, de l'époque où j'étais imprimeur et malgré mes RIP antédiluviens, je n'ai jamais demandé à un client de vectoriser les fontes dans un PDF... au contraire même, il m'est arrivé de demander à des clients qui m'avait envoyé des PDF avec fontes vectorisées de refaire leur PDF sans vectoriser les fontes ! d'ailleurs, en général ils étaient très étonnés, cette demande de vectoriser étant très fréquente chez les imprimeurs...)

 

[GraphiqueDesign]

Hello Claude !

Dans le cas du PDF, je comprend le ridicule à vouloir vectoriser les polices mais dans le cas d'un EPS, quelle différence visuelle entre une police vectorisée et une autre ne l'étant pas ?

D'avance, merci pour tes explications.

 

[Vieux Mac-User]

... ou des PDF avec fontes vectorisées ?...

... parceque dans ce cas... l'imprimeur est une brèle qui ne sait pas traiter correctement des PDF

Ben ça m'avance pas beaucoup. Il sont très gentils sinon...
(2 occurrences seulement sur les 12 derniers mois et je les ai trouvé très efficaces tous les deux)

Je ne choisis pas toujours l'imprimeur moi-même et il y a d'autres facteurs qui entrent en jeu, prix, délais et capacité technique, je fais avec et ça se passe toujours très bien au final, à part mon problème de filets InDesign je n'ai pas rencontré beaucoup de soucis dans ma longue carrière, enfin rien qui ne se corrige au BAT. Les contacts sont toujours cordiaux, le résultat est souvent très bien. Pas de quoi s'arracher les cheveux hein !

Comme je bosse quand même essentiellement sur XPress, c'est assez accessoire, mais j'imagine que des gens qui bossent plus que moi sur Indy auraient pu m'indiquer pourquoi ces filets dégagent, ça me parait pas normal.

 

[claude72]

Il sont très gentils sinon...

Ça n'empêche pas ! (ni dans un sens, ni dans l'autre...)


*********

Dans le cas du PDF, je comprend le ridicule à vouloir vectoriser les polices

Ridicule, oui, quand on sait flasher des PDF, et qu'on peut faire confiance aux graphistes qui les ont créés...

... en revanche, quand ces deux conditions ne sont pas réunies, la vectorisation des fontes paraît une solution simple à celui qui ne sait pas comment marche un PDF, et offre une sécurité confortable à celui qui ne fait pas confiance aux créateurs des fichiers.

Ceci dit, quand les fichiers sortent d'un Publisher via un PDFcreator bugué , la vectorisation est parfois indispensable pour le flashage !!!

... mais dans le cas d'un EPS, quelle différence visuelle entre une police vectorisée et une autre ne l'étant pas ?

EPS ou PDF, le problème est le même... sauf qu'à l'époque de l'EPS, comme l'EPS ne savait pas incorporer les polices, il n'y avait pas trop le choix et il fallait vectoriser pour ne pas avoir de problème de police-s manquante-s.



*********


Un caractère d'une police est un élément vectoriel... comme tout élément vectoriel, sa forme et sa définition est indépendante de la résolution du périphérique de sortie...

... sauf que, quel que soit le périphérique de sortie, écran ou imprimante ou flasheuse, le vectoriel doit être finalement pixellisé à la résolution du périphérique de sortie :
- 72 ppi pour l'écran,
- 300 à 720 dpi pour une imprimante,
- (courament) 2400 ou 2540 dpi pour une flasheuse (1200 ou 1270 dpi pour du flashage "économique", souvent utilisée pour des docs sans image, contenant seulement du texte)

Or, si le vectoriel n'a pas vraiment de dimension, puisque son échelle peut être modifié à volonté, les pixels/points du périphérique de sortie eux ont une dimension (puisque le périphérique a une résolution, et je rappelle que la résolution n'est que l'expression de la taille des pixels de l'écran ou des points de l'imprimante/flasheuse), donc chaque caractère de la police sera traduit en un dessin de pixels à l'écran et de points sur la feuille de papier qui sort d'une imprimante ou sur le film qui sort de la flasheuse.

Et c'est là qu'est le problème : la conversion de la forme vectorielle en pixels/points ainsi que la position de cette forme dans l'écran et/ou dans la page sont des calculs mathématiques, et comme la plupart des calculs ils ne sont jamais entiers...

... alors que le pixel et le point sont des éléments entiers et indivisibles sur une grille fixe par rapport à l'écran et/ou à la page !

Donc, il est quasiment obligatoirement qu'à la fin des calculs les pixels/points de la forme théorique du caractère pixellisé ne se placeront pas exactement dans les cases de la grille de pixels/points du périphérique de sortie.

Par exemple : un "l" en Futura medium 12 pts est une petite barre qui mesure 0,381 mm de largeur...

• à 2540 dpi le point de flasheuse mesure 0,01 mm => donc théoriquement il faudrait 38,1 points pour dessiner la barre du "l" en largeur... la valeur n'est pas entière, il n'est pas possible d'avoir 1/10e de pixel, donc le système va probablement arrondir à 38 points !

• à 600 dpi le point de l'imprimante mesure 0,0423 mm => donc théoriquement il faudrait 9 points pour dessiner la barre du "l" en largeur... pas de problème !

• à 300 dpi le point de l'imprimante mesure 0,0846 mm => donc théoriquement il faudrait 4,5 points pour dessiner la barre du "l" en largeur... il va falloir arrondir à 4 ou à 5 !!!

• le pixel de l'écran à 72 ppi mesure 0,35277 mm => donc théoriquement il faudrait 1,08 pixel pour dessiner la barre du "l" en largeur...

(mais les écrans les plus récents ont des résolutions de l'ordre de plutôt 95-110 ppi : à 105 ppi le pixel de l'écran mesure 0,2419 mm => donc théoriquement il faudrait 1,575 points pour dessiner la barre du "l" en largeur.


Donc, ça ne tombe pas juste !!! mais ce n'est pas grave, c'est prévu :

• l'écran a un système d'anti-aliasing qui permet par l'allumage partiel des pixels des bords de simuler des fraction de pixels ! donc, pour faire 1,575 pixels, le système va faire :
- un pixel noir à 100% et un pixel gris à environ 50% (peut-être même 57,5% !),
- ou, selon la position du caractère sur l'écran, 1 pixel à 70% + 1 autre à 80%
- ou tout autre combinaison de 2 pixels donnant 1,575 selon la position du "l" sur la grille de pixels...
... et ces deux pixels accolés vont donner l'impression visuelle d'un pixel et demi.

• les fontes ont un système de "hints" (infos d'optimisation en français) qui va modifier légèrement la forme et la position du caractère pour l'adapter à la grille de points de l'imprimante/flasheuse tout en étant au plus proche de sa forme originale et de sa position demandée.



Mais après une vectorisation ces deux systèmes d'adaptation n'existent plus... donc :

• pas d'anti-aliasing à l'écran, et le système de l'écran arrondit comme il peut au pixel le plus proche... donc 1,575 pixels devient 2 pixels (peut-être même 1 ou 3 !), donnant l'impression d'un engraissement des caractères.
Mais si on zoome, on utilise plus de pixels pour représenter les caractères, et l'erreur devient moins importante par rapport à la taille de l'affichage et donc moins visible : par exemple, avec un zoom 16 fois, il faut 25,2 pixels et l'arrondi à 25 ou 26 pixels ne se voit plus.

• pas de "hints" donc, le caractère se place comme il peut sur la grille de points de l'imprimante/flasheuse... à 2540 dpi (résolution de flashage "normale") 38,1 points devient 38 et ça ne se voit pas...
... mais pour des corps plus petits, et/ou des résolutions plus basses, les déformations peuvent devenir importantes et visibles : à 600 dpi il faut 9 points (tout rond) d'imprimante pour un texte en corps 12 et exactement pareil pour du corps 6 pt à 1200 dpi (résolution de flashage "économique"), donc pas de problème si le "l" tombe exactement sur 9 points de la grille... mais si les 9 points sont à cheval sur la grille, ça finira arrondi à 8 ou 10 points...
Et plus le corps est petit et/ou la résolution basse, moins il faut de points pour le dessiner et plus il aura du mal à se placer dans la grille et plus il sera déformé.

Bien-sûr ce n'est que peu visible sur des caractères "baton" bien séparés, mais deux "l" côte-à-côte risquent de paraître plus gras, voire devenir presque confondus (surtout à l'écran, et c'est ce qui a été à l'origine du mythe de la vectorisation qui engraisse les caractères) et des caractères plus fins avec des déliés en arrondi de 2 ou 3 pixels seront encore plus déformés.

 

[jmlevy]

[…] mais j'imagine que des gens qui bossent plus que moi sur Indy auraient pu m'indiquer pourquoi ces filets dégagent, ça me parait pas normal.

Parce que le filet nest pas un élément de la police qui est vectorisée, mais un ajout fait par l'utilisateur.

Et si tu veux absolument conserver le filets lors de la vectorisation, il faut avoir recours à un aplatissement prédéfini des transparences dans lequel il faut demander la vectorisation des textes et des contours. Ensuite, s'il n'y a pas d'élément transparent sur la page, on en crée un (un bloc avec une opacité de 0,01 % par exemple), et on crée un PDF en choisissant l'aplatissement des transparences idoine…
Mais, effectivement, on ne peut pas vectoriser un filet ou un souligné dans un fichier InDesign natif.

 

[GraphiqueDesign]

Ouawww, quelle leçon !
Merci Claude

Ca n'arrive pas tous les jours mais quand c'est le cas, cela vaut le déplacement.
Ta réponse est valable pour au moins 20 questions que je me posais depuis des lustres.
Merci encore !

 

[magicPDF]

Waow !
Bravo Claude.

 

[Kosic]

Du grand Claude !
:king:

 

[ccciolll]

claude72, c'est peut-être parce que c'est le matin, mais je ne comprends pas complètement ton explication sur la différence entre typos normale et typo vectorisée.

Je partais en effet du principe qu'une typo étant du vecteur, une typo vectorisée est identique (même si je n'aime pas les typos vectorisées car on ne peux plus modifier le texte).

Et si elle est identique, elle devrait s'imprimer de la même façon dans les mêmes conditions.

Mais tu dis que non.

Je comprends très bien que le vecteur doit être recalculé en points pour l'impression ou l'affichage écran.

Pour les bords des textes (ou de n'importe quelle forme d'ailleurs) je sais bien qu'il met des pixels grisés (on le voit si on fait un zoom écran). Par contre, je n'imaginais pas qu'il traiterait ça différemment sur une typo que sur une forme identique. Mais la nécessité de lisibilité quand on dé-zoome peut expliquer qu'on traite différemment les typos que les autres forme. Ça demande peut-être plus de puissance à la machine de gérer ça donc elle le réserve aux textes. Je ne connaissais pas le sens du mot anti-aliasing et donc je devine maintenant que ça signifie traiter les typos un peu plus richement que les autres formes, et ça explique peut-être les anciennes typos qui avaient une version print et une version écran, je suppose que la version écran comportait un tableau du genre comment afficher telle lettre à telle dimension pour garantir sa lisibilité.
Bref.

Mais pour le print, là, je ne comprends pas la différence. Pourquoi le calcul serait différent si la forme est strictement la même ? Est-ce que les concepteur de typo mettent aussi des tableaux d'exceptions disant, genre, même si la forme te dit que le pixel devrait être comme-ci, moi je te dis qu'il faut le mettre comme ça pour garantir la lisibilité des petits caractères ?


EDIT : en fait tu l'as expliqué, c'est ce que tu appelles des Hints…
Donc c'était ma conclusion finale qui était juste.
Eh ben je ne connaissais pas ces 2 systèmes d'adaptation des typos, je croyais que c'était juste des formes vectorielles qui savaient où se placer les unes par rapport aux autres, mais rien de plus.
Ça explique peut-être aussi pourquoi les typos gratosses sont parfois surprenantes. Le développeurs pas très consciencieux se dira Développer des trucs invisibles à l'utilisateur lambda, pour quoi faire, allez hop, on passe cette étape.

RE EDIT : pour l'affichage écran optimisé, voici une illustration de ce que tu dis.
Un série de L bas-de-casse Myriad Pro dans illustrator.
En haut je les ai vectorisés, en bas non, puis je les affiche en tout petit sur l'écran.
Capture d'écran, ouverture de ladite capture dans PS, gros zoom et recapture d'écran (pour éviter le floutage avec les autres techniques et voir les pixels bien nets) :
résultat, en bas on a un truc assez régulier, en haut c'est le bordel. En haut, JE SUPPOSE, il est au plus proche de la VRAIE forme ; par contre en bas, il adapte pour améliorer la lisibilité et privilégier des pixels COMPLETS bien noirs quitte à être moins exactement à l'emplacement réel de la forme.
Et donc on pourra supposer que la même procédure a lieu pour l'impression (privilégier la lisibilité à l'exactitude).



Uploaded with ImageShack.us

 

[GraphiqueDesign]

Mince, vous êtes trop balèzes sur ce fofo, merci ccciolll !
Assez étonnant si la démonstration s'avérait exacte ...
Je vais la tenter de mon côté ...

 

[ccciolll]

Assez étonnant si la démonstration s'avérait exacte ...

Ah, j'ai rien pipeauté, je t'assure.

 

[claude72]

Je partais en effet du principe qu'une typo étant du vecteur, une typo vectorisée est identique.

Oui, absolument : si tu ouvres une police de caractères quelconque dans Fontographer, et que tu compares la forme de chaque caractère entre le caractère de la fonte dans sa fenêtre de Fontographer et le caractère vectorisé dans Illustrator :

Les caractères dans Fontographer :

Les mêmes caractères vectorisés dans Illustrator :

... on voit bien que la forme est exactement identique et les points de tangente et d'inflexion sont exactement les mêmes et aux mêmes endroits : ce qui veut donc dire que le dessin vectoriel du caractère vectorisé dans Illustrator est exactement le dessin vectoriel contenu dans le fichier de la fonte.

Et si elle est identique, elle devrait s'imprimer de la même façon dans les mêmes conditions.

Mais tu dis que non.

Non, parcequ'une fonte n'est pas un simple fichier vectoriel, mais c'est un fichier un peu particulier, avec des optimisations supplémentaires adaptées aux caractères, comme les "hints", de manière à pouvoir être imprimées automatiquement à des tailles très différentes.


(un peu le genre d'optimisation qu'un graphiste fait quand il décline manuellement un logo pour des tailles d'utilisation et/ou d'impression très différente)

Pour les bords des textes (ou de n'importe quelle forme d'ailleurs) je sais bien qu'il met des pixels grisés (on le voit si on fait un zoom écran).

Plus exactement, on le voit quand on fait un zoom sur une capture d'écran...

En théorie, il y a besoin de pixels gris que autour de la forme, donc au maximum 1 colonne de pixels gris sur chaque bord vertical et 1 rangée pour chaque bord horizontal suffisent pour anti-aliasser une forme noire.

Tu as fait tes captures d'écran dans le cas le plus extrême, c'est à dire l'affichage de la largeur de la barre avec 1 ou 2 pixels, donc il y a au maximum 2 colonnes de pixels gris...

... et si on fait la même capture grossie à partir d'un très fort zoom à l'écran, même si il y a moins besoin de l'anti-aliasing, voire plus du tout, il existe quand-même toujours...
... il n'y a toujours au maximum qu'une colonne de pixels gris sur le bord pour l'anti-aliasing, comme on le voit sur cette capture d'écran grossie d'un "l" en Myriad 12 pt vectorisé affiché à l'écran à 6400% : clair à gauche, foncé à droite, très foncé au-dessus...

Pour les bords des textes (ou de n'importe quelle forme d'ailleurs) je sais bien qu'il met des pixels grisés (on le voit si on fait un zoom écran). Par contre, je n'imaginais pas qu'il traiterait ça différemment sur une typo que sur une forme identique.

Eh bien si : en fait le système et/ou les logiciels traitent différemment les typos et les autres formes...

... d'ailleurs, il suffit de regarder (par exemple) dans les préférences d'Acrobat, où il y a 3 options de lissage possibles de façon indépendante :
- le lissage des textes,
- le lissage des éléments vectoriels,
- et le lissage des images...
... ce qui prouve que tous ces éléments sont distingués par le système et/ou les logiciels et, surtout, sont traités différemment !

Et donc :
- quand le texte est non-vectorisé il est considéré par le système comme du texte et il est lissé comme du texte,
- alors que quand il est vectorisé, ce n'est plus du texte, donc ça devient une suite d'éléments vectoriels quelconque et donc ce "texte-qui-n'en-est-pas" est lissé comme sont lissés n'importequels éléments vectoriels lambda.


Et donc, en fait, quand je dis que les fontes vectorisées perdent l'anti-aliasing, c'est un raccourci un peu rapide, car en réalité elles perdent l'anti-aliasing spécifique au texte pour n'être plus anti-aliasées que comme des éléments vectoriels simples, un peu moins finement (ou un peu plus sommairement !!!).

Ça demande peut-être plus de puissance à la machine de gérer ça donc elle le réserve aux textes.

Là, franchement, tu dépasses mon domaine de compétence... désolé...

Mais logiquement ça doit être quelque chose comme ça : les fontes demandent un lissage plus efficace pour avoir la meilleure lisibilité possible, et donc elles ont certainement droit à un "traitement de faveur", qui doit probablement demander plus de puissance...

Ça paraît logique, mais je n'ai pas d'infos plus précises sur ce sujet.

Je ne connaissais pas le sens du mot anti-aliasing et donc je devine maintenant que ça signifie traiter les typos un peu plus richement que les autres formes...

Non, non : anti-aliasing = lissage ! à ma connaissance, ce sont simplement 2 synonymes
( = anti-crénelage)

... et ça explique peut-être les anciennes typos qui avaient une version print et une version écran...[/I]

Non, rien à voir ! Sur le Mac, c'est beaucoup plus simple que ça :

A) d'abord, les fontes étaient toutes matricielles... et l'affichage et l'impression se faisaient point-à-point, c'est à dire que chaque point de la fonte noir ou blanc était reproduit à l'identique sur le périphérique de sortie, à savoir :
- un point de la fonte pour un pixel d'écran à l'affichage
- et un point de la fonte pour un point de l'imprimante à l'impression...

• dans un 1er temps l'imprimante était une matricielle à aiguille (l'ImageWriter) qui imprimait avec la même résolution que l'écran (72dpi) donc l'imprimante imprimait la même chose que ce qui était affiché à l'écran...

... en clair, elle recopiait simplement l'écran, pixel par pixel !!!

(ça, c'était le vrai WYSIWYG !!!... et d'ailleurs je me souviens avoir vu un jour une impression étonnante : c'était un MacPlus connecté à une ImageWriter, et à chaque passage elle imprimait le bas d'une ligne et le haut de la ligne suivante ! c'était assez marrant à voir !!!)

• ensuite est apparue la LaserWriter, à 300 dpi... et comme l'impression se faisait à 300 dpi pour un affichage écran à 72 ppi, c'est à dire un ratio de 4 (environ), en fait les deux utilisaient des fichiers matriciels de polices identiques mais de corps différents... quand on affichait du 12 points à l'écran, l'imprimante avait besoin de 48 points pour l'impression !
Et donc pour chaque corps il fallait avoir deux fichiers matriciels de la même police, un du corps X pour l'écran et un du corps 4X pour l'impression...
... et si on n'avait que le corps 24 et pas le corps 96, alors on pouvait afficher du 24 points à l'écran, mais il était impossible de l'imprimer !!!


B) Ensuite sont apparues les fontes vectorielles !!! composées de :

• la partie "écran" (aussi appelée police bitmap) qui reste matricielle, pour être affichée directement par l'écran, de point à pixel... et donc il fallait encore avoir un fichier écran par corps utilisé !!!

• et la partie "Imprimante", vectorielle (aussi appelée police PostScript ou police de contour), qui comme tout machin vectoriel peut s'imprimer à n'importequelle taille et n'importequelle résolution, donc aussi bien sur une LaserWriter à 300 dpi que sur une flasheuse à 2400 dpi.
Et comme l'impression est possible à n'importe quelle taille et n'importequelle résolution, alors c'est cette partie qui contient les hints pour adapter la forme des caractères à la taille et la résolution.

, je suppose que la version écran comportait un tableau du genre comment afficher telle lettre à telle dimension pour garantir sa lisibilité.

Oh non, c'était bien plus simple : la partie écran est simplement matricielle et s'affiche de point à pixel : chaque point de la fonte est recopié tel-quel (blanc ou noir) sur l'écran.

Et ce n'est que quand ATM est apparu qu'il a été possible de faire l'affichage écran à partir d'un corps de la partie "écran" en utilisant la forme vectorielle de la partie "imprimante" pour recalculer la partie "écran" des autres corps.

Mais pour le print, là, je ne comprends pas la différence. Pourquoi le calcul serait différent si la forme est strictement la même ? Est-ce que les concepteur de typo mettent aussi des tableaux d'exceptions disant, genre, même si la forme te dit que le pixel devrait être comme-ci, moi je te dis qu'il faut le mettre comme ça pour garantir la lisibilité des petits caractères ?


EDIT : en fait tu l'as expliqué, c'est ce que tu appelles des Hints…
Donc c'était ma conclusion finale qui était juste.

Oui.

(c'est bien : tu te réponds à toi-même, et tu te réponds correctement ! bravo )

Ça explique peut-être aussi pourquoi les typos gratosses sont parfois surprenantes. Le développeurs pas très consciencieux se dira Développer des trucs invisibles à l'utilisateur lambda, pour quoi faire, allez hop, on passe cette étape.

Oui !!!

RE EDIT : pour l'affichage écran optimisé, voici une illustration de ce que tu dis.
Un série de L bas-de-casse Myriad Pro dans illustrator.
En haut je les ai vectorisés, en bas non, puis je les affiche en tout petit sur l'écran.
Capture d'écran, ouverture de ladite capture dans PS, gros zoom et recapture d'écran (pour éviter le floutage avec les autres techniques et voir les pixels bien nets) :
résultat, en bas on a un truc assez régulier, en haut c'est le bordel. En haut, JE SUPPOSE, il est au plus proche de la VRAIE forme ; par contre en bas, il adapte pour améliorer la lisibilité et privilégier des pixels COMPLETS bien noirs quitte à être moins exactement à l'emplacement réel de la forme.

Ton illustration est parfaite, et ton interprétation est presque bonne...

... en fait, plus simplement :

• en haut les caractères sont devenus des formes vectorielles, et ces formes vectorielles sont lissées comme des formes vectorielles... c'est à dire au plus près (peut-être même un peu sommairement ???)

• en bas c'est du texte, qui est donc lissé/optimisé comme du texte, un peu plus soigneusement, de manière à conserver au mieux la lisibilité.


***********


(Images uploadées avec ImageShack.us... merci à ccciolll !!!)



Edit :

Ah, j'ai rien pipeauté, je t'assure.

Je confirme, ces captures d'écran sont parfaitement conformes à la théorie.