[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::online_bookbuilding

Title:Online Bookbuilding
Notice:This conference is write-locked: see note 1.3.
Moderator:VAXUUM::UTT
Created:Fri Aug 12 1988
Last Modified:Mon Jul 15 1991
Last Successful Update:Fri Jun 06 1997
Number of topics:440
Total number of notes:2134

340.0. "DOCUMENT, BookReader, and DECwrite together?" by COOKIE::RJOHNSTON () Thu May 24 1990 00:02

This note moved from the DOCUMENT conference.

================================================================================
Note 2984.1  DOCUMENT, DECwrite, and BookReader - do they work together?  1 of 1
CLOSET::UTT                                          62 lines  23-MAY-1990 18:45
                                  -< sort of >-
--------------------------------------------------------------------------------
>> 1. Will Bookreader accept an SDML file that includes DECwrite figures?
>>    (i.e., does it have to be "pure" SDML or DECwrite file for
>>    it to work with BookReader?)
    
    At the present time, the Bookreader accepts only 2 forms of graphics
    files: RAGS metafiles and Xbitmaps (RAGS and UTOX generate FSE bitmaps
    (an internal DEC binary format) which are converted to Xbitmaps for
    Bookreader display). V2.0 of VAX DOCUMENT (soon to be in field test --
    you heard here first, folks!) will allow DDIF *image* files to be
    specified in <FIGURE_FILE>(BOOKREADER\...) tags -- they, too, will
    be converted to Xbitmaps. So, if you have a DDIF image produced
    by some DECmumble graphics utility *and* you are using V2.0 of VAX
    DOCUMENT, you can include it in your SDML files for Bookreader output.
    
    BTW, DECwrite makes the same conversion we make for DDIF images.
    
    You can also use UTOX to convert your DDIF images to FSE binary format
    and then include that file in your SDML tags.
    
    Future versions of the Bookreader will accept other graphics formats,
    such as Encapsulated PostScript.
    
>> 2. I have heard that DECwrite files on BookReader have poor resolution;
>>    if it's true, what are the plans for fixing it?
    
    *Monitors* have poor resolution, not authoring tools. DECwindows
    monitors are either 75 or 100 dpi, which are very low resolutions,
    and we all have to live with them.
    
    The DECwrite-produced online books that I have seen, in many cases,
    have not used styles designed specifically for online display. So,
    the fonts may be too small or not the most-readable possible. I have
    seen some DECwrite-generated books that look almost as good as ours.
    (biased? moi? :-) We (CUP Engineering) have been in the online tools
    business for years now, and have worked hard and gained a lot of
    experience in formatting for the screen. The DECwrite->Bookreader
    functionality was added in the past 6 months and I think they are
    still working on developing online styles, and that is the cause of
    the differences in "resolution" that you are seeing. 
    
    There is no reason they can't develop an online style that is
    *exactly* like ours, except in one respect -- because of DDIF
    restrictions, DECwrite-generated Bookreader output is *page*
    oriented (i.e., they use fixed-size pages online), whereas 
    DOCUMENT fully supports Bookreader's topic-oriented capability.
    In all other respects, they have the same fonts and the same cruddy
    resolution available to them that we have available to us...
    
    Both DECwrite and DOCUMENT use the same programming interface to
    generate Bookreader files, a set of routines you may have heard
    referred to "Bookwriter."
    
    As for accessing ONLINE_BOOKBUILDING, make sure you are accessing it
    via CLOSET (not VAXUUM). You should have better luck that way.
    
    Thanks,
    
    Mary
    
    
    
    
T.RTitleUserPersonal
Name
DateLines
340.1Clarify a few points, please...COOKIE::RJOHNSTONThu May 24 1990 00:1237
Mary,

I am woefully ignorant about DDIF, bitmaps, etc.  But let
me see if I understand you correctly:

o When DOCUMENT V2.0 comes along, we *will* be able to get
  BookReader output from an SDML file that sucks in DECwrite
  figures.

o Eventually BookReader will also accept Encapsulated Postsript,
  such as that produced by PSART.  (what's the time line for
  "eventually"?)

o You can get BookReader output from the current version of
  DECwrite (V1.1?).

Also, I'm not sure what you meant by this:

    "...because of DDIF restrictions, DECwrite-generated Bookreader output 
    is *page* oriented (i.e., they use fixed-size pages online), whereas 
    DOCUMENT fully supports Bookreader's topic-oriented capability."

Are there some implications here (that I need help recognizing)
if I use DECwrite and DOCUMENT together?  For example, does this
mean that a DECwrite figure could not appear on the same screen
as SDML-coded text?  All figures would need to be pop-up? Something
else? 

Thanx,

Rose

P.S.  Can someone give me a pointer to the DECwrite conference?
      I need to do some searching about drawing railroad diagrams
      with it...    

340.2clarifications (hopefully)AIRBAG::SWATKOElectrons are cheap. Trees are not.Thu May 24 1990 15:4964
>I am woefully ignorant about DDIF, bitmaps, etc.  But let
>me see if I understand you correctly:
>
>o When DOCUMENT V2.0 comes along, we *will* be able to get
>  BookReader output from an SDML file that sucks in DECwrite
>  figures.

No.  DOCUMENT V2 will be able to take in three things as bookreader figures:

- DDIF *image* files, such as can be made with DECpaint, PrintScreen, UTOX,
	RAGS.
- FSE bitmaps, made by UTOX or RAGS

- RAGS drawings.

DECwrite is unable to produce any of these types of files.  DECwrite makes
only DDIF compound documents.  DOCUMENT will NOT be able to take in DDIF
compound documents.  DECwrite also can make PostScript, but it is not
Encapsulated PostScript.


>o Eventually BookReader will also accept Encapsulated Postsript,
>  such as that produced by PSART.  (what's the time line for
>  "eventually"?)

The new bookreader supplied with the next DECwindows release will be able to
use Encapsulated PostScript figures made by any tool.

>o You can get BookReader output from the current version of
>  DECwrite (V1.1?).

Yes, although there are a few differences between DECwrite-produced online
books and DOCUMENT-produced online books.  DECwrite OLBs (online books) are
essentially snapshots of DECwrite pages - ie.  same fonts, sizes,
formatting, etc.  DECwrite OLBs are page oriented like they appear in
DECwrite, not topic oriented like general OLBs.  "Links to Images" in
DECwrite will work for bookreader figures in DECwrite-produced OLBs, but
"Links to Drawings" and object oriented drawings in DECwrite will not make
it into DECwrite-produced OLBs.

>Also, I'm not sure what you meant by this:
>
>    "...because of DDIF restrictions, DECwrite-generated Bookreader output 
>    is *page* oriented (i.e., they use fixed-size pages online), whereas 
>    DOCUMENT fully supports Bookreader's topic-oriented capability."
>
>Are there some implications here (that I need help recognizing)
>if I use DECwrite and DOCUMENT together?  For example, does this
>mean that a DECwrite figure could not appear on the same screen
>as SDML-coded text?  All figures would need to be pop-up? Something
>else? 

You cannot use DECwrite to make figures for use in DOCUMENT-produced OLBs.
DOCUMENT only takes FSE bitmaps or RAGS drawings as figures for the
bookreader, and DDIF images in V2 DOCUMENT.  DECwrite is unable to produce
any of these.

>P.S.  Can someone give me a pointer to the DECwrite conference?
>      I need to do some searching about drawing railroad diagrams
>      with it...    

QUEEN::DECWRITE

-Mike
340.3But you _can_MARVIN::KNOWLESintentionally Rive GaucheFri May 25 1990 08:1437
340.4Online books always limited by screen resolutionAIRBAG::SWATKOElectrons are cheap. Trees are not.Fri May 25 1990 15:1314
True, you can always do screen captures.  My point was that there is no
direct route to use DECwrite produced figures in DOCUMENT-produced online
books.

>    Purists may think that this route makes for poor resolution, but it's
>    good enough for me (and it's a lot better than nothing).

If you're just interested in bookreader books, then there's nothing wrong
resolution-wise with the method you described.  Whatever you display will be
limited by the screen's resolution anyways, so if you're using a capture at
screen resolution, it's just as good as anything else.  Hardcopy is a
different story though.  You will notice the jaggies in hardcopy.

-Mike
340.5Ita veroMARVIN::KNOWLESintentionally Rive GaucheTue May 29 1990 07:4612
    Right Mike - I just didn't want people to get the message that
    graphics produced in DECwrite could never make it onto Bookreader.
    
    You're right too about noticing the jaggies in hardcopy.  Luckily,
    you can write the print file (postscript) straight out of DECwrite -
    then, with a bit of fiddling to get the placement right, you can
    call in the <figure_file> to your .sdml file.
    
    So .sdml and DECwrite can live with each other after a fashion, though
    it's not an ideal relationship.
    
    b
340.6Time to UTOX? Jaggies? What Jaggies?COOKIE::RJOHNSTONFri Jun 01 1990 17:5020
RE: .3 

Is the process you go through a difficult (tedious) one?  Or
after you get used to it, does it go rather quickly?

RE: .4 & .5

The "jaggies" you refer to - I lost something in the context.
Do you mean "jaggies" when producing syntax diagrams, and
do you mean specifically the output when capturing a screen?

One of the writers that works with me has been experimenting
with DECwrite to do syntax diagrams.  Using "snap to" and
reducing some text, I think it's getting to look pretty
darn good on hardcopy (looks very acceptable online).

He hasn't tried capturing a screen with it yet.

Rose
340.7Does DECwrite Pop-Up?COOKIE::RJOHNSTONFri Jun 01 1990 17:547

What about popping up DECwrite figures that are in DOCUMENT file?

Can you do that?

Rose
340.8Quick answersMARVIN::KNOWLESintentionally Rive GaucheMon Jun 04 1990 08:5719
340.9DECwrite graphicsOLD::UTTMon Jun 04 1990 11:1228
    RE: .7 and .8.
    
    Bookreader doesn't care how you drew the figures but it *does* care
    what format they are in: Bookreader V2.0 and DOCUMENT V1.2B support
    RAGS metafiles and FSE bitmaps for online graphics. As stated in
    .2:
    
>>DOCUMENT V2 will be able to take in three things as bookreader figures:

>>- DDIF *image* files, such as can be made with DECpaint, PrintScreen, UTOX,
>>  RAGS.
    
>>- FSE bitmaps, made by UTOX or RAGS

>>- RAGS drawings.

>>DECwrite is unable to produce any of these types of files.  DECwrite makes
>>only DDIF compound documents.  DOCUMENT will NOT be able to take in DDIF
>>compound documents.  DECwrite also can make PostScript, but it is not
>>Encapsulated PostScript.
    
    and...
    
>>The new bookreader supplied with the next DECwindows release will be able to
>>use Encapsulated PostScript figures made by any tool.
    
    Mary
    
340.10PECO generates Bookreader figures, tooREORG::SEARLETue Jun 05 1990 11:248
    Don't forget PECO, that unloved, unsupported hack.  We use an Andrew
    Gent extension to PECO that causes PECO to write out DECW$BOOKFIG
    files of some sort.
    
    To be complete, add that to the list of tools that can generate 
    graphics. 
    
    Kirk
340.11How about the other direction?MAIL::HYSLIPFri Aug 17 1990 20:5211
    Most of the questions I have seen so far deal with trying to
    get data INTO bookreader format.
    
    Is it possible to extract data from a bookreader file and put 
    in into a text file?
    
    If this is not the correct place to ask please point me
    in the right direction.
    
    Thanks
    Dave Hyslip
340.12BULOVA::BOOKREADERMARKUP::DEVRIESBy their notes ye shall know themFri Aug 17 1990 22:075
    BULOVA::BOOKREADER is a better place to ask about that. 
    ONLINE_BOOKBUILDING is primarily a place to discuss creating online
    books via VAX DOCUMENT.
    
    Mark