From: matija@avalon.physik.unizh.ch (Matija Milostnik)
Subject: Re: *REAL* Scalable Font Support for the Amiga?
Summary: CG fonts have more info than other fonts
Keywords: CG fonts, printing
Organization: Informatik Club d. Universitaet, Zuerich
Date: Thu, 5 Nov 1992 14:01:26 GMT

In article <1992Nov3.130525.4926@ida.liu.se> micja@ida.liu.se (Michael Jansson) writes:
>
>In article <1992Nov2.154658.27726@ifi.unizh.ch>, matija@avalon.physik.unizh.ch (Matija Milostnik) writes:
>> Hello
>> In article <1992Oct30.073744.10089@leland.Stanford.EDU> goldman@leland.Stanford.EDU (Oliver Isaac Goldman) writes:
>I belive that it is even worse; printer drivers can *only* print graphics,i.e.
>there are no support for down loadable fonts in the current specification for
>printer drivers (right!?).  
>
>I don't know of a printer that do not have support for down loadable fonts
>(even 9-pin printers have them, though only for fonts of some fixed size).
>A program has to circumvent the printer device if it wants to down load a 
>font, which means that the program has to know of the protocol of the 
>particular printer. This is not a practical solution.

Its also out of the scope of the printer driver as it is intended in the 
Amiga. A down loadable font is meant to be specific to a printer. 
For using downloadable fonts, software shold be capable of asking the
printer the availability and resolution it has, and then decide how the
downloadable font must be. Even though it could have this infotmation from 
the driver self, I guess it would be inpractical.

Another problem I see, is the following situation. Immagine a user with a 
printer A that writes a document with a specific font. When the document is
used by another user, who has a printer that cant download the font for 
printer A, how is he supposed to print the document? Printer B should then
use another font or refuse to print?

>> This is the point.
>> Any application that does this must be rewritten to handle:
>> 
>>   the math to do the right conversion from 75dpi to 300dpi.
>>   [this alone is quiet hard to do. You just cant double all
>>    sizes and expect it to be right. Its even harder by the 
>Is it that hard? Can you point out is the following discussion is wrong 
>or lacks some details:

Nothing wrong, just I didnt point it out right.

>A font is accessed in units of ppm (pixels per em, i.e. number of ink dots 
>in a perfect square that fits inside a character of the font). The unit
>that is preferred is however points, which can be converted if the resolution
>of the device is known. The reference point is the screen resolution, i.e. 
>a font on screen has the same height in ppm as in pt on screen. 

Here we have to differentiate if we are spaking of CG fonts only or if 
we speak speak of scalable font.
CG fonts have their natural unit in em. This information is avaiable and
can be used to determine the font size you need on screen. The font has
few other information, the scaling engine can use the supplided informations
to render the font you need. This information is dependent on the interface
the system (in this case the diskfont.library) gives you.

Scalable fonts are font in bitmap tha can be 'scaled' by the diskfont.library
to any point size. Their size is given in points. If you are lucky you can 
also find out if it was intended to be for wide or narrow pixel, the aspect
ratio and other data. (I dont have the documentation right now, but it 
depends on the version of the font structure).

>Say that I 
>have a 140x300 DPI printer (an arbitrary resolution), then I would request 
>I 10pt font like:
>
>Point size = 10pt
>Resolution = 140 x 300
>Ppm size = pt / ScreenDPI * DPIY => 10 / 72 * 300 = 41.6666 (~42ppm)
>
>I would then set up a font request (a TTextAttr structure) with the ppm size 
>42 and the device resolution 140x300.

Nope you only did the calculation in one direction. What the other size will 
be depends on the aspect ratio of you displaying device, the font design for
wide or tall pixel (scalable fonts), the aspect ratio the engine is sizing 
the caracter at the moment (its not the aspect ratio of the displaying 
device).

>This is straight forward, given that I will not need to apply special 
>adjustment of the space between certain letter combinations (pair-kerning,
>e.g. reducing the gap between A and O). That would require some (non-linear)
>scaling, which has to be handled by a DTP program anyway. Special kerning 
>information is needed for this, but that is not printer specific (it's needed
>for the screen as well).

>>   the splitting of the page in more horrizontal strips.
>>   the bigger memory requirements for this printing.
>>   and so on...
>[These problem could be reduced if there where support for down loading fonts
>through the printer drivers (that would not work for all printer though, e.g.
>some printers can only support fonts of fixed sizes.)]

see above

>I agree, though I don't think the bullet is really needed unless you want to
>do pair-wise kerning (some fonts don't even contain kerning information), 
>rotation etc.  The diskfont.library will give you the correct size and 
>resolution for fonts as of OS 2.04. I guess programs are just not written
>to take advantage of the new features.

The actual diskfont.library give you the ablity to size fonts, but
there are cases you cant know if you have gotten what you asked for.
With bullet you have sligtly complexer interface, but you can aks and 
really get what you asked.

I guess this is getting more confusing at every post, isnt it?:-)
  Matija

>     Michael Jansson	  mij@IDA.LIU.SE, uunet!liuida!mij, mij@SELIUI51.BITNET
-- 
Best regards from Matija Milostinik           : matija@avalon.ifi.unizh.ch  
                                              : matija@amiga.physik.unizh.ch
Therefore, use local labels in the procedures as often as possible. 
Save the environment!  Recycle!  ;-)                 (Bjoern Reese)