Discussion :

[lvr]

Edit ; split de discussion

Quel est le problème avec Gimp ? Les fonctionnalités de base permettent déjà de faire pas mal de choses (...)Et il y a également des softs tout à fait utilisables pour le dessin (...)

Un pro ne se contente pas de soft qui font "pas mal de chose", qui sont "utilisable", ... Il veut des softs pro.
Pour GIMP: le support CYMK est très partiel. Si tu fais du print (pas du print laser), tu **dois** bosser en CYMK. Si tu envoies du RGB à ton imprimeur, tes bons-à-tirer vont avoir une drôle de tête

T'as raison pour Bitwig, très bon soft. Pour du live, Linux t'imposera Bitwig, alors MacOS et Windows te permettent Bitwig et Ableton Live + Max for Live qui sont des tueries.

etc...

Je ne dis pas qu'il n'y a pas de solutions sous Linux, je dis qu'il y en a moins et donc au final, c'est ta platforme qui va t'imposer comment travailler et pas toi qui va choisir comment travailler.

Une limitation de Linux, c'est l'approche OpenSource, Community-built de beaucoup de software. En community-built, et à moins d'avoir une grosse communauté derrière soi - comme LibreOffice, Blender, ... - une compagnie commerciale aura, je pense, souvent plus de moyens et de volonter pour faire évoluer ses softs. Les softs seront aussi plus péreine (y a une manne financière à faire vivre).

Combien de bons petits softs OO n'ont pas survécu à leur créateur, à l'énergie qu'il avait à y mettre ?

Un pro (qui peut se permettre de payer des licenses de Adobe CC) ne veut pas changer de workflow tous les 2 ans, pcq tel soft n'est plus supporté son créateur ou sa communauté.

Le jour où plus de compagnies commerciales développeront pour Linux (et c'est mon voeu), alors ça pourrait changer. Mais va-t-on vraiment dans cette direction ?

[Jipété]

Pour GIMP: le support CMYK est très partiel. Si tu fais du print (pas du print laser), tu **dois** bosser en CMYK.

Ce que j'ai fait fin 2013 sans aucun problème.

Faut dire aussi que l'article date de 2006, avec une petite mise à jour concernant ce sujet en 2012...

[loulnux]

Un pro ne se contente pas de soft qui font "pas mal de chose", qui sont "utilisable", ... Il veut des softs pro.
Pour GIMP: le support CYMK est très partiel. Si tu fais du print (pas du print laser), tu **dois** bosser en CYMK. Si tu envoies du RGB à ton imprimeur, tes bons-à-tirer vont avoir une drôle de tête

L'imprimeur auquel tu fais référence a besoin d'une sérieuse mise à jour de sa chaîne de production ou tout simplement de quelques éclaircissements de la part de ses fournisseurs de RIP car ça fait plus de 15 ans que les interpréteurs postscript intègrent des courbes de correction pour les images RVB.
Il faut tout de même comprendre l'historique de l'utilisation du CMJN en amont du flashage pour savoir pourquoi ce mythe perdure tout comme celui des images en 300ppp que jamais personne n'a su respecter ni compris comment ça devait fonctionner. Aujourd'hui avec 95% des sources produites en RVB comment peut-on imaginer qu'on soit obligé de transiter par le CMJN et de produire des fichiers en CMJN pour obtenir une impression correcte? Travailler une image RVB en vue subjective CMJN est en soi une aberration.
Le seul souci d'un imprimeur correctement équipé, aujourd'hui c'est de travailler ses courbes colorimétriques en fonction de la blancheur relative de son support d'impression et le problème est le même quelle que soit la technologie de reproduction (offset ou numérique direct).

[Jipété]

Désolé, mais je ne voudrais pas mourir idiot :

[...] Le seul souci d'un imprimeur correctement équipé, aujourd'hui c'est de travailler ses courbes colorimétriques en fonction de la blancheur relative de son support d'impression et le problème est le même quelle que soit la technologie de reproduction (offset ou numérique direct).

À quoi servent alors tous ces profils qu'on peut incorporer à 'toshop ou The Gimp (pour n'en citer que deux), profils parfois fournis par l'imprimeur (ou tout au moins indiqués par) ?

Just curious, merci de ta réponse.

[loulnux]

A faire vivre Adobe.

Aujourd'hui effectivement les courbes ICC sont une nécessité pour permettre d'avoir une référence de calibration interne à la station de travail mais le mode de travail CMJN tel que le propose Adobe n'est pas une nécessité absolue, c'est juste une vaine tentative de simulation CMJN dans l'espace colorimétrique RVB (chose quasi impossible puisqu'il faut simuler de la quadri soustractive dans un espace additif trichro ) alors que la plupart du temps la base objective RVB est réelle puisque c'est elle qui a servi de la prise de vue aux opérations de correction.
En d'autres termes pourquoi simuler très mal en amont des documents créés, travaillés et modifiés en RVB et surtout prévisualisés en RVB, dont la production CMJN n'est que la finalité? Finalité locale sur ton imprimante (qui fait elle même le travail de séparation RVB>CMJN grâce au profile ICC) et finalité chez l'imprimeur.
Comme en "print" seul le résultat CMJN est à prendre en compte, il est plus important de travailler avec une imprimante correctement calibrée en local (qui donnera un résultat général satisfaisant en terme d'épreuve) et de fournir cette épreuve à respecter à l'imprimeur.

Adobe créateur, entre autres, du postscript a voulu au départ simuler ce flow car à l'origine les scanners rotatifs sortaient directement des films CMJN mais à l'époque on montait les films tramés et la typo à la main à l'aveugle et il fallait que le photograveur sorte un chromalin (ou autre) pour soumettre une épreuve (souvent flatteuse) en guise de BAT charge à lui de tenter de s'en approcher lors du tirage définitif. Et Adobe devenu standard de fait a continué a entretenir ses utilisateurs dans cette illusion ce qui arrange bien souvent les imprimeurs qui n'hésitent pas à utiliser cet argument pour couvrir leur incompétence.

Aujourd'hui un imprimeur qui se respecte doit avoir un RIP central souvent Ghostscript (libre) genre GMG Color server qui analyse le contenu des fichiers (RVB et/ou CMJN) à imprimer et applique la courbe nécessaire à chaque canal couleur en fonction des caractéristiques du support final et évidemment du personnel compétant.

Pourquoi crois-tu que l'équipe de Gimp rechigne à participer au mythe?

[lvr]

Pourquoi crois-tu que l'équipe de Gimp rechigne à participer au mythe?

Je te crois volontiers. Mais cela ne change rien au problème de fond : travailler avec Linux te réduit le champ des possibles dans certains domaines.
En simplifiant, si je veux travailler avec Linux et Gimp, je vais devoir abandonner mon imprimeur pour un imprimeur dont le worklfow est plus moderne. Alors que si je travaille avec Windows ou Mac, je peux garder mon imprimeur actuel.
Question : qu'est ce que je gagne (si je peux me payer les licenses Windows/Mac, Adobe/Core) à passer sur Linux ?
Si tu travailles en vectoriel, tu es plutôt Adoble Illustrator, Corel Draw, Inkscape ? Les 3 ont leurs atouts. Tu peux même alterner en fonction du besoin du moment. Sur Windows, tu as le choix. Les 3 sont dispo. Sur Linux, juste Inkscape. De nouveau, Linux te réduit le champ de possibles...

[loulnux]

J'avoue avoir toujours eu une préférence nette pour Corel qui depuis très longtemps fait beaucoup mieux que Illustrator ou FreeHand depuis et qui m'a justement permis de comprendre à l'époque l'intérêt de l'utilisation des profiles ICC et tout le boulot de l'imposition prépresse puisque tout y est intégré (débords ou retraits, trames et séparation). Si ça tombe ton imprimeur dispose de tous les outils sauf des compétences, puisque tu parles de ça fût un temps j'en ai croisé un qui ne travaillait qu'avec des bitmaps "aplatis" dans un .pdf avec repères, en fait lui il allait à la chasse et son opératrice fraîche émoulue de stage était tombée sur un formateur bidon qui lui avait expliqué que c'était la parade à tout problèmes; c'est sûr que c'est efficace.
Ce n'est pas pour rien que j'ai déjà entendu l'expression "c.. comme un imprimeur" et à l'époque je peux te dire que j'étais concerné au plus haut point puisque je m'occupais d'un studio pré-presse d'une boîte de sérigraphie grand format.
En fait ce que tu vas gagner, c'est le prix des licences, la stabilité et la rapidité de ton système; d'ailleurs on peut aussi faire des merveilles avec Scribus très proche de Quark en terme d'utilisation mais sans les limites (ce qui permet de créer un doc de n'importe quelle taille à échelle 1 et évite toute erreur de conversion) et qui a le bon goût d'importer de nombreux formats de fichiers.
Ce que tu gagnes aussi c'est le droit d'inverser les principes d'échanges : dans la logique ça ne devrait pas être à toi de te plier aux exigences de ton sous-traitant mais l'inverse.

[Jipété]

[...] d'ailleurs on peut aussi faire des merveilles avec Scribus très proche de Quark en terme d'utilisation mais sans les limites (ce qui permet de créer un doc de n'importe quelle taille à échelle 1 et évite toute erreur de conversion) et qui a le bon goût d'importer de nombreux formats de fichiers.

Sauf pour les tableaux, à moins que ça ait (beaucoup !) évolué depuis mes tests avec la version 1.4.0.

[loulnux]

Sauf pour les tableaux, à moins que ça ait (beaucoup !) évolué depuis mes tests avec la version 1.4.0.

Quels tableaux? Issus de quoi et intégrés comment?

[Jipété]

Quels tableaux ? Issus de quoi et intégrés comment ?

Des tableaux genre tableur, pour présenter des données en lignes et en colonnes.
Issus du besoin de présenter des données en lignes et en colonnes.
Intégrés absolument pas comme avec Publisher (où il suffit de sélectionner "tableau" dans la liste des objets disponibles et de dessiner son espace sur la feuille, exactement comme on dessine un cadre de texte. Et plus qu'à le remplir avec les données.)

Sous Scribus j'ai le souvenir (4 ans, ça date) d'avoir abandonné après y avoir passé beaucoup (trop) de temps ; et à l'époque je n'étais pas le seul à m'en plaindre.

[loulnux]

Des tableaux genre tableur, pour présenter des données en lignes et en colonnes.
Issus du besoin de présenter des données en lignes et en colonnes.
Intégrés absolument pas comme avec Publisher (où il suffit de sélectionner "tableau" dans la liste des objets disponibles et de dessiner son espace sur la feuille, exactement comme on dessine un cadre de texte. Et plus qu'à le remplir avec les données.)

Sous Scribus j'ai le souvenir (4 ans, ça date) d'avoir abandonné après y avoir passé beaucoup (trop) de temps ; et à l'époque je n'étais pas le seul à m'en plaindre.

Il ne faut pas confondre les torchons et les serviettes :
Publisher n'a jamais été un logiciel sérieux de PAO pour la simple raison que bien qu'intégré au point d'utiliser les fonctionnalités OLE de windows et de mimer certaines fonctionnalités des autres produits de chez microsoft les documents produits au fil des versions années après années deviennent incompatibles avec les versions plus récentes; bref c'est un gadget qui donne une vague idée de ce qu'est la PAO.
Les logiciels de PAO en général permettent de générer des documents composites de sources issues d'applications diverses et variées pourvu qu'un filtre d'importation ait été prévu pour se faire (Tiff, Jpeg, Pdf, doc, ....) en général les documents genre "tableaux" sont générés par une appli genre exel ou libreoffice, exportés en PDF puis importés pour leurs mise en page parmi d'autres sources texte, bitmap,vecteurs....
Attendre de Scribus de faire des tableaux serait comme demander à word de générer des photos ou à excel de faire de la musique. Et surtout ce n'est pas (sauf en interne et pour le texte) fait pour exploiter des objets copiés dans d'autres applications et collé à la va comme je te pousse dans un coin pour faire genre.
Voilà désolé mais avant d'attendre certains prodiges de logiciels il faut comprendre leur utilité.

[chrtophe]

Je reste curieux de savoir si Scribus est apte à remplacer inDesign en usage professionnel avec fourniture d'un fichier exploitable par un imprimeur en respectant les normes typographiques, colorimétriques, etc. Si un infographiste l'a déjà vu en production dans le monde de la PAO, le feedback m’intéresse.

[Jipété]

Salut,

Il ne faut pas confondre les torchons et les serviettes :
[--snip--]
Attendre de Scribus de faire des tableaux serait comme demander à word de générer des photos ou à excel de faire de la musique.

Je ne confonds rien du tout, j'utilise le bon outil au bon moment, genre pour dévisser une vis cruci je sais que je peux y arriver avec un tournevis plat, avec la pointe d'un couteau des fois, mais le mieux c'est encore le tournevis cruci.

Un exemple valant mieux qu'un long discours, admettons que j'aie besoin de faire un topo sur les espaces de couleurs, où l'on utilise beaucoup les matrices. 13 minutes montre en main de la page blanche de Publisher à la copie d'écran pour ici, et encore il m'a fallu chercher les infos à utiliser :

Ne tenez pas compte de l'effet d'escalier dans les polices, j'avais mal paramétré le Windows de la machine virtuelle utilisée comme atelier d'imprimerie, , et de toute façon ça n'impacte que l'affichage, pas l'impression, pi bon, c'est corrigé .

Annoncez vos chiffres...

[loulnux]

Je reste curieux de savoir si Scribus est apte à remplacer inDesign en usage professionnel avec fourniture d'un fichier exploitable par un imprimeur en respectant les normes typographiques, colorimétriques, etc. Si un infographiste l'a déjà vu en production dans le monde de la PAO, le feedback m’intéresse.

Scribus est concurrent de Qwark pour son usage et sa présentation et est effectivement exploitable en labeur pro, (le Brésil en a fait son logiciel de prédilection depuis des années); le seul logiciel comparable à Indesign dans ses fonctionnalités c'est Corel Draw qui fait à mon humble avis mieux depuis longtemps.

Salut,

Je ne confonds rien du tout, j'utilise le bon outil au bon moment, genre pour dévisser une vis cruci je sais que je peux y arriver avec un tournevis plat, avec la pointe d'un couteau des fois, mais le mieux c'est encore le tournevis cruci.

Un exemple valant mieux qu'un long discours, admettons que j'aie besoin de faire un topo sur les espaces de couleurs, où l'on utilise beaucoup les matrices. 13 minutes montre en main de la page blanche de Publisher à la copie d'écran pour ici, et encore il m'a fallu chercher les infos à utiliser :

Ne tenez pas compte de l'effet d'escalier dans les polices, j'avais mal paramétré le Windows de la machine virtuelle utilisée comme atelier d'imprimerie, , et de toute façon ça n'impacte que l'affichage, pas l'impression, pi bon, c'est corrigé .

Annoncez vos chiffres...

La réponse est dans ta démo.

[Jipété]

Bonjour,

(oui, je sais, ça date de plus de 3 ans -- et alors ?)

Je relis cette discussion et je tombe sur ce petit bout, qui me laisse sur ma faim, question compréhension :

[…] ce mythe […] des images en 300ppp que jamais personne n'a su respecter ni compris comment ça devait fonctionner.

C'est quoi dont tu parles, là ?
Deux lignes d'explications seraient les bienvenues, merci.

[loulnux]

Tu as de la chance que je ne sois pas mort.
Et ce sera l'unique et ultime réponse que tu obtiendras sur ce fil.
300ppp c'est la valeur de résolution d'image déterminée par le labeur pour insérer les bitmaps dans les documents.
Sauf que cette valeur manque de précision dans la mesure ou c'est à échelle 1 du document imprimé et pour une linéature de trame stochastiques de 133lpi (trame moyenne de la presse offset couleur).
Je dis que c'est un mythe parce qu'en général avec Qwark l'image originale n'était pas "embarquée" mais simulée et elle pouvait être recadrée agrandie ou réduite tout en laissant l'original intact.
Or en toute bonne foi un maquettiste pouvait scanner un timbre poste en 300ppp à échelle 1 de l'original pour en faire une première de couve tabloïd en adaptant sa taille dans Quark ou l'inverse et dans les deux cas le compte n'y est pas et le résultat peut-être catastrophique d'autant qu'une fois préparé pour la presse son client décide de sortir son bout d'édition pour en faire des affiches 4x3 (autre type d'impression autre linéature).
Bref l'arrivée tardive des trames aléatoires a permis d' "estomper" sans les corriger les erreurs grossières générées par cette valeur hasardeuse. et plus que moyenne tout dépend de la manière dont elle était interprétée ou entendue.
300ppp, CMYK et étalonnage d'écrans sont les trois mamelles des arnaques de la chaîne graphique PAO
Voilà comme tu l'as compris je ne donnerai pas suite à d'éventuelles autres questions sauf peut être dans trois ans quand j'aurai totalement oublié ce fil de discussion.