🚀 go-pugleaf

Excerpts from internet.info-andrew: 26-Feb-90 Printing bugs with insets.
Rocky - Rakesh Patel@khn (5259+1)



> There are some serious bugs with printing and insets... 

> When embedded rasters are incuded in a document, ezprint ends up
> sticking `\` at the end of each postscript command. That is a serious problem.



Well, it is not a problem of ezprint. It is a problem what pops up in
newer versions of troff (As far as I've have seen, in ditroff release
2.0). This newer version of troff has a bug fix which cause this new one
introduce a bug, the classical example of ``there is always one last
bug''. For historical reasons ditroff has its own version of the stdio
library. It has been decided that [fs]printf will always stick a
backslash before non-printable characters, although this code actually
never got executed in the original ditroff version. This bug is fixed
and now another one pops up: accidently '\n' is also considered
non-printable.

The problem can easy be demonstrated with something along the line of:

troff
\!this string will appear in the ouput with a backslash attached
\!it shouldn't
.ex

There should now be some output with the two strings clearly visible and
with a backslash before the CR following these strings.

If you have the source, it is easy to fix. Look at the file n1.c and
look at the scaled down version of C library printf. You will see twice
code in the style of:

	else if (c == 'c') {
		c = *astr & 0377;
		if (c > 0177 || c < 040)
			putchar('\\');
		putchar(*astr & 0177);
	etc.

It is obvious that one should not print the backslash for certain chars
< 040, so the code need to look along the lines of:

	else if (c == 'c') {
		c = *astr & 0377;
		switch(c) {
		    case '\n':
		    case '\t':
		    case '\f':
		    case '\b':
			putchar(c); break;
		    default:
			if (c > 0177 || c < 040)
			    putchar('\\');
			putchar(*astr & 0177);
		}
	etc.


Note that I'm doing this from memory, so you mileage might vary how the
code actually looks like. Of course, if you don't have the source yell
to your supplier.

> The other problem is seen when embedding other insets into a zip object.

[Example deleted]

> This is a serious mess. I'm surprised no one has bothered to even mention
> these problems or attempted to fix them.  Note that I have been happy
> with the new release since the folks at CMU (and friends) have put considerable
> effort in to de-CMUize the release. I just wish we could print the stuff
> now.  :-(

Yep, it is a serious mess. Printing is not ATK strongest point. It is of
course difficult to put this infinite embedding of objects on paper. It
is amazing how much does work and yes, I'm afraid embedding insets in
zip looses when it gets printed.