J'ai placé sur <http://www.levenez.com/NeXTSTEP/#magazine> des scans de
magazines (SVM et MiC MAC) sur NeXT d'il y a 20 ans.
Fin 1990, au moment d'acheter une nouvelle machine en remplacement de
mon Atari ST, c'est grâce à MiC MAC que j'ai choisi de ne pas passer au
Mac (je prévoyais un IIsi qui venait de sortir) sous cet horrible
Système 6/7 (renommé Mac OS, mais ça ne trompais personne). J'ai alors
décidé d'acheter une NeXTstation. Puis c'est seulement quand Mac OS X
est sorti que j'ai acheté mon premier Mac.
Merci MiC MAC !
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le code de l'application qui sert à afficher à l'écran est le même que celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour l'écran, ça l'est aussi pour l'imprimante.
Wouaw! T'as l'air d'en connaitre un brin en technologie RIP. Enfin tu crois en connaitre un brin...
Et toi tu as beaucoup manipulé Display PostScript ?
AH je comprends! parceque tu sais comment rediriger un Postscript vers une imprimante, tu crois pouvoir écrire les âneries ci dessus?
Je comprends maintenant que tu ne sais pas ce qu'est Display PostScript et tu ne sais pas non plus comment marche la NeXTprinter.
Tu essayes d'adapter ce que tu comprends de la technologie NeXT avec ton petit monde.
J'aurais dû écouter tes conseils avertis avant de mettre une fortune dans mon RIP Fiery,
Tu fais ce que tu veux mon grand.
Et oui, Pierre-Olivier Taubaty a raison en parlant de la vitesse d'impression sous NeXTSTEP avec la NeXTprinter par rapport aux solutions disponibles à la même époque.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/11/11 21:02, Laszlo Lebrun a écrit :
On 16.11.11 20:46, Éric Lévénez wrote:
Le 16/11/11 20:24, Laszlo Lebrun a écrit :
On 14.11.11 21:32, Éric Lévénez wrote:
Le code de l'application qui sert à afficher à l'écran est le même que
celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour
l'écran, ça l'est aussi pour l'imprimante.
Wouaw! T'as l'air d'en connaitre un brin en technologie RIP.
Enfin tu crois en connaitre un brin...
Et toi tu as beaucoup manipulé Display PostScript ?
AH je comprends! parceque tu sais comment rediriger un Postscript vers
une imprimante, tu crois pouvoir écrire les âneries ci dessus?
Je comprends maintenant que tu ne sais pas ce qu'est Display PostScript
et tu ne sais pas non plus comment marche la NeXTprinter.
Tu essayes d'adapter ce que tu comprends de la technologie NeXT avec ton
petit monde.
J'aurais dû écouter tes conseils avertis avant de mettre une fortune
dans mon RIP Fiery,
Tu fais ce que tu veux mon grand.
Et oui, Pierre-Olivier Taubaty a raison en parlant de la vitesse
d'impression sous NeXTSTEP avec la NeXTprinter par rapport aux solutions
disponibles à la même époque.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le code de l'application qui sert à afficher à l'écran est le même que celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour l'écran, ça l'est aussi pour l'imprimante.
Wouaw! T'as l'air d'en connaitre un brin en technologie RIP. Enfin tu crois en connaitre un brin...
Et toi tu as beaucoup manipulé Display PostScript ?
AH je comprends! parceque tu sais comment rediriger un Postscript vers une imprimante, tu crois pouvoir écrire les âneries ci dessus?
Je comprends maintenant que tu ne sais pas ce qu'est Display PostScript et tu ne sais pas non plus comment marche la NeXTprinter.
Tu essayes d'adapter ce que tu comprends de la technologie NeXT avec ton petit monde.
J'aurais dû écouter tes conseils avertis avant de mettre une fortune dans mon RIP Fiery,
Tu fais ce que tu veux mon grand.
Et oui, Pierre-Olivier Taubaty a raison en parlant de la vitesse d'impression sous NeXTSTEP avec la NeXTprinter par rapport aux solutions disponibles à la même époque.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
J'ai ajouté deux nouveaux articles sur NeXT, à la même adresse <http://www.levenez.com/NeXTSTEP/#magazine> : UnixWorld et Datamation.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
J'ai ajouté deux nouveaux articles sur NeXT, à la même adresse
<http://www.levenez.com/NeXTSTEP/#magazine> : UnixWorld et Datamation.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Je viens de rajouter sur ma page web deux magazines français sur NeXT : - Le journal NEXTSTEP - du MAN - Inspector - La Lettre d'Information du FaNG
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Thierry Mella
OliDa wrote:
quelle époque formidable en créativité tout de même hein ?
20 ans après, quelles seraient les technologies futures qui, réunies ensembles, auraient autant de créativité que les NeXT à l'époque ? (à part l'iPhone/iPad !) ;-)
OliDa wrote:
quelle époque formidable en créativité tout de même hein ?
20 ans après, quelles seraient les technologies futures
qui, réunies ensembles, auraient autant de créativité
que les NeXT à l'époque ? (à part l'iPhone/iPad !) ;-)
quelle époque formidable en créativité tout de même hein ?
20 ans après, quelles seraient les technologies futures qui, réunies ensembles, auraient autant de créativité que les NeXT à l'époque ? (à part l'iPhone/iPad !) ;-)
pehache
On Nov 14, 9:32 pm, Éric Lévénez wrote:
Le 14/11/11 20:47, Laszlo Lebrun a écrit :
> On 14.11.11 02:11, Pierre-Olivier TAUBATY wrote: >> vu que l'OS NeXT fonctionnaiten Display >> Postscript, tout le boulot était déjà fait par l'ordi > surement pas! > Il y a un monde entre le rendering imprimante et écran.
En gros il n'y a que la résolution.
Oui, mais c'est énorme. Créer une image à 400dpi pour l'imprimante, c e 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.
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'imag e imprimante à la demande, comme d'habitude quoi.
Le code de l'application qui sert à afficher à l'écran est le mêm e que celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour l'écran, ça l'est aussi pour l'imprimante. Le CPU 68040 plus une liai son série haute vitesse (2 Mb/s) font le reste.
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.
Après, le principe de rasteriser sur l'ordi plutôt que sur l'imprimante, avec les avantages et les inconvénients que ça a, existe depuis un moment, et c'était très répandu dans le monde windows (sous le nom de "winprinters").
-- pehache
On Nov 14, 9:32 pm, Éric Lévénez <use...@levenez.com> wrote:
Le 14/11/11 20:47, Laszlo Lebrun a écrit :
> On 14.11.11 02:11, Pierre-Olivier TAUBATY wrote:
>> vu que l'OS NeXT fonctionnaiten Display
>> Postscript, tout le boulot était déjà fait par l'ordi
> surement pas!
> Il y a un monde entre le rendering imprimante et écran.
En gros il n'y a que la résolution.
Oui, mais c'est énorme. Créer une image à 400dpi pour l'imprimante, c e
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.
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'imag e
imprimante à la demande, comme d'habitude quoi.
Le code de l'application qui sert à afficher à l'écran est le mêm e que
celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour
l'écran, ça l'est aussi pour l'imprimante. Le CPU 68040 plus une liai son
série haute vitesse (2 Mb/s) font le reste.
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.
Après, le principe de rasteriser sur l'ordi plutôt que sur
l'imprimante, avec les avantages et les inconvénients que ça a, existe
depuis un moment, et c'était très répandu dans le monde windows (sous
le nom de "winprinters").
> On 14.11.11 02:11, Pierre-Olivier TAUBATY wrote: >> vu que l'OS NeXT fonctionnaiten Display >> Postscript, tout le boulot était déjà fait par l'ordi > surement pas! > Il y a un monde entre le rendering imprimante et écran.
En gros il n'y a que la résolution.
Oui, mais c'est énorme. Créer une image à 400dpi pour l'imprimante, c e 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.
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'imag e imprimante à la demande, comme d'habitude quoi.
Le code de l'application qui sert à afficher à l'écran est le mêm e que celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour l'écran, ça l'est aussi pour l'imprimante. Le CPU 68040 plus une liai son série haute vitesse (2 Mb/s) font le reste.
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.
Après, le principe de rasteriser sur l'ordi plutôt que sur l'imprimante, avec les avantages et les inconvénients que ça a, existe depuis un moment, et c'était très répandu dans le monde windows (sous le nom de "winprinters").
-- pehache
Éric Lévénez
Le 18/11/11 16:12, pehache a écrit :
On Nov 14, 9:32 pm, Éric Lévénez wrote:
Le 14/11/11 20:47, Laszlo Lebrun a écrit :
On 14.11.11 02:11, Pierre-Olivier TAUBATY wrote:
vu que l'OS NeXT fonctionnaiten Display Postscript, tout le boulot était déjà fait par l'ordi
surement pas! Il y a un monde entre le rendering imprimante et écran.
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 680x0 pour avoir un affichage fluide et une impression rapide. La vitesse du CPU joue un rôle primordial par rapport aux solutions de l'époque avec des imprimantes beaucoup moins bien dotés.
En plus, là où les imprimantes du marché (HP...) se limitaient à 300 dpi, la NeXTprinter était à 400 dpi, et cela avec la même cartouche EPS.
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.
Le code de l'application qui sert à afficher à l'écran est le même que celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour l'écran, ça l'est aussi pour l'imprimante. Le CPU 68040 plus une liaison série haute vitesse (2 Mb/s) font le reste.
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.
Après, le principe de rasteriser sur l'ordi plutôt que sur l'imprimante, avec les avantages et les inconvénients que ça a, existe depuis un moment, et c'était très répandu dans le monde windows (sous le nom de "winprinters").
Oui cela a existé avant NeXT et cela a existé après NeXT. Mais il faut replacer la chose à l'époque. Le 68040 des NeXTstations était une exclusivité NeXT avant les ordinateurs HP et donc longtemps avant les premières imprimantes avec ce processeur.
Dans la licence d'utilisation de NeXTSTEP il y avait une clause restrictive pour interdire de générer une image bitmap en interne avec une trop grande résolution (je n'ai pas retrouvé la limite mais c'était du genre 600 dpi). Plus tard la limite était toujours présente dans les docs mais avec un blanc à la place du nombre (donc clause sans valeur). Ceci avait été fait, sûrement à cause de Canon/HP/Adobe pour ne pas bouffer le marché des RIP dédiés.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 18/11/11 16:12, pehache a écrit :
On Nov 14, 9:32 pm, Éric Lévénez<use...@levenez.com> wrote:
Le 14/11/11 20:47, Laszlo Lebrun a écrit :
On 14.11.11 02:11, Pierre-Olivier TAUBATY wrote:
vu que l'OS NeXT fonctionnaiten Display
Postscript, tout le boulot était déjà fait par l'ordi
surement pas!
Il y a un monde entre le rendering imprimante et écran.
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 680x0 pour avoir un
affichage fluide et une impression rapide. La vitesse du CPU joue un
rôle primordial par rapport aux solutions de l'époque avec des
imprimantes beaucoup moins bien dotés.
En plus, là où les imprimantes du marché (HP...) se limitaient à 300
dpi, la NeXTprinter était à 400 dpi, et cela avec la même cartouche EPS.
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.
Le code de l'application qui sert à afficher à l'écran est le même que
celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour
l'écran, ça l'est aussi pour l'imprimante. Le CPU 68040 plus une liaison
série haute vitesse (2 Mb/s) font le reste.
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.
Après, le principe de rasteriser sur l'ordi plutôt que sur
l'imprimante, avec les avantages et les inconvénients que ça a, existe
depuis un moment, et c'était très répandu dans le monde windows (sous
le nom de "winprinters").
Oui cela a existé avant NeXT et cela a existé après NeXT. Mais il faut
replacer la chose à l'époque. Le 68040 des NeXTstations était une
exclusivité NeXT avant les ordinateurs HP et donc longtemps avant les
premières imprimantes avec ce processeur.
Dans la licence d'utilisation de NeXTSTEP il y avait une clause
restrictive pour interdire de générer une image bitmap en interne avec
une trop grande résolution (je n'ai pas retrouvé la limite mais c'était
du genre 600 dpi). Plus tard la limite était toujours présente dans les
docs mais avec un blanc à la place du nombre (donc clause sans valeur).
Ceci avait été fait, sûrement à cause de Canon/HP/Adobe pour ne pas
bouffer le marché des RIP dédiés.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
vu que l'OS NeXT fonctionnaiten Display Postscript, tout le boulot était déjà fait par l'ordi
surement pas! Il y a un monde entre le rendering imprimante et écran.
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 680x0 pour avoir un affichage fluide et une impression rapide. La vitesse du CPU joue un rôle primordial par rapport aux solutions de l'époque avec des imprimantes beaucoup moins bien dotés.
En plus, là où les imprimantes du marché (HP...) se limitaient à 300 dpi, la NeXTprinter était à 400 dpi, et cela avec la même cartouche EPS.
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.
Le code de l'application qui sert à afficher à l'écran est le même que celui qui est utilisé pour l'imprimante. Et comme c'est optimisé pour l'écran, ça l'est aussi pour l'imprimante. Le CPU 68040 plus une liaison série haute vitesse (2 Mb/s) font le reste.
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.
Après, le principe de rasteriser sur l'ordi plutôt que sur l'imprimante, avec les avantages et les inconvénients que ça a, existe depuis un moment, et c'était très répandu dans le monde windows (sous le nom de "winprinters").
Oui cela a existé avant NeXT et cela a existé après NeXT. Mais il faut replacer la chose à l'époque. Le 68040 des NeXTstations était une exclusivité NeXT avant les ordinateurs HP et donc longtemps avant les premières imprimantes avec ce processeur.
Dans la licence d'utilisation de NeXTSTEP il y avait une clause restrictive pour interdire de générer une image bitmap en interne avec une trop grande résolution (je n'ai pas retrouvé la limite mais c'était du genre 600 dpi). Plus tard la limite était toujours présente dans les docs mais avec un blanc à la place du nombre (donc clause sans valeur). Ceci avait été fait, sûrement à cause de Canon/HP/Adobe pour ne pas bouffer le marché des RIP dédiés.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
dapenospam51
Éric Lévénez wrote:
<http://www.levenez.com/NeXTSTEP/#magazine>
C'est vrai que cela fait du bien de revoir ces images et articles.
Je suis sûr que vous la connaissé tous, mais je rappelle qu'il y a une video de 35 minutes de démonstration de Next Par Jobs sur Youtube :
<http://www.youtube.com/watch?v=j02b8Fuz73A>
C'est vraiment une prévisualisation de notre système actuel !
-- dpesch
Éric Lévénez <usenet@levenez.com> wrote:
<http://www.levenez.com/NeXTSTEP/#magazine>
C'est vrai que cela fait du bien de revoir ces images et articles.
Je suis sûr que vous la connaissé tous, mais je rappelle qu'il y a une
video de 35 minutes de démonstration de Next Par Jobs sur Youtube :
<http://www.youtube.com/watch?v=j02b8Fuz73A>
C'est vraiment une prévisualisation de notre système actuel !
Je suis sûr que vous la connaissé tous, mais je rappelle qu'il y a une video de 35 minutes de démonstration de Next Par Jobs sur Youtube :
<http://www.youtube.com/watch?v=j02b8Fuz73A>
C'est vraiment une prévisualisation de notre système actuel !
Sur ma page web il y a cette vidéo mais aussi des dizaines d'autres.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Laszlo Lebrun
On 18.11.11 16:12, pehache wrote:
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.
Naturellement! A moins que le tramage NeXT n'ait été extrêmement primitif: sans lissage de polices, sans hinting, sans profils ICC et sans correction de moirés.
-- One computer and three operating systems, not the other way round. One mobile and two operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
On 18.11.11 16:12, pehache wrote:
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.
Naturellement! A moins que le tramage NeXT n'ait été extrêmement
primitif: sans lissage de polices, sans hinting, sans profils ICC et
sans correction de moirés.
--
One computer and three operating systems, not the other way round.
One mobile and two operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
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.
Naturellement! A moins que le tramage NeXT n'ait été extrêmement primitif: sans lissage de polices, sans hinting, sans profils ICC et sans correction de moirés.
-- One computer and three operating systems, not the other way round. One mobile and two operating systems, not the other way round. One wife and many hotels, not the other way round ! ;-)
