En gros il n'y a que la résolution.
Oui, mais c'est énorme.
Bin non, justement.
> Créer une image à 400dpi pour l'imprimante, cen'est pas tout à fait la même chose que de créer une image à 72dpi
pour l'écran, ni en termes de ressources, ni en termes de temps de
temps de calcul.
Le code Display PostScript a été optimisé pour le 680x0pour avoir un
affichage fluide et une impression rapide.
Je ne pense quand même pas qu'une image imprimante était précalculée
pour tout document affiché à l'écran, donc il fallait calculer l'image
imprimante à la demande, comme d'habitude quoi.
Oui, bien sûr, mais la vitesse des NeXTstations ou NeXTcubes fait toute
la différence.
Je ne sais pas si le fait que ce soit le même code ou pas a vraiment
de l'importance. A un moment il faut calculer l'image pour
l'imprimante et c'est ça qui coûte.
Le problème avec Mac OS et Windows est que le code à générer pour
l'imprimante est différent du code affiché, et donc beaucoup de bugs,
beaucoup de problèmes et de sous-optimisation de cette partie par le
programmeur pour un code spécifique qui n'est que rarement utilisé (par
rapport à un affichage du type traitement de texte). Cela a entraîné
l'apparition de la prévisualisation de l'impression pour voir les bugs à
l'écran avant de les imprimer...
Un exemple du problème de transcodage sous d'autres systèmes : je me
rappelle d'une page affichant des graduations en tout sens, de plus en
plus petit, pour tester la finesse du rendu des lignes et des dégradés.
Sur l'écran, la résolution de base est de 72 dpi, mais on peut zoomer
dans la fenêtre DIsplay PostScript et l'affichage de la page s'affine de
plus en plus, et cela sans changer de code. Mais le plus intéressant est
que le code PostScript est un véritable programme, avec boucle et
décision, et pas juste une suite d'instructions de traçage comme c'est
le cas en utilisant un transcodage type Mac OS ou Windows. Et là aussi
utiliser toutes les finesses du langage au lieu d'appeler de grosses
macros de dessin (compatible PCL), cela joue énormément.
En gros il n'y a que la résolution.
Oui, mais c'est énorme.
Bin non, justement.
> Créer une image à 400dpi pour l'imprimante, ce
n'est pas tout à fait la même chose que de créer une image à 72dpi
pour l'écran, ni en termes de ressources, ni en termes de temps de
temps de calcul.
Le code Display PostScript a été optimisé pour le 680x0pour avoir un
affichage fluide et une impression rapide.
Je ne pense quand même pas qu'une image imprimante était précalculée
pour tout document affiché à l'écran, donc il fallait calculer l'image
imprimante à la demande, comme d'habitude quoi.
Oui, bien sûr, mais la vitesse des NeXTstations ou NeXTcubes fait toute
la différence.
Je ne sais pas si le fait que ce soit le même code ou pas a vraiment
de l'importance. A un moment il faut calculer l'image pour
l'imprimante et c'est ça qui coûte.
Le problème avec Mac OS et Windows est que le code à générer pour
l'imprimante est différent du code affiché, et donc beaucoup de bugs,
beaucoup de problèmes et de sous-optimisation de cette partie par le
programmeur pour un code spécifique qui n'est que rarement utilisé (par
rapport à un affichage du type traitement de texte). Cela a entraîné
l'apparition de la prévisualisation de l'impression pour voir les bugs à
l'écran avant de les imprimer...
Un exemple du problème de transcodage sous d'autres systèmes : je me
rappelle d'une page affichant des graduations en tout sens, de plus en
plus petit, pour tester la finesse du rendu des lignes et des dégradés.
Sur l'écran, la résolution de base est de 72 dpi, mais on peut zoomer
dans la fenêtre DIsplay PostScript et l'affichage de la page s'affine de
plus en plus, et cela sans changer de code. Mais le plus intéressant est
que le code PostScript est un véritable programme, avec boucle et
décision, et pas juste une suite d'instructions de traçage comme c'est
le cas en utilisant un transcodage type Mac OS ou Windows. Et là aussi
utiliser toutes les finesses du langage au lieu d'appeler de grosses
macros de dessin (compatible PCL), cela joue énormément.
En gros il n'y a que la résolution.
Oui, mais c'est énorme.
Bin non, justement.
> Créer une image à 400dpi pour l'imprimante, cen'est pas tout à fait la même chose que de créer une image à 72dpi
pour l'écran, ni en termes de ressources, ni en termes de temps de
temps de calcul.
Le code Display PostScript a été optimisé pour le 680x0pour avoir un
affichage fluide et une impression rapide.
Je ne pense quand même pas qu'une image imprimante était précalculée
pour tout document affiché à l'écran, donc il fallait calculer l'image
imprimante à la demande, comme d'habitude quoi.
Oui, bien sûr, mais la vitesse des NeXTstations ou NeXTcubes fait toute
la différence.
Je ne sais pas si le fait que ce soit le même code ou pas a vraiment
de l'importance. A un moment il faut calculer l'image pour
l'imprimante et c'est ça qui coûte.
Le problème avec Mac OS et Windows est que le code à générer pour
l'imprimante est différent du code affiché, et donc beaucoup de bugs,
beaucoup de problèmes et de sous-optimisation de cette partie par le
programmeur pour un code spécifique qui n'est que rarement utilisé (par
rapport à un affichage du type traitement de texte). Cela a entraîné
l'apparition de la prévisualisation de l'impression pour voir les bugs à
l'écran avant de les imprimer...
Un exemple du problème de transcodage sous d'autres systèmes : je me
rappelle d'une page affichant des graduations en tout sens, de plus en
plus petit, pour tester la finesse du rendu des lignes et des dégradés.
Sur l'écran, la résolution de base est de 72 dpi, mais on peut zoomer
dans la fenêtre DIsplay PostScript et l'affichage de la page s'affine de
plus en plus, et cela sans changer de code. Mais le plus intéressant est
que le code PostScript est un véritable programme, avec boucle et
décision, et pas juste une suite d'instructions de traçage comme c'est
le cas en utilisant un transcodage type Mac OS ou Windows. Et là aussi
utiliser toutes les finesses du langage au lieu d'appeler de grosses
macros de dessin (compatible PCL), cela joue énormément.
Le 18/11/11 18:35, Éric Lévénez a écrit :
>>>
>>> En gros il n'y a que la résolution.
>>
>> Oui, mais c'est énorme.
>
> Bin non, justement.
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Le 18/11/11 18:35, Éric Lévénez a écrit :
>>>
>>> En gros il n'y a que la résolution.
>>
>> Oui, mais c'est énorme.
>
> Bin non, justement.
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Le 18/11/11 18:35, Éric Lévénez a écrit :
>>>
>>> En gros il n'y a que la résolution.
>>
>> Oui, mais c'est énorme.
>
> Bin non, justement.
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
pehache wrote:Le 18/11/11 18:35, Éric Lévénez a écrit :
En gros il n'y a que la résolution.
Oui, mais c'est énorme.
Bin non, justement.
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
C'est pas vectoriel, le Postscript ?
pehache<pehache.7@gmail.com> wrote:
Le 18/11/11 18:35, Éric Lévénez a écrit :
En gros il n'y a que la résolution.
Oui, mais c'est énorme.
Bin non, justement.
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
C'est pas vectoriel, le Postscript ?
pehache wrote:Le 18/11/11 18:35, Éric Lévénez a écrit :
En gros il n'y a que la résolution.
Oui, mais c'est énorme.
Bin non, justement.
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
C'est pas vectoriel, le Postscript ?
Le 18/11/11 18:35, Éric Lévénez a écrit :
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Et je suppose qu'on fait moins de compromis pour une impression que pour
un affichage écran, en plus. Sans compter qu'à l'écran la carte
graphique est impliquée.
Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.
Oui, bien sûr, mais la vitesse des NeXTstations ou NeXTcubes fait toute
la différence.
D'accord. Donc ça reposait sur la puissance de la station.
Je ne dis pas le contraire. Néanmoins, il fallait bien recalculer
l'image pour l'impression à un moment ou à un autre.
Je suis d'accord que pour plein de raisons, avoir la même librairie
graphique pour l'écran et l'impression peut avoir certains avantages. De
là à dire que c'est pour ça que l'impression était rapide, j'ai un
doute.
Vu comme il est répandu, je pense qu'un truc comme PCL est quand
même optimisé aussi.
Le 18/11/11 18:35, Éric Lévénez a écrit :
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Et je suppose qu'on fait moins de compromis pour une impression que pour
un affichage écran, en plus. Sans compter qu'à l'écran la carte
graphique est impliquée.
Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.
Oui, bien sûr, mais la vitesse des NeXTstations ou NeXTcubes fait toute
la différence.
D'accord. Donc ça reposait sur la puissance de la station.
Je ne dis pas le contraire. Néanmoins, il fallait bien recalculer
l'image pour l'impression à un moment ou à un autre.
Je suis d'accord que pour plein de raisons, avoir la même librairie
graphique pour l'écran et l'impression peut avoir certains avantages. De
là à dire que c'est pour ça que l'impression était rapide, j'ai un
doute.
Vu comme il est répandu, je pense qu'un truc comme PCL est quand
même optimisé aussi.
Le 18/11/11 18:35, Éric Lévénez a écrit :
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Et je suppose qu'on fait moins de compromis pour une impression que pour
un affichage écran, en plus. Sans compter qu'à l'écran la carte
graphique est impliquée.
Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.
Oui, bien sûr, mais la vitesse des NeXTstations ou NeXTcubes fait toute
la différence.
D'accord. Donc ça reposait sur la puissance de la station.
Je ne dis pas le contraire. Néanmoins, il fallait bien recalculer
l'image pour l'impression à un moment ou à un autre.
Je suis d'accord que pour plein de raisons, avoir la même librairie
graphique pour l'écran et l'impression peut avoir certains avantages. De
là à dire que c'est pour ça que l'impression était rapide, j'ai un
doute.
Vu comme il est répandu, je pense qu'un truc comme PCL est quand
même optimisé aussi.
Le 19/11/11 12:46, pehache a écrit :Le 18/11/11 18:35, Éric Lévénez a écrit :Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Ce n'est pratiquement jamais le cas. En effet, pour une impression
typique (sur NeXTprinter par exemple), seules les pixels noirs sont
calculés, et donc c'est bien N fois plus de pixels, mais N est tout petit.
Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.
Les premiers NeXT étaient en 68030, mais la série était en 68040.
Je suis d'accord que pour plein de raisons, avoir la même librairie
graphique pour l'écran et l'impression peut avoir certains avantages. De
là à dire que c'est pour ça que l'impression était rapide, j'ai un
doute.
Il faut comprendre que PostScript est un langage informatique complet
optimisé pour la description de pages. Et quand on a bien assimilé cela
on a tout compris.
Display PostScript avait de nombreuses extensions, comme la possibilité
d'afficher des données avant la fin de la page (le showpage de
PostScript). Il y avait aussi la notion de transparence bien utile sur
écran. Display PostScript optimise aussi la gestion des fonts bitmaps,
bien utile pour la rapidité d'affichage.Vu comme il est répandu, je pense qu'un truc comme PCL est quand
même optimisé aussi.
PCL est une langage de description de pages, comme PDF.
Le 19/11/11 12:46, pehache a écrit :
Le 18/11/11 18:35, Éric Lévénez a écrit :
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Ce n'est pratiquement jamais le cas. En effet, pour une impression
typique (sur NeXTprinter par exemple), seules les pixels noirs sont
calculés, et donc c'est bien N fois plus de pixels, mais N est tout petit.
Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.
Les premiers NeXT étaient en 68030, mais la série était en 68040.
Je suis d'accord que pour plein de raisons, avoir la même librairie
graphique pour l'écran et l'impression peut avoir certains avantages. De
là à dire que c'est pour ça que l'impression était rapide, j'ai un
doute.
Il faut comprendre que PostScript est un langage informatique complet
optimisé pour la description de pages. Et quand on a bien assimilé cela
on a tout compris.
Display PostScript avait de nombreuses extensions, comme la possibilité
d'afficher des données avant la fin de la page (le showpage de
PostScript). Il y avait aussi la notion de transparence bien utile sur
écran. Display PostScript optimise aussi la gestion des fonts bitmaps,
bien utile pour la rapidité d'affichage.
Vu comme il est répandu, je pense qu'un truc comme PCL est quand
même optimisé aussi.
PCL est une langage de description de pages, comme PDF.
Le 19/11/11 12:46, pehache a écrit :Le 18/11/11 18:35, Éric Lévénez a écrit :Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Ce n'est pratiquement jamais le cas. En effet, pour une impression
typique (sur NeXTprinter par exemple), seules les pixels noirs sont
calculés, et donc c'est bien N fois plus de pixels, mais N est tout petit.
Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.
Les premiers NeXT étaient en 68030, mais la série était en 68040.
Je suis d'accord que pour plein de raisons, avoir la même librairie
graphique pour l'écran et l'impression peut avoir certains avantages. De
là à dire que c'est pour ça que l'impression était rapide, j'ai un
doute.
Il faut comprendre que PostScript est un langage informatique complet
optimisé pour la description de pages. Et quand on a bien assimilé cela
on a tout compris.
Display PostScript avait de nombreuses extensions, comme la possibilité
d'afficher des données avant la fin de la page (le showpage de
PostScript). Il y avait aussi la notion de transparence bien utile sur
écran. Display PostScript optimise aussi la gestion des fonts bitmaps,
bien utile pour la rapidité d'affichage.Vu comme il est répandu, je pense qu'un truc comme PCL est quand
même optimisé aussi.
PCL est une langage de description de pages, comme PDF.
Le 19/11/11 14:09, Éric Lévénez a écrit :Le 19/11/11 12:46, pehache a écrit :Le 18/11/11 18:35, Éric Lévénez a écrit :Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Ce n'est pratiquement jamais le cas. En effet, pour une impression
typique (sur NeXTprinter par exemple), seules les pixels noirs sont
calculés, et donc c'est bien N fois plus de pixels, mais N est tout
petit.
Je pense que tu fais erreur, là. Même en ne calculant que les pixels
noirs, ça en fait toujours 30 fois plus (environ) à 400dpi plutôt qu'à
72dpi.
Ce que tu veux dire j'imagine c'est que sur une page il y a des cas où
il n'y a pas forcément beaucoup d'éléments à calculer. Mais ça reste
vrai, que la rasterisation se fasse sur l'ordi avec DPS ou sur
l'imprimante avec PS ou PCL.
...et comme PS ou DPS. C'est juste que PS/DPS sont plus élaborés
(ce qui
n'est pas forcément un avantage dans toutes les situations, et c'est ce
qui a conduit Adobe à créer le PDF, en enlevant de PS par exemple les
sructures de programmation).
Pour en revenir au sujet, à savoir la rapidité d'impression, je suis à
peu près certain que la vitesse d'impression des NeXT ne tenait pas
spécialement à DPS, mais juste au fait que ça rasterisait sur la station.
D'ailleurs à matériel égal, je ne crois pas qu'une imprimante PS soit
notablement plus rapide qu'une imprimante PCL.
Le 19/11/11 14:09, Éric Lévénez a écrit :
Le 19/11/11 12:46, pehache a écrit :
Le 18/11/11 18:35, Éric Lévénez a écrit :
Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Ce n'est pratiquement jamais le cas. En effet, pour une impression
typique (sur NeXTprinter par exemple), seules les pixels noirs sont
calculés, et donc c'est bien N fois plus de pixels, mais N est tout
petit.
Je pense que tu fais erreur, là. Même en ne calculant que les pixels
noirs, ça en fait toujours 30 fois plus (environ) à 400dpi plutôt qu'à
72dpi.
Ce que tu veux dire j'imagine c'est que sur une page il y a des cas où
il n'y a pas forcément beaucoup d'éléments à calculer. Mais ça reste
vrai, que la rasterisation se fasse sur l'ordi avec DPS ou sur
l'imprimante avec PS ou PCL.
...et comme PS ou DPS. C'est juste que PS/DPS sont plus élaborés
(ce qui
n'est pas forcément un avantage dans toutes les situations, et c'est ce
qui a conduit Adobe à créer le PDF, en enlevant de PS par exemple les
sructures de programmation).
Pour en revenir au sujet, à savoir la rapidité d'impression, je suis à
peu près certain que la vitesse d'impression des NeXT ne tenait pas
spécialement à DPS, mais juste au fait que ça rasterisait sur la station.
D'ailleurs à matériel égal, je ne crois pas qu'une imprimante PS soit
notablement plus rapide qu'une imprimante PCL.
Le 19/11/11 14:09, Éric Lévénez a écrit :Le 19/11/11 12:46, pehache a écrit :Le 18/11/11 18:35, Éric Lévénez a écrit :Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
qu'une image à 72dpi
Ce n'est pratiquement jamais le cas. En effet, pour une impression
typique (sur NeXTprinter par exemple), seules les pixels noirs sont
calculés, et donc c'est bien N fois plus de pixels, mais N est tout
petit.
Je pense que tu fais erreur, là. Même en ne calculant que les pixels
noirs, ça en fait toujours 30 fois plus (environ) à 400dpi plutôt qu'à
72dpi.
Ce que tu veux dire j'imagine c'est que sur une page il y a des cas où
il n'y a pas forcément beaucoup d'éléments à calculer. Mais ça reste
vrai, que la rasterisation se fasse sur l'ordi avec DPS ou sur
l'imprimante avec PS ou PCL.
...et comme PS ou DPS. C'est juste que PS/DPS sont plus élaborés
(ce qui
n'est pas forcément un avantage dans toutes les situations, et c'est ce
qui a conduit Adobe à créer le PDF, en enlevant de PS par exemple les
sructures de programmation).
Pour en revenir au sujet, à savoir la rapidité d'impression, je suis à
peu près certain que la vitesse d'impression des NeXT ne tenait pas
spécialement à DPS, mais juste au fait que ça rasterisait sur la station.
D'ailleurs à matériel égal, je ne crois pas qu'une imprimante PS soit
notablement plus rapide qu'une imprimante PCL.
Le 19/11/11 13:08, SbM a écrit :
> pehache wrote:
>
>> Le 18/11/11 18:35, Éric Lévénez a écrit :
>>>>>
>>>>> En gros il n'y a que la résolution.
>>>>
>>>> Oui, mais c'est énorme.
>>>
>>> Bin non, justement.
>>
>> Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
>> qu'une image à 72dpi
>
> C'est pas vectoriel, le Postscript ?
>
Si, mais à un moment ou à un autre il faut convertir le code PS en une
image bitmap.
Le 19/11/11 13:08, SbM a écrit :
> pehache<pehache.7@gmail.com> wrote:
>
>> Le 18/11/11 18:35, Éric Lévénez a écrit :
>>>>>
>>>>> En gros il n'y a que la résolution.
>>>>
>>>> Oui, mais c'est énorme.
>>>
>>> Bin non, justement.
>>
>> Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
>> qu'une image à 72dpi
>
> C'est pas vectoriel, le Postscript ?
>
Si, mais à un moment ou à un autre il faut convertir le code PS en une
image bitmap.
Le 19/11/11 13:08, SbM a écrit :
> pehache wrote:
>
>> Le 18/11/11 18:35, Éric Lévénez a écrit :
>>>>>
>>>>> En gros il n'y a que la résolution.
>>>>
>>>> Oui, mais c'est énorme.
>>>
>>> Bin non, justement.
>>
>> Une image à 400dpi c'est quand même 30 fois plus de pixels à calculer
>> qu'une image à 72dpi
>
> C'est pas vectoriel, le Postscript ?
>
Si, mais à un moment ou à un autre il faut convertir le code PS en une
image bitmap.
Si, mais à un moment ou à un autre il faut convertir le code PS en une
image bitmap.
le "mais" ne peut en rien diminuer les mérites de ce système. Du moment
que c'est du vectoriel, l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont.
Tu dit dans un message précédent "Alors
tout reposais sur la puissance de la station". Vu la puissance des NeXT,
à base à l'époque de 68040 (alors que quasiment tous les concurrents
étaient encore au 68030, dans le meilleur des cas), ça aurait été quand
même crétin de chez couillon de ne pas exploiter cette débauche de
puissance disponible, et de foutre un processeur de m.... dans une
imprimante, alors qu'on avait la Rolls-Royce des procs de l'époque dans
la station et qui ne demandait qu'à bosser
Si, mais à un moment ou à un autre il faut convertir le code PS en une
image bitmap.
le "mais" ne peut en rien diminuer les mérites de ce système. Du moment
que c'est du vectoriel, l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont.
Tu dit dans un message précédent "Alors
tout reposais sur la puissance de la station". Vu la puissance des NeXT,
à base à l'époque de 68040 (alors que quasiment tous les concurrents
étaient encore au 68030, dans le meilleur des cas), ça aurait été quand
même crétin de chez couillon de ne pas exploiter cette débauche de
puissance disponible, et de foutre un processeur de m.... dans une
imprimante, alors qu'on avait la Rolls-Royce des procs de l'époque dans
la station et qui ne demandait qu'à bosser
Si, mais à un moment ou à un autre il faut convertir le code PS en une
image bitmap.
le "mais" ne peut en rien diminuer les mérites de ce système. Du moment
que c'est du vectoriel, l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont.
Tu dit dans un message précédent "Alors
tout reposais sur la puissance de la station". Vu la puissance des NeXT,
à base à l'époque de 68040 (alors que quasiment tous les concurrents
étaient encore au 68030, dans le meilleur des cas), ça aurait été quand
même crétin de chez couillon de ne pas exploiter cette débauche de
puissance disponible, et de foutre un processeur de m.... dans une
imprimante, alors qu'on avait la Rolls-Royce des procs de l'époque dans
la station et qui ne demandait qu'à bosser
l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont
l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont
l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont
On 20.11.11 00:45, Pierre-Olivier TAUBATY wrote:l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont
Ca j'en doute fortement! Avec une résolution différente, même de l'ordre
de quelques DPI, il faut *tout* refaire.
On 20.11.11 00:45, Pierre-Olivier TAUBATY wrote:
l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont
Ca j'en doute fortement! Avec une résolution différente, même de l'ordre
de quelques DPI, il faut *tout* refaire.
On 20.11.11 00:45, Pierre-Olivier TAUBATY wrote:l'important c'est que ça est été calculé une
fois (pour l'écran), après, c'est de l'adaptation, le plus gros du
travail a été fait en amont
Ca j'en doute fortement! Avec une résolution différente, même de l'ordre
de quelques DPI, il faut *tout* refaire.