| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 774.1 | At first glance... | COOKIE::JOHNSTON | | Fri Aug 07 1987 15:23 | 16 |
| Did you possibly get bit by the /PASSALL/NOFEED hornet?
What you describe frequently indicates that you failed to print the file
using those qualifiers, which are required:
$ PRINT/QUE=somequeue/PASSALL/NOFEED filename.LN03
.POST
I think these qualifiers are included in the DESTINATIONS.DAT file, so
they should be inherent in the DOCUMENT command line. But not knowing
how your queues are set up...
Rose
|
| 774.2 | Sure it's not the figure? | GNUVAX::LIBRARIAN | Looking at the big sky | Fri Aug 07 1987 16:18 | 10 |
|
Are you sure that the two figures are the same size etc.? Just to make
sure you could try switching around where the two figures are called
in, calling each in the others place. If you still get the unwanted
extra space at the same position in the document with the other figure
in that place, it pretty much has to be a Document quirk. If not,
perhaps it has to do with one of the figures.
Lance
|
| 774.3 | tried all those.. | CASEE::BROWN | Lynda Brown | Mon Aug 10 1987 05:59 | 36 |
| < Is it the passall/nofeed hornet?
No...that was the first thing that I tried when the problem first
started. Exactly the same thing happens when I explicitly specify
Passall/nofeed when I print the chapter.
< Are the figs. the same size etc....
No...the two figures are completely different to each other. I've
swopped the placement of the figures in the chapter and when the
second (largest) figure is put first it is too large to fit on the
page and it is put at the top of the following page...as one would
expect. The first figure prints perfectly O.K. as the second figure
in the chapter.
The thing that is confusing me at the moment is that, the figures
printed properly using a different template (report etc.). Also,
the first figure definitely should fit on the page I want it to
go on. If it was just a case of the figure taking up too much room
on the page then I would still get the running feet on the first
page and the figure would just be printed at the top of the second
page...exactly what happens when I swopped the two figures over.
But...what actually happens is that the figure is printed where
I want it to be on the first page but the page number/running feet
is missing..when you look at the second page, the text that follows
the figure is printed on the 2nd page EXACTLY where it should be
ON THE FIRST PAGE (ie. great for a cut-and-paste job). The page
number/running footer for the FIRST page is also printed on the second
page.
Still in need of help.....
Lynda.
|
| 774.4 | Were those figures cropped...? | GNUVAX::LIBRARIAN | Looking at the big sky | Mon Aug 10 1987 10:27 | 16 |
|
Since you created the figures in SIGHT I'm assuming that you didn't
crop them. It could be that one of the figures has a lot of blank
whitespace at the bottom (or top). Try editing each figurefile that is
being called in with a text editor. You'll be looking at sixel code, so
expect it to look strange. Move to the very bottom of the file. Look to
see if there are a whole lot of hyphens. In sixel code hyphens
represent CR/LF's. If you find a bunch of them, say "whoopee" loudly,
cut them all out, exit the file, and process your .SDML file again
calling in the new figurefile. If you don't find a large number of them
at the bottom, check the top and follow the same procedure. No hyphens
anywhere? --> Return to drawing board.
Lance
|
| 774.5 | if all else fails | CLOSET::ANKLAM | | Mon Aug 10 1987 17:57 | 5 |
|
If Lance's suggestions don't solve the problem, please get in touch
with me directly. I will need access to your sources, sixes, etc.
|
| 774.6 | problem solved but... | CASEE::BROWN | Lynda Brown | Wed Aug 12 1987 04:58 | 17 |
| First of all, thanks for the help.......cropping the figure
files did the trick nicely.
But I'm still a bit confused - If the extra hyphens at the end of
the file were the problem, why didn't the same problem happen when
I just swapped the two figures over? If the extra space meant that
the figure didn't fit where I thought it should why did it print
O.K. when I just moved it to a different place in the file?
Also, I noticed that there were some spare hyphens at the end of the
second figure file (so I removed them just in case) but why didn't
they cause a problem like the first file?
Anyway, I'm pleased that the problem appears to have been sorted
out but I'd appreciate a little bit of light being shed on my
confusion.
Lynda.
|
| 774.7 | bug avoided, not resolved | CASEE::CLARK | Ward Clark | Wed Aug 12 1987 10:34 | 18 |
| It's nice that there is a work-around for Lynda's problem, but it seems
to me that there's still at least one bug here:
1. When the oversized figure is included, no page number appears
at the bottom of the page.
2. The <FIGURE_FILE> tag requires a "vertical-size" argument. The
(BL8) documentation doesn't indicate what happens when this
argument does not match the actual figure.
I'd assumed that the vertical-size is used to pad or truncate
the actual figure. If that's case, the length of the figure
should not affect formatting.
In any case, the documentation could be improved. (Maybe it
already has been for V1.0.)
-- Ward
|
| 774.8 | Dep't of clarification | CLOSET::ANKLAM | | Wed Aug 12 1987 14:29 | 43 |
|
Here is an explanation of the relationship between the <FIGURE_FILE>
tag's vertical size argument and the graphic itself:
1. The value specified in the vertical size argument is given to
the text formatter, which constructs the page leaving the specified
area blank.
2. During device conversion, the graphic file is included. The origin
point of the graphic is the upper left-hand corner of the space
left by the text formatter.
This is true for the LN03, which we are discussing here. For
PostScript, the origin is the *lower* left of the space reserved.
3. If the graphic itself is longer or wider than the space left
by the text formatter, it will overwrite anything that the text
formatter will have placed on the page in the area now occupied
by the graphic.
Furthermore, if the graphic runs off the bottom of the
page, a page eject will occur. Then, in the typical case, the
text which follows the graphic will be positioned at the correct
depth on the new sheet of paper.
This is particularly subtle, because some graphics editors create
"full-page" images, even though the visible content may be only
a small part at the top of the image. That is why sixel files
sometimes contain a lot of graphic newlines (hyphens) at the end,
and that is why (1) the page eject described in .0 occurred and
(2) the technique described in .4 (hyphen-removal) worked.
As to the question of why the page eject occurred in one place
and not another: without looking at the files, one can only
guess that the figure was positioned lower on one page than
on another according to the surrounding context.
The point is that the text formatter has no knowledge about the
figure itself; it must rely on the fact that the vertical size
argument is correct and that the graphic itself is within those
bounds.
-pa (with edits by Mark DeVries)
|
| 774.9 | Implementation glitch or feature? | CASEE::CLARK | Ward Clark | Thu Aug 13 1987 04:31 | 12 |
| Thanks to Patti and Mark for the very detailed clarification of how
figures are handled by the tag translator and text formatter.
One aspect of this problem is still not clear. Is the current behavior
(1) an unfortunate aspect of the current implementation or (2)
something that DOCUMENT users will have to contend with in V2 and
beyond?
Whichever is the case, the V1.1 Release Notes should probably address
this figure size issue.
-- Ward
|
| 774.10 | Don't blame Document | GNUVAX::LIBRARIAN | Doing what I can't to learn how to | Thu Aug 13 1987 12:20 | 37 |
|
RE:-.1
It's not really Document that's causing the trouble here. As Patti
pointed out, some graphics editors (such as SIGHT) create figures that
are full-page size no matter what. If the actual picture or whatever
you created is only 5 picas square, the rest of the figure that SIGHT
creates is filled with 'whitespace'. You can't see this whitespace, but
it takes up space.
Since it looks to you like the figure you have created is only 5
picas that's what you tell Document to expect, and it dutifully leaves
a 5 pica hole. Then it tries to include a figure that is more like
50 picas tall. You end up with the problems Patti described.
There are several workarounds to this problem;
1) Use GRED and crop the figure when saving it.
2) Use SIGHT. Save the figure you create and then read it
into GRED and crop it. *** I don't recomment this
solution. The ability to pass .UIS files back and forth
between SIGHT and GRED probably won't always be around.
Also, once a SIGHT file has been read into GRED it is
changed a bit. If you try to work on it in SIGHT again you
may have problems. ***
3) Use SIGHT. Create your figure so that it takes up
the whole screen. Save it that big and then use
RENDER/SIZE to reduce the graphic to the size you want.
There is more information on this subject in the
CLOSET/VAXUUM::DOC_GRAPHICS (GRED) and SARAH::SIGHT notesfiles.
Lance
|
| 774.11 | Graphics inclusion is still in its infancy | VAXUUM::DEVRIES | M.D. -- your Device Doctor | Thu Aug 13 1987 13:42 | 26 |
| RE: .9 (will it always be so...)
Basically, the only way to "bullet-proof" VAX DOCUMENT against passing
a graphics file that doesn't behave properly would be to implement a
complete LN03 emulator in our software -- and that we are, uh, reluctant
to do.
It's analogous in the programming world to writing a program in
a high-level language (or even a low-level one) and then calling
somebody else's assembly language routine. You've got to trust
that their routine stays in the expected address space, doesn't
muck with the wrong registers, etc.
I'm sorry, but that's the state of things now. We can just provide
ways to incorporate (hopefully) well-behaved diagrams prepared by
tools that were never intended to create encapsulated graphics.
Indeed, the notion of compound documents for the masses didn't even
exist when many of these tools were created.
For the future, these concerns are beginning to be considered.
In the PostScript world, there are cooperative efforts under way
to define a well-behaved protocol for included graphics. VAX DOCUMENT
V1.0 doesn't do much yet to help here. This is, in my mind, a high-priority
item for the "next version".
--Mark
|