MiC MAC

Le
Éric Lévénez
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.
Vos réponses Page 3 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
pehache
Le #23981111
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

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.


> 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.



Du 680x0 (?) pour une impression rapide ? C'est pas du 400dpi, ça.


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.



D'accord. Donc ça reposait sur la puissance de la station.


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...



Je ne dis pas le contraire. Néanmoins, il fallait bien recalculer
l'image pour l'impression à un moment ou à un autre.


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.



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.

--
pehache
sebastienmarty
Le #23981281
pehache
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 ?

--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
pehache
Le #23981401
Le 19/11/11 13:08, SbM a écrit :
pehache
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.

--
pehache
Éric Lévénez
Le #23981661
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.

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.



Pas sur NeXTstation et NeXTcube standard. Mais vrai pour les NeXTcubes
avec une carte NeXTdimension et son i860.

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.

Et oui, je le répète l'impression (et l'affichage) était rapide.

Bien sûr il ne faut pas comparer un 68040 à 25 MHz avec un processeur
moderne multi-cœur et N GHz.

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.



Bien sûr puisqu'il n'y avait pas de véritable CPU dans les NeXTprinters.

Par contre on pouvait bien sûr imprimer sur une imprimante "normale" qui
fait son propre rendu.

Je ne dis pas le contraire. Néanmoins, il fallait bien recalculer
l'image pour l'impression à un moment ou à un autre.



On a toujours dit que c'est NeXTSTEP qui faisait la rasterisation de la
NeXTprinter et que cette solution était plus rapide que les solutions
avec PostScript intégré sur imprimante.

On parle de techno d'il y a 20 ans. Je le rappelle encore une fois.

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.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
pehache
Le #23982171
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.



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.




J'avais compris une résolution de 680 x whatever :-)



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.




...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.

--
pehache
Éric Lévénez
Le #23982401
Le 19/11/11 15:55, pehache a écrit :
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.



Oui dans le cas où la page est totalement rempli, donc faux dans la
majorité des cas. Les fabricants d'imprimante considèrent qu'une page
est remplie en moyenne à 5 % d'encre. Après on peut chipoter que
certains utilisateurs impriment toujours des images pleine page.

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.



Oui, bien sûr. Mais je le répète une dernière fois, on parlait de la
vitesse d'impression sur NeXT présente grâce à la vitesse de son CPU,
grâce à l'optimisation de NeXTSTEP, et grâce au fait que Display
PostScript ait accès a beaucoup de place mémoire pour son cache des
fonts (par exemple) et à la vitesse du CPU de la machine.

...et comme PS ou DPS. C'est juste que PS/DPS sont plus élaborés



Non, c'est un langage informatique complet.

(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).



Adobe a fait beaucoup de mal à PostScript dans ses évolutions. On le
voit en regardant les problèmes de compatibilité des versions PS et on
ne voit en regardant comment certains ont utilisé des astuces pour
contourner les limites du moment. Je pense par exemple au images preview
(en bitmap) d'un fichier PS/EPS vectoriel (fait pour Mac OS ou Windows,
pas pour NeXTSTEP bien sûr), que certains ont détourné pour y placer des
images complètes bitmap !

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.



La vitesse du CPU est de loin ce qui expliquait la vitesse, mais
l'optimisation de Display PostScript est est un autre point. Pour
imprimer sur NeXTSTEP, il suffit de rediriger le flux des tokens DPS
vers l'imprimante. Sur les autres systèmes il faut qu'un driver vienne
interpréter les ordres de dessin de l'OS pour les transcoder dans le
plus petit comment dénominateur des imprimantes PS/PCL.

Pour imprimer une image sur PostScript, on envoie celle-ci en bitmap à
RIP qui se charge de l'affichage (résolution, transformation
diverses...), et à l'époque les imprimantes étaient souvent reliées en
série (et pas à 115 bauds) ou en parallèle (première génération, lent).
Alors faire tout le traitement dans NeXTSTEP et n'envoyer que le
résultat final, en compressé et sur une ligne à 2 Mbits/s était une
avancée. La NeXT Color printer, à cause de la couleur, devait avoir une
liaison encore plus rapide, et c'est pour cela que l'interface était
SCSI (je crois que c'était du 80 Mbits/s).

J'ai une très vieille imprimante PostScript qui pouvait avoir un disque
dur pour accélérer les traitements des pages avec beaucoup de fonts, et
bien tout cela était inutile avec Display PostScript et sa NeXTprinter
par ce qu'il tournait sur une machine avec beaucoup de mémoire (pour
l'époque). De plus c'était de la mémoire virtuelle, comme sur tout Unix
que se respecte. Les imprimantes PostScript de l'époque envoyaient
souvent des "Stack Overflow" dès qu'une page était trop remplie...

D'ailleurs à matériel égal, je ne crois pas qu'une imprimante PS soit
notablement plus rapide qu'une imprimante PCL.



Oui. Mais faut voir la qualité lamentable du code PostSript généré par
les drivers d'impression. C'est comme regarder le contenu d'une page Web
générée par un outil Microsoft.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
pas.de.spam
Le #23983731
pehache
Le 19/11/11 13:08, SbM a écrit :
> pehache >
>> 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 "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
--
PO.

Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
pehache
Le #23983801
Le 20/11/11 00:45, Pierre-Olivier TAUBATY a écrit :




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.



La génération du code PS n'est sûrement pas ce qui est le plus coûteux,
par rapport à la rastérisation.

Le soft génère le code (D)PS, et le système le traduit en un bitmap
affichable, en 72dpi.

Pour envoyer le truc à l'imprimante, il n'y a certes pas à regénérer le
code (D)PS (encore que, si tu imprimes un doc de 50 pages en n'ayant que
la première affichée, il faut bien générer le code des 49 autres au
moment de l'impression), mais il faut refaire la rastérisation à 400dpi
(et c'est ce qui coûte, et ce n'est pas juste une adptation).

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



Mais je n'ai pas dit que ce n'était pas bien de faire ça, j'ai
simplement mis en doute le fait que la rapidité d'impression était dûe à
DPS en lui-même.

--
pehache
Laszlo Lebrun
Le #23984851
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.

--
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 ! ;-)
Éric Lévénez
Le #23984941
Le 20/11/11 11:20, Laszlo Lebrun a écrit :
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.



Effectivement. Le code Objective-C d'un programme utilise des API
Display PostScript directement. Et c'est suivant la résolution du
périphérique de sortie que ces fonctions font le rendu bitmap. En fait
les fonctions C de Display PostScript tokenisent les ordres DSP et les
envoient au Window Server qui fait le rendu.

Voir
Et donc le même code Objective-C/DPS donne un bitmap différent quand on
l'appel pour l'écran ou pour une imprimante donnée. Ce qui veut dire que
le rendu utilisé pour l'écran ne peut pas être utilisé pour l'imprimante.

Mais ce qui est intéressant est que le même code Objective-C/DPS est
appelé 2 fois et donc il n'y a pas de code nouveau faisant une
interprétation spécifique pour l'imprimante, comme avec les drivers
imprimantes des autres systèmes.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.
Publicité
Poster une réponse
Anonyme