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

Conference vaxuum::document_ft

Title:DOCUMENT T1.0
Notice:**New notesfile (DOCUMENT.NOTE) now available (see note 897)**
Moderator:CLOSET::ADLER
Created:Mon Feb 09 1987
Last Modified:Thu Oct 31 1991
Last Successful Update:Fri Jun 06 1997
Number of topics:897
Total number of notes:4397

744.0. "Frustration with LN03/PostScript incompatibilities" by CASEE::CLARK (Ward Clark) Tue Aug 04 1987 11:35

    I'm creating several documents that will be distributed to a wide,
    DEC-internal audience.  All the document preparation has been done
    using our group's LN03+.

    Because some of the intended readers may have only PostScript printers,
    I decided to be a good guy and offer both LN03 and PostScript versions
    of the documents. 

    I believe that I have once again run into the the "myth of
    transportable documents".  Compounding the problems with
    non-transportable tags, I'm now confronted with LN03/PostScript
    incompatibilities:

	-  The REPORT document type uses different-sized fonts for the
	   two output devices, resulting in different line lengths,
	   different hyphenation, different page layout, ...

	   The visual presentation of the documents (which I now realize
	   relies on the LN03-specific fonts) needs to be reworked so that
	   the PostScript documents look as good as the LN03 documents.

	-  I have several diagrams that I created with SIGHT that are
	   included in the documents.  It now appears that I must maintain
	   separate source files because <FIGURE_FILE> arguments (device
	   type and file type) must be hardwired to a specific output
	   device.

           Life would be a lot simpler if the device-specific needs of the
           <FIGURE_FILE> tag were based on the "destination" argument of
	   the DOCUMENT command.

    -- Ward
T.RTitleUserPersonal
Name
DateLines
744.1Some things will change; feedback is crucialVAXUUM::DEVRIESM.D. -- your Device DoctorTue Aug 04 1987 14:2656
>    Because some of the intended readers may have only PostScript printers,
>    I decided to be a good guy and offer both LN03 and PostScript versions
>    of the documents. 
    
    If your readers with PostScript printers have only DEC PostScript
    printers, and they are using the "standard" LPS40 and LN03R symbionts,
    they can print LN03 files on their printers as ANSI files without
    further DCL qualifiers.  Will that be sufficient?
    
    
>    I believe that I have once again run into the the "myth of
>    transportable documents".  
    
    True -- complete and perfect transportability between two complex, 
    dissimilar components is *always* a myth.  The measure of a system is 
    in how well it does the things you deem most important.
    
    
>    Compounding the problems with non-transportable tags, I'm now 
>    confronted with LN03/PostScript incompatibilities:
    
    Thanks for calling to our attention those things you deem most
    important.  Such feedback is crucial.
    
    
>    The visual presentation of the documents (which I now realize
>    relies on the LN03-specific fonts) needs to be reworked so that
>    the PostScript documents look as good as the LN03 documents.
    
    a) ANY visual presentation that uses variables such as fonts relies
       on the devices that support those fonts, and even "the same"
       fonts look different on devices that have different imaging
       technologies.
    b) Can you be more specific about what "look as good" means?  Larger
       fonts?  Smaller fonts?  Different faces?  Different spacing?
       The more specific you can be, the more help the developers can
       be.  And if you can relate it to the fonts actually available
       on the different devices, it will be even more helpful.
    
    
>    I have several diagrams that I created with SIGHT that are
>    included in the documents.  It now appears that I must maintain
>    separate source files because <FIGURE_FILE> arguments (device
>    type and file type) must be hardwired to a specific output
>    device.
    
    Not so.  You can use <FIGURE_FILE> tags for different devices in the 
    same SDML file.  That's why those tags take device arguments.  (Another
    one for the wishlist: <FIGURE_SPACE> ought to have a device component,
    too.)
    
    
    Thanks for the feedback.  We are by no means done -- we are only
    at the beginning.  This is only Version One.
    
    --Mark
744.2A student in the School of Hard KnocksCASEE::CLARKWard ClarkWed Aug 05 1987 06:2831
    .1>  If your readers with PostScript printers have only DEC PostScript
    .1>  printers, and they are using the "standard" LPS40 and LN03R
    .1>  symbionts, they can print LN03 files on their printers as ANSI
    .1>  files without further DCL qualifiers.  Will that be sufficient?

    Based on the observation that other groups (like VAX DOCUMENT) took the
    trouble to offer both LN03 and PostScript versions of documents, I
    assumed that practice was necessary, or at least desirable.  Let me
    repeat Mark's question:  Will it be sufficient to offer only LN03
    format documents?

    .1>  b) Can you be more specific about what "look as good" means?

    In the specific case of my first test of LN03/PostScript output, "look
    as good" refered to overall page layout.  Because of the smaller font
    used in the PostScript case, I wound up with a couple of unfortunate
    page breaks.  One involved a major section starting at the bottom of a
    page with only a few lines of text.  Another involved a bullet list
    being broken across two pages.  Neither of these are serious problems.
    It's just that the LN03 output "looks better" than the PostScript
    output.

    .1>  You can use <FIGURE_FILE> tags for different devices in the same
    .1>  SDML file.

    After a good night's sleep, this "workaround" became obvious.  Since
    Mark indicated that this feature is intentional, rather than
    accidental, it would be a good idea to specifically point it out in the
    documentation of the <FIGURE_FILE> tag.

    -- Ward
744.3One column PostScript text seems too smallCASEE::CLARKWard ClarkWed Aug 05 1987 07:3617
    .0>  The REPORT document type uses different-sized fonts for the two
    .0>  output devices [LN03 & PostScript], resulting in different line
    .0>  lengths, different hyphenation, different page layout, ...

    Is this difference necessary?  desirable?

    With respect to the latter, my opinion is that the PostScript text font
    is too small for single column formatting.  It's about the same size
    that used for REPORT.TWOCOL for an LN03.

    It's my understanding that human factors studies have shown that the
    readability of text falls off quite rapidly when the lines are longer
    than "n" characters.  (I don't recall what "n" is.)  What happens is
    that the long lines makes it hard to accurately locate the beginning of
    the next line of text.

    -- Ward
744.4Only the user knows for sure.VAXUUM::DEVRIESM.D. -- your Device DoctorWed Aug 05 1987 11:4322
    
.2>    Based on the observation that other groups (like VAX DOCUMENT) took the
.2>    trouble to offer both LN03 and PostScript versions of documents, I
.2>    assumed that practice was necessary, or at least desirable.  
    
    It is certainly necessary, to provide documents in the formats your 
    readers can use.  I was just trying to make a helpful suggestion.  
    Since, in this case, you are unhappy with the PostScript output can
    your readers, in this case, all use the format you like (LN03)?  I
    placed the response here because not all users are aware that they can 
    print LN03 files on the LPS40 and LN03R.
    
    
.2>    Let me repeat Mark's question:  Will it be sufficient to offer only 
.2>    LN03 format documents?
    
    It's certainly not sufficient for any new tools to produce only
    LN03 format documents.  Only you can say which features you need
    to use in any particular case, and which ones you can ignore.
    
    --Mark
    
744.5Switching to Century might be an answerDECWET::KOSAKWed Aug 05 1987 11:4712
    Re: text font being too small in PostScript, I agree.  There is,
    however, a simple workaround, at least for users with an LPS40.
    The fonts resident on the LPS40 include Century.  We have tweaked
    our doctypes to switch everything that was printed in Times to now
    print in Century, a vast improvement (especially on those tiny little
    footnotes).  This, of course, requires the intended PostScript printer
    to have the Century font installed, and this could be a problem
    since Century is not a "standard" font that usually comes built
    in.  We don't have any LN03Rs, so does anyone out there know if they 
    come with Century, or if it is possible to install this font? 
    
    -- Craig
744.629 fonts are standard; test program enclosedVAXUUM::DEVRIESM.D. -- your Device DoctorWed Aug 05 1987 12:4566
    The LN03R uses the DEC standard complement of fonts, just like the
    LPS40.  So yes, Century lives there, too.
    
    Below the form feed is a little PostScript program that prints out
    the name of each face in that face.  You might want to extract this
    note, edit it to isolate the following code, and print it as a
    PostScript file.  There are more elegant demo programs around, if
    you need to pursue the matter.

% ---- 2 9   T Y P E F A C E S ----
% ---- defined procedures ----
/vpos 648 def		%vertical position variable
/choosefont		%stack: typeface name
{ findfont 15 scalefont setfont } def
/newline
{ /vpos vpos 15 sub def	%decrease vpos
  72 vpos moveto } def	%go to that line
/printword		%stack: typeface name | typeface name
{ choosefont		%set font
  show			%show typeface name
  newline } def		%goto that line

% ---- begin program ----
144 720 moveto			%print heading
(DEC PostScript Built-In Typefaces)	/Times-BoldItalic	printword

72 vpos moveto		%vpos starts near top
(Courier)		/Courier		printword
(Courier-Bold)		/Courier-Bold		printword
(Courier-Oblique)	/Courier-Oblique	printword
(Courier-BoldOblique)	/Courier-BoldOblique	printword
newline
(Times-Roman)		/Times-Roman		printword
(Times-Bold)		/Times-Bold		printword
(Times-Italic)		/Times-Italic		printword
(Times-BoldItalic)	/Times-BoldItalic	printword
newline
(Helvetica)		/Helvetica		printword
(Helvetica-Bold)	/Helvetica-Bold		printword
(Helvetica-Oblique)	/Helvetica-Oblique	printword
(Helvetica-BoldOblique) /Helvetica-BoldOblique	printword
newline
(Symbol)		/Symbol			printword
newline
(AvantGarde-Book)	 /AvantGarde-Book	 printword
(AvantGarde-BookOblique) /AvantGarde-BookOblique printword
(AvantGarde-Demi)	 /AvantGarde-Demi	 printword
(AvantGarde-DemiOblique) /AvantGarde-DemiOblique printword
newline
(NewCenturySchlbk-Roman)	/NewCenturySchlbk-Roman	     printword
(NewCenturySchlbk-Bold)		/NewCenturySchlbk-Bold	     printword
(NewCenturySchlbk-Italic)	/NewCenturySchlbk-Italic     printword
(NewCenturySchlbk-BoldItalic)	/NewCenturySchlbk-BoldItalic printword
newline
(Souvenir-Demi)		/Souvenir-Demi		printword
(Souvenir-DemiItalic)	/Souvenir-DemiItalic	printword
(Souvenir-Light)	/Souvenir-Light		printword
(Souvenir-LightItalic)	/Souvenir-LightItalic	printword
newline
(LubalinGraph-Book)	    /LubalinGraph-Book		printword
(LubalinGraph-BookOblique) /LubalinGraph-BookOblique	printword
(LubalinGraph-Demi)	    /LubalinGraph-Demi		printword
(LubalinGraph-DemiOblique) /LubalinGraph-DemiOblique	printword
%
showpage