lout-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Big Bag o' Questions


From: Colin Klipsch
Subject: Big Bag o' Questions
Date: Wed, 11 Aug 1999 14:01:08 -0400 (EDT)

Greetings.  More Lout questions this month, and again, I apologize in
advance if I'm bringing up painfully obvious issues.


(1) For one of my documents, I've wanted to have a "keystroke"
    function -- one that wraps its argument in a rounded rectangle to
    make it look like a keyboard key.  I've composed the following
    function, which _almost_ works perfectly:

    def @Key right x
    #Example usage: @Key{delete}
    {
        @Diag vstrut{1f} hstrut{1f} halign{ctr} margin{2p}
        {
            @CurveBox font{Helvetica CondOblique -4p} {x}
        }
    }

    However, the "halign{ctr}" attribute seems to be ignored.  For
    short labels, such as single characters, the label appears left-
    justified within its box, rather than centered.  Any idea what
    I'm missing?


(2) This is admittedly a minor nit.....

    The "umlaut" character (ISO Latin1 character 168) doesn't seem to
    be recognized properly.  When present in one's Lout source file,
    one gets an error message like this:

      character "\250" replaced by space (it has no glyph in font
      Courier Base)

    ... or in Times Base for that matter, and presumably the other
    fonts also.  However, the glyph _does_ exist; or at least, there's
    one called "dieresis" in PostScript which seems the same to me.
    This prompted me to try _all_ the input codes from 160 to 255; in
    all, five of them generate such errors:

        168  dieresis (umlaut)
        173  hyphen ("soft" hyphen)
        175  macron
        180  acute
        184  cedilla

    What's puzzling is that the file LtLatin1.LCM, if I correctly
    understand its purpose, _does_ map these input codes to their
    proper PostScript characters.  Perhaps the trouble is in the files
    in lib/font -- the embellished AFM files?

    After trial and error, I discovered that using "\230" in my Lout
    source file would produce an umlaut/dieresis in the output
    PostScript, though this code's value is a mystery to me.  Also,
    using address@hidden dieresis} works, though it's a bit cumbersome.


(3) I want to propose that a collection of good quality freeware &
    shareware PostScript fonts be added to Lout, perhaps as a
    supplemental download package.

    There are two in particular I have in mind to start out with:
    Adobe's Utopia, and Bitstream's Charter, both of which are freely
    distributable; their AFM and PFA/B files reside on CTAN.  Both of
    these fonts have the advantage that they come in the four key
    styles: regular, italic, bold, and bold-italic.  They also have
    "complete" glyph sets and kerning data.

    And then there are the extra fonts available in GhostScript and
    Acrobat Reader (e.g. Antiqua, Arial, AdobeSansMM, and
    AdobeSerifMM), and a few good ones here and there around the
    Internet.  My proposal is _not_ to collect together any old fonts
    that merely exist in PostScript form, but rather just those fonts
    that are both free and of good quality.  The relative dearth of
    such fonts almost guarantees that such a collection would not get
    out of hand.

    I've already been using many of these fonts myself with Lout, and
    would be willing to do the work -- minor though it is -- of
    setting up the AFM files and the "fontdef" declarations for
    general use.  Any interest?


(4) Along the same lines, I'd like to push for Multiple Master font
    support, specifically the use of "optical scaling" at different
    point sizes.  Acrobat Reader's bundled MM fonts provide a base
    for testing the idea.

    I can imagine that adding this feature would mean major changes to
    Lout's internal workings.  It requires handling the possibility
    that the same typeface in different point sizes will have
    different metrics; in general they won't scale in the straight-
    forward way.  But on the plus side, MM fonts usually embody
    an entire font family in one package: boldface, italics, and
    condensed versions all included.

    And, if we want Lout to compete with TeX, the TeX mavens are going
    to pick on optical scaling eventually.  ;)


(5) It seems that defining new symbols inside the document text is
    impossible, that they all need to be defined in the "mydefs" file,
    even those used only over a small scope.  Is this true?  Is there
    a way to define a symbol inside a chapter or section?  If so, will
    it be "local" or "global"?


(6) What's the easiest way to _outdent_ all my section headers?
    Or perhaps equivalently, to indent all section text?


(7) Here's another feature request, if this isn't already possible...
    It would be nice to have a text "wrap-around" feature for small
    figures and tables, perhaps as a new value for the @Location
    parameter.  The figure (or table) would then be set alongside the
    current paragraph -- hugging either the left or right margin
    according to the user's choice -- with the text wrapping around
    it.  I'm referring to something like the DropCap feature, only
    much more flexible.


(8) I realize that Lout has some PDF support, but what I'd also like
    is extra support in Lout's PostScript output for later PDF
    distillation.  I refer to the documents below; they discuss the
    _pdfmark_ operator that Distiller obeys to generate hypertext
    links, bookmarks, and so on:

      http://pdfzone.com/pdfs/merzprimer.pdf

      http://partners.adobe.com/
        supportservice/devrelations/japan/PDFS/TN/PDFMARK.PDF

    For example, Lout's "bsf.lpg" setup file should perhaps have the
    following lines added to it:

      /pdfmark where
        {pop}  {userdict /pdfmark /cleartomark load put}  ifelse

    These lines are harmless in the sense that they give _pdfmark_ a
    definition only if it doesn't already have one.  (This operator is
    implicitly defined by Distiller before it does its work.)  In PS
    files _not_ being processed by Distiller, our substitute _pdfmark_
    will simply eat its arguments and do nothing.  We are now free to
    use _pdfmark_ in our PostScript without ill effect.

    The next step then is to actually invoke _pdfmark_ where
    appropriate.  This would require amending Lout's PostScript output
    to include things like:

        [ /Title (...)
          /Author (...)
          /Creator (Lout 3.16)
          /DOCINFO pdfmark 

    for general document information, and things like:

        [ /Rect [ ...... ]
          /Dest ...
          /Subtype /Link
          /ANN pdfmark

    for hypertext links, and things like:

        [ /Page ...
          /Title ...
          /OUT pdfmark

    for bookmarks (Acrobat TOC entries).

    In my opinion, it's worthwhile to add this PDF support in all
    PostScript output files, regardless of whether the user intends to
    run Distiller or not.  The amount of "waste" in that case is still
    quite small.  However, these features could perhaps be implemented
    in an optional "PDF" support package that the user could include
    by choice.


Thanks for listening.  Looking forward to hearing from people...

-- Colin K.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]