Conference vaxuum::document_ft

    
    It was removed to (1) be more consistent with existing <FIGURE_SPACE>
    and <EXAMPLE_SPACE> tags and (2) to be able to check for errors
    better. It worked before only because the entire argument was passed
    to TeX. This was okay as long as the units (cm, in, etc) were specified
    EXACTLY as TeX would understand. Any deviation caused errors in
    TeX that were very unfriendly.
    
    patti
    

    Will sites be able to select which value the numeric value is measured
    in? Here in the states we use INCHES but on the continent they use
    CM.  Sounds like some thought needs to be given here to accounting
    for internationalization requirements for this particular (and others)
    value. What you had before solved the problem.  Now, the problem
    may not yet have a solution.
    
    jack

One related issue, has the position of the figure in relation to the
captions and/or rules changed at all?  It seemed that even if there was
a rule below the caption, that the vbox for the <FIGURE_FILE> started
at the baseline of the caption.  This appeared to be the case for BL6,
but I can't say that I've tried it for BL7 to see if its changed.

-tl

    
    In BL7, the numeric value is expected to be in picas, only.
    That's an interesting point about the international use of units;
    perhaps picas are used internationally (?)
    
    The examples in the documentation still show units, not just numerics,
    and therefore are wrong. They will be fixed for Version 1 release.
    
    -Barbara Corman 

    Re units of measure:
    
    Perhaps we could follow the lead of Adm. Hopper's and use picoseconds.
    
    kh

    
    Re: .3
    
    You can get around this in Baselevel 7 by putting a <FIGURE_SPACE> tag
    between the <FIGURE> and <FIGURE_FILE> tags. Adding just a couple of
    picas with the <FIGURE_SPACE> tag at that point should make it look
    good. You can also add whitespace to the top of the graphic itself
    using the workaround in note 648 of the DOCUMENT notesfile.        
    
    
    				Lance

    I've just started creating templates for cropping our DOCUMENT bound
    GRED illustrations, and have run across a problem.  DOCUMENT puts
    some awfully funny spacing around figures.  
    
    For example, I created a figure with a vertical height of 10 picas 
    (which was also the height I cropped it to).  I included it with the 
    <FIGURE_FILE> tag and specified 10 as the vertical size.  I then
    processed the file through the Software.Reference doctype.  
    
    What I got was the figure positioned between two horizontal bars
    (as expected), but there is 2 picas of space from the top bar to
    the top of the figure, and only .5 pica from the bottom of the figure
    to the bottom bar.  I've tried this with a few other doctypes as
    well, and the spacing is not always consistent from one to another.
    I also tried using the <FIGURE_SPACE> tag as mentioned in some previous
    notes, and messing with the vertical size spec in the <FIGURE_FILE>
    tag, but without success.  The <FIGURE_SPACE> tag won't accept any
    number less than 1 (like .5), results *seem* to be unpredictable,
    and the mental gymnastics required to figure how much space to take out
    of the <FIGURE_FILE> tag, and add with the <FIGURE_SPACE> tag is
    just too much to go through for 3,000 figures.
    
    May I suggest that this be corrected for the Field Test Update?
    I would like to see a spacing of 1 pica above, and 1 pica below
    each figure, and have this spacing consistent from doctype to doctype.
    If the spacing suggested doesn't work for everyone, I'd be glad
    to go along with a consensus, just as long as the space above and
    below the figure is *fairly* equal (if unequal, there should be
    more space below than above), and the spaces are between 1 and 2
    picas. 

    Thanks,
    
    -- Craig

    Although the <FIGURE_FILE> tag accepts vertical size arguments other
    than whole numbers (i.e. 14.6), my tests show that it really just
    ignores the decimal (14.6 would leave the same space as 14).  In
    other words, <FIGURE_FILE> requires that all artwork be an even
    number of picas tall; which is simply unrealistic.
    
    This, along with the problem mentioned in the previous reply, makes
    it impossible to get good looking, and consistent spacing around 
    figures.  Could someone from CUP Engineering please respond and
    let us know if, and when this might be fixed?
    
    Thanks,
    
    -- Craig

    ... that if DOCUMENT will just handle vertical height arguments
    with decimals I can take care of the rest with procedures and cropping
    templates within GRED.
    
    What I ran across is that in most of our books we use little art
    numbers in the lower right of each figure.  So, if the art number
    sits on a line .5 picas below the bottom of the drawing, and DOCUMENT
    leaves .5 picas after the figure, the spacing comes out just right
    (below the figure that is).  Sites or customers that don't use art
    numbers can just crop their figures with .5 picas extra white space
    on the bottom (or more if they like).
    
    To get the spacing above the figure to come out right I've been
    subtracting 1 pica from the height of my crop box, and using that
    for the vertical size argument.  This works great for figures where
    the crop box is in whole picas, but figures with decimals in the
    height argument end up being shorted by the amount of the decimal.
    
    Examples:
    
    crop box size	vertical space argument	      space above figure
    --------------------------------------------------------------------
    14 picas		13 picas		      1 pica (just right)
    14 picas		14 picas		      2 picas
    14.7 picas		13.7 picas		      .3 picas  
    14.7 picas		14.7 picas		      1.3 picas

    Unless someone can think of a more elegant solution, I think getting
    DOCUMENT to recognize decimals in <FIGURE_FILE> would allow
    the most control, yet at the same time offer the most flexibility. 
    

    Gutentag will only take a height of 46 picas, however, when
    I use software.reference and us <figure_file> I get one or
    two lines of text below the figure.  I would be nice to specify
    a full figure for <figure_file>
    
    Thanks
    jim amend
    8625::amend
    522-2351
    

    Yes, I've noticed the 46 pica limit as well.  In the GENERAL doctype
    a much larger figure would fit, but Gutentag won't take any number
    larger than 46.  However, in the SOFTWARE.HANDBOOK doctype, a 46
    pica figure won't even fit on the page but Gutentag still thinks
    the limit is 46.
    
    -- Craig

    
    I didn't reply to the earlier note because I needed to check with
    our local graphics people to see what the effect would be to
    change <figure_file> to pad 1pc above and below each graphic. (I
    really liked this solution because it is consistent with the
    2pc pad we do on <figure_space> and I was reluctant to change
    <figure_space> because of the impact on existing files.)
    
    Anyway, that is my proposal, though I haven't had time to understand
    all the repercussions in order to get this into the FT update. I
    do still need feedback on whether it sounds reasonable to everyone?
    
    I *did* change the figure tags for the FT update so that they do
    not truncate decimal points, so measurements that have decimal points
    will be preserved. I also changed <ICON_FILE> so that *no* padding
    occurs for these.
    
    In selecting a 'max height' I hoped to get a value that was reasonable
    for all types. I do do without checking the value at all at the
    SDML level, since the TeX macros themselves do the appropriate thing,
    along with issuing a message, if a space is too big for a page.
    Should I just stop the checking?
    
    Also, there is a tag (not documented, reserved for future use as
    needed) that you can use to change the value 46. If you put
    
    <set_max_figure_depth>(num)
    
    in a file that you include from the command line or wherever, it
    sets the counter value that is checked in <FIGURE_SPACE> and
    <FIGURE_FILE> tags.
                     
    
    -patti
    

    Those sound like workable solutions Patti, thanks.  
    
    I would like to see a lot of response here to Patti's question.  
    What do we want the <FIGURE_FILE> pad size to be?
    
    Here's my proposal.  If possible, I'd like to differentiate between
    doctypes that put rules above and below figures, and ones that don't.
    The other thing I'm taking into considerartion is the use of art
    numbers.  Anyway, on doctypes with rules I'd like a 1 pica pad above
    and a .5 pica pad below.  On doctypes without rules, a 1 pica pad
    above and below looks nice.*
    
    If it's not possible to vary the pad from doctype to doctype, then
    I would opt for the 1 above/.5 below version.  It's usually easy
    to add space below a figue (such as how the figure is cropped in
    GRED), but tought to remove it if added by DOCUMENT.
    
    The fix to allow the figure tags to accept decimals is great, as
    is the "max height" tag.  This is the kind of control we need.
    However, I'd like to figure a way to set the max height once for each 
    doctype and always have it take effect, rather than having to 
    include the tag each time.  Anyone have any thoughts as to how this
    could be done (we'll need a different setting for each doctype)?

    *Note:
     Here's how I came up with this spacing.  We're using the smallest
     font in GRED, scaled to 75% for our art numbers.  Positioning this
     number with its baseline 8 points below the bottom of the art looks
     nice to me.  If document left .5 pica after the figure this would
     add up to 1 pica 2 points below the figure.  With 1 pica above
     the figure it looks nicely placed.  Figures that have no rule below
     them seem to need a bit more space to keep them from looking too
     close to the text, therefore the extra .5 pica for doctypes without
     rules.

    So, what do you all think of this?  I relaize that in many groups,
    the graphics people don't read this conference.  If that's the case
    in your group it would be nice to turn them on to this discussion.
    Hopefully we can get this issue resolved quickly so Patti can tune
    up DOCUMENT.  Also, as soon as a clear definition of how DOCUMENT
    will handle this is available, I plan to create GRED cropping 
    templates for most of the doctypes.  If anyone is interested in this
    sort of thing, send MAIL.
    
    -- Craig

    
    I'd like to put in my vote for keeping the amount of padding
    DOCUMENT does automatically small. One pica above and below
    sounds reasonable.
    
    White space can always be added above the figure with a
    <FIGURE_SPACE> tag, and below the figure by increasing the
    space parameter in the <FIGURE_FILE> tag. As Craig points
    out, it's not so easy to remove space DOCUMENT puts in. 
                                                  
    
    				Lance

    How about this guys?
    
    Make the default 1 pc and allow it to change by the use of another
    undocumented and as yet unimplemented tag -- 
    [like <set_max_figure_depth>(n)]. 

    We could call it <set_figure_padding>(n) where n = {1,2, or 3} allowing
    for up to 1/2 in.
    
    Regards.

    User selectable padding sounds great, as long as the "n" value can
    be specified in points (12 points to a pica), or some other very
    small increment (i.e. 10ths of a pica, but I don't know of any rulers
    that measure that way).  It would also be necessary to be able to
    specify values for padding above, and padding below.  Note in my
    previous reply how the use of art numbers requires more padding above 
    the figure.  Customers would probably like this as well since it
    make DOCUMENT flexible enough to work in any application.
        
    re. .14 - Yes, let's keep the default padding value small.  If we
    have to go with the same space above and below, and it's not user
    selectable then how about half a pica.  This would make the art
    number thing work out.  One question though, can <FIGURE_SPACE>
    add space below a figure as well as above?  I just realized that on 
    some illustrations we won't have the option to add space by cropping - 
    I'm thinking of bitmaps and files from other systems that don't have 
    cropping abilities.  User selectable padding sounds better all the time,
    as long as we can select different values for padding above and
    below, and do it in very small increments (thanks for the suggestion
    Jerry). 

    -- Craig

    Beware of using a phony size argument to <FIGURE_FILE> to
    get extra space below the figure.  With PostScript, you'll get the
    extra space ABOVE the figure.
    
    DOCUMENT does not interpret the included graphic, and does not know
    how big it *really* is.  It just leaves the size you asked for,
    plus whatever white space the doctype provides.
    
    Since printing on the LN03 is a "top-down" operation, we position
    at the top of the figure area (after any up-top white space built
    into the doctype), pass through the sixel graphic file,
    and position at the bottom of the area according to the size you
    provided (plus any white space built into the doctype).
    
    On PostScript devices, however, printing is "bottom-up".  Therefore,
    we position at the bottom of the figure area you specified, pass
    through the PostScript graphic file, and continue from the bottom
    of the area (plus any white space built into the doctype).

    md

    Not wanting to bring up religion again, but shouldn't this stuff be
    doc-type specific?  It seems to me that the graphic should be cropped
    to its true boundries and any spacing requirements should be specified
    in the DTP file and not by users in the GNC file.  Is there some
    particular need that requires variable graphic positioning in a
    single document?


    -tl

    Re: .18
    
    I would prefer to have figure spacing taken care of in the DTP files.
    However, we (and many other groups I would imagine) want to use
    CUP supported doctypes rather than hack them up for our particular
    application.  We've been bitten before by doing this.
    
    Also, there are many different systems used to generate graphics,
    and many ways graphics are treated in different kinds of documents.
    
    I think it might be tough to get all the groups using the CUP doctypes
    to agree on a standard spacing for each.  For instance, I don't think 
    a group including figures that need no art numbers, and generated by 
    a system with no cropping ability, would like my "1 pica above, .5
    pica below" proposal.  In fact, our engineers use DOCUMENT to do their 
    specs, and have that exact situation.  A different doctype would be 
    required to make their figure spacing  look correct.  We could end up 
    with an awful lot of doctypes, and that's just at our site.
    
    Perhaps there could be a "supported" way to handle this problem
    at the DTP level?
    
    -- Craig