per@chalmers.UUCP (Per Westerlund) (09/02/86)
We recently got our LaserWriterPlus, and is using it for Tex/LaTeX on SUN-2s, running 2.0. The driver is dvi2ps on a recent UNIX-TeX tape from Washington, the one where the gf-format is not yet supported. We have run into some problems with this driver. (Actually it is not a driver, just a translator.) - For the fun of it I tried to print a document called "A Guide to TeX for the Troff User", by Mike Urban. (It was on the tape.) There is no way I can make the LaserWrite print the first page of Appendix B, Font Samples. It contains among other examples the word "BIG", in font 'aminch'. The bitmap is just to big, around 25 kbyte for the three letters. - During normal work, mostly 10pt type, two or three different fonts, I usually get from 5 to 25 pages before the LaserWrite quits with the message "VMerror: Offending command......." Some questions: - The big bitmaps can be much more compactly represented, cf. *gf <-> *pxl. Would it not be possible to send a PostScript program that builds the bitmap, prints the character and then releases the memory used by the bitmap? Alternatively, there could be a similar interpreter in the prolog, and a compact description could be sent instead. Maybe big characters can be represented as outline fonts; it should be possible to trace the border pixels of a big traditional letter bitmap and make a path out of it. This does not work for patterned bitmaps of course. - What is beeing done on font-cacheing? If big bitmaps can be more compactly represented, it should almost always be possible to print any single page. If then the conservative approach was used, and all of the used memory is reclaimed between pages, unlimited stretches of pages could be printed. Is there something in between? Reclaim some of the memory, and use it for new bitmaps. Even if this has not been done, it would be nice to hear of work in progress, or ideas that it might be possible to pursue. Per Westerlund perw@holtec.UUCP Excuse any abuse of the English (American?) language, my Swedish is much better. [[Editor's note: If you are doing work on this, please cc me as well as perw as I am currently gearing up to do some work on this for the Unix TeX distribution copy. My address is furuta@mimsy.umd.edu. Thanks. --Rick ]]
furuta@MIMSY.UMD.EDU (Richard Furuta) (09/21/86)
From: adobe!foley@decwrl.dec.com (Matt Foley)
Date: 10 Sep 1986 1833-PDT (Wednesday)
To: Per Westerlund <caip!seismo!enea!chalmers!per@uw-beaver.arpa>
Cc: foley@decwrl.dec.com, furuta@mimsy.umd.edu
Subject: Re: dvi2ps, bitmaps and font cacheing
In-Reply-To: Per Westerlund <decwrl!caip!seismo!enea!chalmers!per@uw-beaver> /
Mon, 1 Sep 86 17:19:54 -0200.
<8609011519.AA06949@chalmers.UUCP>
- The big bitmaps can be much more compactly represented,
cf. *gf <-> *pxl. Would it not be possible to send a
PostScript program that builds the bitmap, prints the
character and then releases the memory used by the bitmap?
Alternatively, there could be a similar interpreter in the
prolog, and a compact description could be sent instead.
I am not personally familiar with dvi2ps, but I believe it downloads
TeX characters as PostScript bitmap fonts. This requires that the
character description data be contained in VM, and indeed you could get
VM overflow with huge fonts. There are two basic solutions:
1. don't send the data as font characters, just send an imagemask
properly positioned on the page;
2. send the data in compressed form, with a /BuildChar procedure
that invokes a decompression routine. Since the PostScript environment
is interpretted (vs. compiled), this might be a little slow, but it
will work. However, the fonts produced by dvi2ps probably don't allow
for compressed data. If you are a PostScript programmer, you could
probably hack their filter and prologue so it would.
- Maybe big characters can be represented as outline fonts; it
should be possible to trace the border pixels of a big
traditional letter bitmap and make a path out of it. This
does not work for patterned bitmaps of course.
This would be even better, of course. One of the advantages of Adobe's
approach is the compactness of font data compared to bitmaps. It also
could be made to work for patterned fills of the characters. This
would take me a while to explain; email me if you ever have the
pressing need to do so.
- What is beeing done on font-cacheing?
If big bitmaps can be more compactly represented, it should
almost always be possible to print any single page.
It is not the font cache that's filling up, but the VM where the font
DEFINITION is being stored. The font cache is automatically bypassed
if a character glyph is too big.
It is possible to use an ordinary font definition, but not
download the individual character definition until it's needed. Just
download the "top level" of the font (apprx. 1300 bytes) and do the
'definefont', then when you need the 'A' character, do a save, download
the char data for 'A', invoke '(A) show', then do the corresponding
'restore'. This would allow you to diddle VM to your heart's content.
The problem is you spend lots of time downloading bit maps repeatedly,
because these very large characters won't be cached so you have to
download their defs each time. But it will work.
By the way, a similar approach may be used with ordinary-sized fonts to
fake up a system that appears to let you have a very large number
of fonts present in the printer without taking
up much VM. The font cache does not obey the save/restore mechanism, so
one can (a) create the top level of the font; (b) do a save;
(c) download the char defs;
(d) 'show' them at the needed point size [possibly into the null
device -- see 'setnulldevice'] so as to force their glyphs into the
font cache; then (e) do the corresponding restore, which recovers the VM
used to store the char data. The characters are available at the point
size and orientation at which they were cached, because the high-level
font dict is still present in VM, but the char defs are not taking up
any VM. Of course, this approach completely kills PostScript's usual
ability to arbitrarily scale a font; you also need to be aware that the
use of another font might cause your first font to be flushed out of
the font cache. If you wish to use this approach, you will probably
want to have a /BuildChar proc that yells for help if asked to print a
char for which it has no def. Recovery from such an error would be
nearly impossible on a single-channel device; on the other hand, a
system like the Lino100, which has a disk drive, could automatically
load from disk via a different channel, without interfering with data
already in the stdin channel.
I'm getting rather esoteric here. If you have further questions,
please feel free to address them directly to me.
[Note to moderator: Rick, if you think this would be of general
interest to the newsgroup, feel free to post it.]
--Matt Foley, Cust. Supt. Eng.
ADOBE SYSTEMS INCORPORATED
decwrl!adobe!foley
"adobe!foley"@glacier.stanford.edu
(415) 852-0271
PostScript is a registered trademark of Adobe Systems Incorporated.