[Top][All Lists]
[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.
- Big Bag o' Questions,
Colin Klipsch <=