[luatex] LuaTeX file almost 2.5x bigger

[Reinhard Kotucha]

On 7 August 2010 Martin Schröder wrote:

 > 2010/8/7 Pablo Rodríguez <oinos at web.de>:
 > > I guess there is no way to avoid it (since there is no easy way
 > > to avoid the patent itself).
 > 
 > Well, the patent is EP0466953, which should have expired on
 > 2010-07-18 (1990-07-17 plus 20 years), but IANAL... :-)

There are also severe technical problems.  I assume that Zapf's idea
is based on multiple-master fonts.  But since such fonts are not
available, there is no easy way to implement Zapf's algorithm.
Hence it's not only a legal problem.

The difference between Thanh's and Zapf's algorithms is that Thanh
scales the glyphs horizontally while Zapf proposes to create dedicated
instances of a font where the stroke width is preserved.

Quite strange: There is no easy way to implement Zapf's algorithm
anymore since we have/prefer Type1 fonts, TTF, and OTF.  With
Metafont, I believe, it's not a big deal. :)

I don't know whether it's possible at all to create expanded instances
from Type1 outlines on-the-fly with Lua.  In a properly hinted Type1
font the stroke width can be derived from the /hstem and /vstem hints.
But I fear that many fonts are not properly hinted and thus this
approach is supposed to fail.

The subject of this thread is "LuaTeX file almost 2.5x bigger".
So let me summarize:

   * Zapf's algorithm requires dedicated fonts for each level of
     expansion.  This leads to larger PDF files.  Especially if Type1
     fonts are involved which can't be compressed efficiently because
     they are encrypted.

   * Thanh's algorithm requires that a particular font is inserted
     only once and expansion is performed by scaling the glyphs.  This
     obviously leads to smaller files.  

Nevertheless, as Patrick pointed out, the reason that the file created
by LuaTeX is so large is that each glyph is preceded by the TextMatrix:

  0.98 0 0 1 226.832 147.716 Tm [<0057>]TJ
  0.985 0 0 1 230.145 147.716 Tm [<0058>]TJ
  0.98 0 0 1 235.264 147.716 Tm [<0055>]TJ
  0.985 0 0 1 238.686 147.716 Tm [<0044>]TJ
  0.98 0 0 1 242.624 147.716 Tm [<004F>]TJ
  0.985 0 0 1 247.57 147.716 Tm [<0056>]TJ
  0.98 0 0 1 251.064 147.716 Tm [<00B5004F>]TJ

There is probably some room for improvements.  The TJ operator
supports kerning already quite similar to dvips, which is very
efficient.

Example (from the PDF reference manual):

  [(A) 120 (W) 120 (A) 95 (Y)] TJ

And the Th operator supports horizontal scaling.

I think that a lot of space can be saved if these operators are used
instead of the TextMatrix.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha		1] http://www.adobe.com/devnet/font/pdfs/5091.Design_MM_Fonts.pdf	              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------