[comp.fonts] Adobe Type 1 font file sizes

kibo@pawl.rpi.edu (James 'Kibo' Parry) (08/23/90)

[]
	I'm looking at the sizes of the outline font files that came
with Adobe Type Manager 1.2 (Macintosh)...

	Courier              28,686 bytes
	Courier Bold         29,721
	Courier Oblique      35,010
	Courier BoldOblique  36,915

	Helvetica            27,866
	Helv. Bold           28,162
	Helv. Oblique        33,990
	Helv. BoldOblique    34,677

	The question is, why are the oblique font files 20 to 25 percent
larger than the non-oblique files?

	The only explanation I could think of is that maybe Adobe is
clever and has a command defined that's a "lineto-same-x-coordinate"
that takes one parameter, so non-oblique fonts could use the shorthand
for their vertical strokes... but this is speculation, of course.

	Just wondering...

-- 
james "kibo" parry, 138 birch lane, scotia, ny 12302 <-- close to schenectady.
kibo@pawl.rpi.edu            _________________________________________________
kibo%pawl.rpi.edu@rpi.edu   / Kibology    /  Anything I say is my opinion,
userfe0n@rpitsmts.bitnet   /  is better! /   and is the opposite of Xibo's.

kevina@apple.com (This space for rent) (08/24/90)

In article <66_%&L#@rpi.edu> kibo@pawl.rpi.edu (James 'Kibo' Parry) writes:
>         I'm looking at the sizes of the outline font files that came
> with Adobe Type Manager 1.2 (Macintosh)...
> 
>         (...sizes deleted...)
>
>         The question is, why are the oblique font files 20 to 25 percent
> larger than the non-oblique files?
> 
>         The only explanation I could think of is that maybe Adobe is
> clever and has a command defined that's a "lineto-same-x-coordinate"
> that takes one parameter, so non-oblique fonts could use the shorthand
> for their vertical strokes... but this is speculation, of course.

Adobe is cleverer still, in that the font data for Oblique fonts is the 
*same* font data as in the corresponding Roman font, algorithmically 
sheared using the FontMatrix.  (This is why they are called "Oblique" 
instead of "Italic"... the same holds true for "Narrow" vs. "Condensed".)
Adobe calls these "synthetic" fonts (see chapter 9 of the Black Book.)

If the base font (e.g. Helvetica) already exists on the printer, the 
synthetic font program (e.g. Helvetica-Oblique) creates a new font 
dictionary with its own FontName, FontMatrix, UniqueID and FontInfo 
entries.  (It also creates its own Private dictionary, but only because 
the UniqueID is duplicated there.)  It then uses the CharStrings 
dictionary from the base font as the CharStrings entry in the synthetic 
font dictionary.  Saves VM, right?  Right!

But what if the base font doesn't already exist on the printer?  (Granted, 
it won't happen with Helvetica-Oblique, but it might with Tekton-Oblique.)  
The synthetic font program contains a copy of the base font program.  If 
the base font is already on the printer, the base font program is 
discarded; if not, it is executed and the synthetic font proceeds as 
before.  

So, in printer VM, synthetic fonts are actually only about 20-25% the size 
of their base fonts, due to the font dictionary itself and its FontInfo 
and Private dictionaries.  Because the synthetic font program has a copy 
of the entire base font program, the synthetic font *files* are 25% larger.

(Of course, Adobe *does* have a "lineto-same-x-coordinate" command -- 
hlineto -- but that's not causing the savings here.)

--Kevin Andresen [kevina@apple.com]
"X_____ geek-heads of the world, unite!"

meuchen@grad2.cis.upenn.edu (Paul Eric Menchen) (09/02/90)

In article <66_%&L#@rpi.edu> kibo@pawl.rpi.edu (James 'Kibo' Parry) writes:
>[]
>	I'm looking at the sizes of the outline font files that came
>with Adobe Type Manager 1.2 (Macintosh)...
>
>	Courier              28,686 bytes
>	Courier Bold         29,721
>	Courier Oblique      35,010
>	Courier BoldOblique  36,915
>
>	Helvetica            27,866
>	Helv. Bold           28,162
>	Helv. Oblique        33,990
>	Helv. BoldOblique    34,677
>
>	The question is, why are the oblique font files 20 to 25 percent
>larger than the non-oblique files?
>
>	The only explanation I could think of is that maybe Adobe is
>clever and has a command defined that's a "lineto-same-x-coordinate"
>that takes one parameter, so non-oblique fonts could use the shorthand
>for their vertical strokes... but this is speculation, of course.
...
Someone responded that obliques were based on the base Roman typeface
and were therefore smaller. He or she (don't remember) missed the boat
entirely. The Obliques are larger, and there is a reason. I will try
to shed some light on this.

First, even though the Obliques do not involve changes one would
associate with an italic, they are not encoded as just "look up Roman
'a' and slant 15%." Apparently this takes up too much time, and instead
the character forms are all slanted 15% (or whatever, depending on the
face) and then the Adobe Type 1 encoding is done.

I am not a PostScript guru, but as I read the Fontographer 3.1.x
update which produces Adobe Type 1 fonts among other things, I did
read that the encryption/compression works better for tangent points
and bezier points which are at 90 degree angles. I don't remember the
details and the manual is at work, but I guess if you have a straight
and either horizontal or verticle line that connects to a curve and
the corresponding bcp of the curve lies along the line some special
compression takes place. This also may be true for single curves which
have bcp's either horizontally or vertically aligned from the
endpoints. Thus Roman characters with many horizontal and verticle
lines and horizontally and vertically aligned bcp's can be compressed
more than Oblique characters.

                      +++++****X**                  +++++*****X***
                        ***                        +  ***
                     + *                           +**
                     +*                           +*
                     +*                           *
                     *                            *  
                     *                           *
                     X                           X
                     *                          *

*'s are the outline; + the Bezier control lines; X's the endpoints

The Roman character on the left can be better encrypted because of its
verticle stroke which connects to a bezier curve with verticle aligned bcp.

Better sources of info than me would be the Adobe black & white book
and the Fontographer 3.0 manual and 3.1 update in particular. I did
discuss this with a tech person at Altsys as well in reference to the
"Would it be better to create a composite that references the original
and just slant it 15% question." They were pretty helpful.

Paul Eric Menchen
meuchen@grad1.cis.upenn.edu