Conference vaxuum::online_bookbuilding

    Hi Diane,
    	I believe we've fixed this problem.  But, if you could, would you
    send me a small .SDML file that demonstrates the problem?  
    
    	Also, what version of the bookbuilding tools are you using?
    
    Thanks,
    	Wayne

    RE: .0.
    
    1. Spacing between words: this is an unfortunate side effect of
       positioning hotspots in such a way that supports both the
       75 and 100 dpi monitors (the basic problem is that fonts are
       *not* monitor independent). Some improvements have been made
       for V1.2B and this problem should not occur as frequently.
    
    2. Spacing between paragraphs: as Wayne says in .1, this should be
       fixed in V1.2B. If you continue to have problems under 1.2B, send
       or post a small .SDML that reproduces it. (Is the tag after the
       <figure> a <cp>?)
    
    Thanks,
    
    Mary

    We are running 1.2a.  I have been told that we will probably not
    be running 1.2b for another couple of weeks or so.  So if you
    feel this problem has been fix in 1.2b then it would not make sense
    to forward you a .sdml file at this time.  The books are not due
    to go on tape until March 28th.  I can sit on them for a while.
    I'll let you know if the probably still exist on 1.2b.
    
    Thank-you both for responding.
    
    Diane

Hi,

We are running 1-2B and I ran a book yesterday to make sure that everything
was working.

I got the book to run and scanned through it quickly. I did notice a case
of no space between words.

         ...to the calling routine insdb_
address.

This is coded as in <emphasis>(sdb_address\bold) in a <routine> section.

Will send file if anyone wants it.

Ruth-Ellen

    RE: 271.4
    
    Ruth-Ellen,
    	Would you please send me a short .SDML file that exhibits this
    problem?  I'll take a look at it for you.
    	My first guess is that this is caused by the change to bold font
    for the emphasis.  Font changes, especially when they're located to the
    right of the window, tend to shift text.  But, I won't know for sure
    until I see it.
    
    Thanks,
    	Wayne

    Ruth-Ellen,
    	After testing the file that you sent, I found that my first guess
    was correct.  The problem is caused by the font change from normal to
    bold near the right side of the window.  I tested it by removing some
    of the text and making the offending font change appear nearer the left
    margin and it looked OK.  I'm not suggesting that that's a workaround. 
    That's just the way I tested the file.
    
    	This is a regrettable technical problem with the output device (and
    one which will be solved eventually).
    
    Wayne

    Wayne,
    
    When I first initiated this note I thought the lack of space between
    words was just when there was a reference tag.  Now I see it when
    there is an <emphasis> tag (both bold and italics).  I don't understand
    what Mary meant by dpi, and monitors.  If this is appearing in V1.2b
    also, is this a bug and something we have to live with?  If so,
    could someone explain to me in English why it is really happening
    so I can explain it to the editor  and convince him/her and myself
    that there really is nothing that can be done.  
    
    Appreciate any comments or suggestions.  
    
    Diane

    See notes 148.7 and 204, under "hotspot alignment." Note 204 is
    an especially good explanation of the problem. Although it
    refers only to hotspot alignment, the problem with word spacing
    when the font changes is exactly the same problem.
    
    Mary

    Hi,
    
    So is this a bug that we have to live with and work around. It seems
    like an awful big problem that is not going to make it easy to make the
    book readable online.
    
    Sounds like I have to rewrite sentences so that the bold doesn't come
    at the end of a line in the bookreader... but looks fine in hardcopy.
    
    Ruth-Ellen

    Would an align_char do as a workaround - to avoid the sort of
    re-writing that .-1 mentions?
    
    b

    <align_char> might work -- anybody wanna try this? BUT it could produce
    unnacceptable output for hardcopy...(too much space maybe).
    
    I would *not* suggest rewriting around this problem to get the output
    to look the way you want. The first tiny modification you make after
    the rewrite-that-works will blow the workaround up. DOCUMENT is
    designed to take the formatting out of the hands of writers, so it
    would be very difficult to make this work in all cases for all
    versions. Read 'very difficult' as meaning 'a real waste of your
    time.'
    
    I suggest living with it. New technology does not spring full blown
    from the heads of developers. There are always bugs/glitches/things-
    that-are-not-as-we-want-them. That's life. That's also fonts -- this
    is one area that DEC (or almost anyone) does not have a good handle
    on and causes all kinds of headaches. We try not to pass the headaches
    on to you, the poor underpaid and overworked user, but sometimes it
    is unavoidable. This particular problem is one that we want to fix
    as badly as you want to see it fixed and we have some ideas for how
    to do so. But it's not trivial to fix; it will probably mean
    significant changes to several components of DOCUMENT and the
    Bookreader. Given that, and our resource constraints (you knew that
    was coming, right?), it won't happen for Bookreader V3.
    
    As mentioned, this is a regrettable side effect of having to support
    two different-resolution monitors in DECwindows, which means, in
    effect, formatting for two different fonts at the same time. It's sort
    of like trying to output a single file that can print on both PS and
    LN03 printers: device-independence is still a utopian dream, I'm
    afraid.
    
    So, I personally would not lose any sleep, much less coding time, over
    this problem.
    
    Mary

    Hi,
    
    Any updates to this note? Will DECwindows Version 3.0 fix this problem?
    
    I solved this problem by using conditional text for hardcopy and online
    and used the <align_char> tag or just put in an extra space in the
    <emphasis>() tag. Worked okay, but meant extra coding.
    
    Ruth-Ellen

    No, DECwindow V3 handles fonts the same way as DECwindows V2.
    
    Suggest that  you submit a requirement to the Bookreader
    engineering team. They have a notes conf for that purpose:
    DECWET::BOOKREADER-REQUIREMENTS.

    Uh? I thought fixes to known bugs were a sort of unwritten requirement
    on all products. Or maybe this isn't a bug; it just happens to look bad.
    
    b

    We could probably quibble forever about whether it's a bug or not.
    
    The problem occurs because the Bookreader must position text as well as
    possible on both the 75- and 100-dpi monitors. Different resolutions
    mean different font metrics, and we format for only one set of font
    metrics. The Bookreader does the best it can; it's not perfect. 
    
    There would be no positioning problem if books were built and shipped
    for each resolution, but no one thought it was acceptable to ask
    writers to build multiple online versions of their books or to ask
    manufacturing to ship multiple online versions.
    
    Mary