| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 887.1 | Includes_file wasn't intended for Figure_file | VAXUUM::DEVRIES | M.D. -- your Device Doctor | Wed Sep 09 1987 13:10 | 21 |
| RE .0:
> It seems that there is no way to run just the device converter and
> have included files, such as figures, brought into the output.
To clear up a misstatement -- you *can* run just the device converter
to incorporate files which are specified by the <FIGURE_FILE> tag.
The problem here has to do with files that use logical names defined
by the <INCLUDES_FILE> tag in a profile.
According to user's guide, the <INCLUDES_FILE> tag provides a flexible
way to specify <ELEMENT> names for use in bookbuilding. If this
technique has been working for <FIGURE_FILE> names, I'd consider
that an accidental side effect.
And for precisely the reason that logical-name based processing
has to start at the beginning of the chain, I'd expect the situation
to stay the way it is, unless we see a considerable overhaul in
the software machinery.
--Mark
|
| 887.2 | binding of names | VAXUUM::KOHLBRENNER | | Wed Sep 09 1987 14:23 | 37 |
| It seems to me that it is a question of when the logical name
is to used, that is when is it to be translated into its
equivalence name.
Currently, when you specify <includes_file>(logical\equiv) in a
profile and do a bookbuild, we do two things:
. issue a "$ DEFINE logical equiv" command which lasts until the
end of the bookbuild, hence it will work for either of
<include>(logical) which the tag translator acts on
<figure_file>(logical) which the device converter acts on
. store in the XREF file a reminder to repeat the DEFINE command
anytime that an element build is done.
We could change this behavior so that when the tag translator
saw <figure_file>(logical) it could translate the logical name and
pass the tag on as <figure_file>(equiv) to the device converter.
That would cause the logical name translation to occur in all cases
during the tag translator. THat would be a good solution for the
user who is simply trying to rerun from the device converter stage.
However, that would mean that the user who wanted to change the
equiv name before rerunning the device converter would not be getting
the new setting because the old equiv name would be locked into
the DVI file.
The question is when does the logical name get translated.
The question behind that question is when does the logical name
get defined.
And it is a lot of work to change what is now done.
bill
|
| 887.3 | Glad *I* don't have to write the documentation | VAXUUM::DEVRIES | M.D. -- your Device Doctor | Wed Sep 09 1987 15:47 | 31 |
| > We could change this behavior so that when the tag translator
> saw <figure_file>(logical) it could translate the logical name and
> pass the tag on as <figure_file>(equiv) to the device converter.
> That would cause the logical name translation to occur in all cases
> during the tag translator. THat would be a good solution for the
> user who is simply trying to rerun from the device converter stage.
That makes sense to me.
> However, that would mean that the user who wanted to change the
> equiv name before rerunning the device converter would not be getting
> the new setting because the old equiv name would be locked into
> the DVI file.
It still makes sense to me. Basically, this model is saying that
a particular instance of the book is frozen when you begin the
bookbuild, and partial processing of that instance of the book
will always work with the same pieces. That's a rational, defensible
position, and a lot more explanable than the current situation:
Well, now, you defined your elements with <includes_file>,
so they were resolved before your DVI file was ever built.
But you defined some <figure_file>s with DCL logical names,
and they continue to be variable until you run the device
converter, but you defined others with <includes_file>,
and now you can't use them at all unless you start the
bookbuild all over. Sheesh!
--Mark
|
| 887.4 | Still dreamin' | CUPOLA::HAKKARAINEN | This side up | Wed Sep 09 1987 17:11 | 20 |
|
Or, perhaps to make it simpler, if Document would accept default
file extensions for certain conditions, as has been requested before,
then the need for logicals could be reduced.
General text usage .sdml
<include>(foo) gets you foo.sdml in the current directory.
Postscript figure .post
<figure_file>(post\foo\14) gets you foo.post in the current directory.�
LN03 figure .ln03, .plus
<figure_file>(ln03\foo\14) gets you foo.ln03 or foo.plus in the
current directory�
There are probably better default extensions, but you get the idea.
�It would be really nice if we could get automatic inclusion of
figure files, such that Document will know to use the ln03 figure
when we're processing for ln03 output, similarly for postscript.
|
| 887.5 | Defaults don't help if there's no standard | CLOSET::DEVRIES | M.D. -- your Device Doctor | Thu Sep 10 1987 15:26 | 48 |
| Regarding default extensions: I'm generally cool on the idea of
relying too much on a *batch* system to do the right thing when
I've got so many degrees of freedom to derail it accidentally.
It's one thing for an interactive system to assume a default path,
and then tell me what it assumed (like LSE using a default filename).
It's a lot worse when a batch system chugs away for a half hour
or so, then you find out it included the wrong file. Nevertheless,
let's discuss default extensions:
For <include>, I suppose .SDML is a reasonable default. You
folks who use this feature know better than I.
For figures: those are created by tools outside the realm of
VAX DOCUMENT, and we have no control over their defaults.
There are no standard defaults at present, although I will
say this: for PostScript, .PS is very common, and we deliberately
picked .POST for our generated PostScript output to distinguish
it from PostScript graphics coded by hand or by other tools.
I strongly urge you NOT to use the extension .POST for PostScript
files you get from anyplace besides VAX DOCUMENT.
And for LN03 sixel graphics: there are a variety of extensions
seen in that world as well, and we picked .LN03 for our
generated LN03 output because it's different from the
other extensions we've seen (among other reasons). Please
try to reserve it for VAX DOCUMENT LN03 output and not use it
for files from other sources.
I believe .POST and .LN03 are registered with SQM as referring
to VAX DOCUMENT output specifically. And since these are the
extensions of our output files, if you try to use them for a
figure file that has the same filename as the output file,
we'll try to reopen the newly-created output file instead,
and will report that it can't be done. (That's already been
tried and reported elsewhere in this notesfile.)
> It would be really nice if we could get automatic inclusion of
> figure files, such that Document will know to use the ln03 figure
> when we're processing for ln03 output, similarly for postscript.
I don't understand the complaint. You put in one figure_file tag
that tells the filespec, size and alignment for the LN03 figure, and
another figure_file tag with the filespec, size and alignment for
the PostScript figure. Both figure_file tags go in the same SDML
file. Isn't this "automatic inclusion"? Isn't this "knowing to
use the ln03 figure for ln03 output, similarly for PostScript"?
--Mark
|
| 887.6 | But there are conventions ... | CUPOLA::HAKKARAINEN | I got plenty of Noting | Thu Sep 10 1987 16:33 | 37 |
|
Re .5
I wasn't aware that .ln03 and .post had been registered with SQM
for Document use. Agreed that some other extensions must be chosen.
Does Render have defaults for its output of Postscript, etc.?
> I don't understand the complaint. You put in one figure_file tag
> that tells the filespec, size and alignment for the LN03 figure, and
> another figure_file tag with the filespec, size and alignment for
> the PostScript figure. Both figure_file tags go in the same SDML
> file. Isn't this "automatic inclusion"? Isn't this "knowing to
> use the ln03 figure for ln03 output, similarly for PostScript"?
I'd like to get to the point that we have just one <figure_file>
tag for a figure. Document would call the appropriate file based on the
destination.
<figure>(My Fig)
<figure_file>(\foo\24)
<endfigure>
When processed for ln03 output, foo.six would be used. When processed
for Postscript, foo.ps would be brought in.
This solution is requested because we've encountered a number of cases
where a writer has just manaaged to re-render a whole bunch of files.
But, if the writer hasn't yet tracked down all of the figures
and added that second <figure_file> tag, the new graphics will not
be included.
Admittedly, this should not be high on the priority list. Nevertheless,
the <figure_file> is one of the few spots where device-specific
information is contained in the file. It would be neat to be able
to generalize the tag so the appropriate graphic is included,
irrespective of the destination.
|
| 887.7 | Beware of accidental defaults & different sizes | VAXUUM::DEVRIES | M.D. -- your Device Doctor | Thu Sep 10 1987 17:12 | 32 |
| If you could only enter one figure_file tag per figure, then all figures
would have to have the same file name. Many people might find that
constraining. And, of course, you'd run into the accidental default
case where you had a foo.sixel you wanted in your LN03 output, but
forgot about that foo.ps you didn't want in your PostScript output.
Of course, it would be possible to keep the current device-specific
approach and add the device-common approach. But that just makes
the user guide (and LSE environment) that much more complicated.
And I maintain that it would generally be bad practice to use the
same figure_file tag for different types of figures anyway, because
your sixel file may not be precisely the same dimensions as your
PostScript graphic. Even if the image area is the same, you may
want to use different values to change the adjacent white space,
since the sixel file prints from the top down in the space you specify,
while the PostScript file prints from the bottom up in the space
you specify.
And there *may* be features added in the future (no promises) to
let you manipulate the graphic file a little bit. Such features
would most certainly be device specific.
Perhaps the special case of updating all places that used foo.six
to add a PostScript reference could have been served just as well
with a DCL search of all pertinent SDML file directories for
"<FIGURE_FILE>(LN03: foo.six" or some useful equivalent. To open
up VAX DOCUMENT for this global search-and-replace type of function
is to create yet another degree of freedom (I'd prefer "degree of
uncertainty") for the system to trap the user in.
--Mark
|
| 887.8 | Render does not differentiate between devices | CRAYON::GENT | Party gone out of bounds -- B52's | Fri Sep 11 1987 09:05 | 13 |
| Re: .6
> Does Render have defaults for its output of Postscript, etc.?
The default file type for RENDER output is .REN, no matter what
the device type. So unfortunately, there is no precedence there.
--Andrew
P.S. There is quite a complete discussion about *why* Render uses
a single file type in either the SIGHT or UIS notes file, which
may or may not be relevant to this discussion. I'll see if I
can remember where I saw it...
|