cmcmanis%pepper@Sun.COM (Chuck McManis) (05/16/88)
Actually there is a much better benefit to NAPLPS than just it being a
standard, and that is that it has "infinite" resolution. And when you
printed it on your printer you could use the printer resolution and
you images would look better on paper than they did on the screen.
This is the current difficulty that the Amiga has with fonts. Basically
you pick Ruby 15 because you want big letters on the screen, but when
you print them on the printer at 1:1 resolution you get little letters.
What most users *want* is that the letters on the printer be the same
size as the letters on the screen and if the printer has better resolution
than the printer then you want the letters to look better on the printer
than they do on the screen. What this involves is abstracting the characters
exactly like you do NAPLPS images. The ratio between the printer resolution
and the screen resolution is determined and the font is 'mapped'. For
example :
By convention 8 pixel fonts map 1:1 to the printers built in font which
generates (usually) 10 characters per inch. So 8.5" of printer map to one
screen width of 640 pixels. If the printers resolution is 144 dots/inch
(like on the epsonX series) then 8.5 inches on the printer is 1224 pixels.
And the mapping, screen to printer is 1:1.91. Thus if you were using Ruby
15 on the screen you would need to use ruby 28 on the printer to get the
same 'size' letters. Unfortunately this is not a very straight forward
mapping but NAPLPS can handle it.
Now, does anyone know why the 'info' terminals which use NAPLPS to render
to the screen are so slow?
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.richard@gryphon.CTS.COM (Richard Sexton) (05/16/88)
In article <53300@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > > By convention 8 pixel fonts map 1:1 to the printers built in font which >generates (usually) 10 characters per inch. So 8.5" of printer map to one >screen width of 640 pixels. If the printers resolution is 144 dots/inch >(like on the epsonX series) then 8.5 inches on the printer is 1224 pixels. >And the mapping, screen to printer is 1:1.91. Thus if you were using Ruby >15 on the screen you would need to use ruby 28 on the printer to get the >same 'size' letters. Unfortunately this is not a very straight forward >mapping but NAPLPS can handle it. It's even easier in PostScript. And more elegantly, too. >Now, does anyone know why the 'info' terminals which use NAPLPS to render >to the screen are so slow? They use Suns to render the images ? >--Chuck McManis > sun!cmcmanis Sorry Chuck, she made me do it :-) -- And other people run red lights, too. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
scott@applix.UUCP (Scott Evernden) (05/16/88)
Hmm, I thoght that NAPLP like PostScript, ReGIS, CGM, various TEK command sets, etc, etc, were *presentation level* protocols. Unless I remember wrong, they are used to *render* pictures, but provide nothing in the way of *structured* information. Sure, you can make up macros and defs and escapes and such, but then you haven't defined anything, and you're back where you started. How is an application supposed to understand grouping, attributes, and other relationships from a NAPLPS or PostScript data file? How are these mechanisms extended to handle 3D information, constraints, and history, for example? These protocols deal with Viewing and not Modelling. Formats like IGES, etc., are more in line with where I think investigations should begin. Also note that in over 10 years of standardization efforts on the part of ANSI and ISO, and despite CORE, GKS, PHIGS, CGM, etc, etc,. there is still no universally adopted model for representing graphical information. -scott