Conference vaxuum::online_bookbuilding

    1. Scaling graphics down results in poor resolution: This is not a
       DOCUMENT or Bookreader bug; it is a function of the screen
       resolution, which at this time is very low: 75 or 100 dpi.
       If you scale a graphic down 25%, you lose 24% of the dots. At
       a low resolution of 100 dpi, this is *very* noticable, to the
       point of, as you say, being unacceptable output. At 600 dpi
       (PS printers), you probably don't notice it at all. 
    
       The only solution (short of waiting for higher resolution monitors),
       is to create the graphics such that they do not need to be scaled.
       I realize this is not an acceptable solution in many cases.
    
    2. Unacceptable margin text and graphics: We are extremely constrained
       for screen real estate in the Bookreader, and that is not likely
       to change (at least not in the near future). As a result of those
       constraints, we made the design decision (it was actually forced
       on us) not to use wide gutters or leave much white space in the
       left margin at all. <margin_note> and <margin_icon>, therefore, place
       their text and graphics *above* the accompanying text rather than 
       next to it, as in hard copy. For small graphics and short pieces of
       text, this seems to work OK. Large graphics (or graphics that are
       drawn large and scaled down, thereby running into problem #1 above)
       and long segments of text do not work well, or often at all.
    
       I don't see a good solution for this one. I thought about making
       the margin stuff pop up, but I think that would be more of an
       annoyance than anything else. I'm open to any suggestions that 
       anyone has...
    
       Also maybe other readers of this notes conference have some
       suggestions for treating margin notes and art online?
    
    Hope this helps,
    
    Mary

>1.  Currently when we create graphics that are acceptable for the hardcopy  
>books, when they are displayed in the bookreader, they are huge.  If writers
>shrink the graphics down so they aren't gigantic on the screen, then the 
>resolution is not very good.  (I can show you some examples of this in Version 
>1.0 DECdecision documentation.)  Do you see a solution for this problem 
>in the online doc type used with the Bookreader for DECwindows V3.0?

What do you mean by "huge"? Do you mean the online graphics are the same
size as the original screen (if you're using screen captures)? If so, read
on.

Mary (.1) is correct.  When you shrink a screen capture image down, things
look bad real fast.  This is not a software problem.  This is an inherent
limitation of the system, in this case, the number of pixels in an object in
relation to the hardware resolution.

First, you have to understand that the resolution of a device (screen,
printer) is constant and is determined by the hardware.  Images are composed
of pixels.  Your typical screen characters are composed in a grid of 6x6
pixels.  If you have an image and you want to scale it down to, say 50% of
the original, something has to "give" in order to make it smaller.  Since
you can't make the pixels smaller (that's a hardware constant), you have to
recreate the image using fewer pixels.  If you scale a 6x6 grid down by 50%,
you wind up with a grid of 3x3 pixels.  It's nearly impossible to create a
recognizable character with a 3x3 grid - it just plain looks terrible.  Try
it yourself.  Draw an 6x6 grid and fill in blocks to make a letter.  Now,
try to draw that letter using a 3x3 grid - can't do it.  That's why it looks
bad when images are scaled down and viewed on the screen.

"So, why can you shrink an image and print it to a printer and it looks
good?" The printer has a higher resolution than the screen - typically,
about 4 times the resolution.  That means that the printer's pixels are
smaller and it uses more pixels to make up a letter the same size as one on
the screen.  If the screen was 75dpi and a character occupied a 6x6 grid, a
300dpi printer would use a 24x24 grid to create a letter of the same size.
Because there are more pixels in relation to the size of the character, you
can afford to throw out pixels in the printer version and still recreate the
character in recognizable fashion.  If you scaled down by 50%, you'd wind up
with a 12x12 grid on the printer, which you CAN realistically recreate the
character in.  Therefore the scaled printed version will look much better
than the scaled screen version.

This is a limitation that we all have to live with.  The options, until
someday they invent higher resolution displays, is to

1).  Make the objects the correct size before you make the screen capture
(ie.  resize the windows and make them smaller before capturing)  

2).  Use the graphics at full size - maybe put them in popup windows.

3).  Scale them down and take what you get.

Not attractive, but there's little that anyone can do about it.
Hope that helps.
-Mike

    Re margin icons -
    I don't see why Mary (.1) thinks popups would be an annoyance; they
    sound to me like a very neat way out of the space problem. Also, they
    allow the user to see margin text next to some body text - just as
    in hardcopy, but with the added flexibility of being able to move
    it about.
    
    What I imagine you may mean, Mary, is that what would be
    annoying - if Janet conditionalized her files to put a few
    <ONLINE_POPUP> in them - would be the implied message
    `There's some crucial extra text here, but you'll have to click
    somewhere if you want to see it'. That's true only if you
    tie the popup to a hotspot (the way popups have always been).
    
    Why not make the popup in this case happen willy nilly for all the
    <margin_...> tags when the destination is BOOKREADER? (I won't be
    surprised if there are big implementation drawbacks here, but I
    wouldn't like to think that that we were missing an easy trick just
    because of the assumption that you can't have a popup without a
    hotspot - which may well be true, the way things are at the moment.)
    
    
    b

    re .3: Yes, Bob, that's exactly what I thought. As we do popups today,
    the user would have to click on each one and they don't always come up
    where you might like them (various other notes and notes conferences
    have made this complaint). If there is lots of margin stuff, the
    constant clicking and (probably) moving of hotspots could be *quite*
    annoying. 
    
    There would be implementation issues in automatically popping up the
    margin notes and graphics but it's appealing and worth some thought.
    I think it would be very little work for DOCUMENT but it would mean
    new Bookreader functionality to know which hotspots were to be popped
    up automatically with the text and (and this may be the really hard
    bit) positioning them properly on the screen. Such new functionality,
    if done at all, would not be done until after Bookreader V3, so there
    still is no easy, quick answer for Janet.
    
    Also, because of the problems with scaling (see .2), the 'margin' art
    might still be either unacceptably large or unacceptably distorted by
    scaling.
    
    Thanks,
    
    Mary

Something that seems to be overlooked sometimes...

When you do a screen capture of a window, all you have to show is the
pertinent section of the window. I've seen docs that have a huge figure
(full-page) when all the figure illustrates is the menu bar, or a single 
pull-down menu. There's nothing wrong with cropping the window. I think this is
better than resizing it.

    RE .0 --

>My understanding is that the online doc type should allow us to use one
>set of sdml files for producing online and hardcopy docs. Currently, due
>to these 2 bugs, this is not the case. 

    You shouldn't have to have more than one set of SDML files --
    you could conditionalize the margin icons, etc...

						-- Nina

    RE .6: It's even easier than that (conditionalizing) for <margin_icon>
    --  simply omit the tag that specifies Bookreader output and the margin
    icon will not appear online. This is what the DECwindows doc group did
    when they realized how big some of their 'margin' graphics were going
    to be. They further decided that the margin icons were not as
    necessary online as for hardcopy, because there you were, sitting right
    there in front of the interface. I don't know if that observation is
    appropriate for your documentation, but I thought I'd report on one
    group's take on this problem.
    
    Mary
    

We found the same solution as .7 for the OPS5 docset, but arrived there on a
different path.  We built the manual for bookreader with _no_ margin art,
to start with.  Looking at the first online version, we decided it looked 
rather dull.  So then we added <margin_icon>(bookreader ...) tags for
_selected_ margin art.

Works great, looks fine.  No error messages.  Coming soon on a disk near you.


Pilar.