From: "Drew Adams" <drew.adams@oracle.com>
To: "'Tim X'" <timx@nospam.dev.null>, <help-gnu-emacs@gnu.org>
Subject: RE: printing info pages
Date: Sat, 16 Feb 2008 22:23:58 -0800 [thread overview]
Message-ID: <003401c8712d$ae2a3d90$2d58908d@us.oracle.com> (raw)
In-Reply-To: <87ejbcpfdf.fsf@lion.rapttech.com.au>
> >> I started using ECB and use th einfo pages to read the
> >> documentation. Is it possible to convert these info pages into a
> >> printable document?
> >
> > Sure. Use `ps-print-buffer' or `ps-print-buffer-with-faces'.
> >
> > ,----[ C-h f ps-print-buffer RET ]
> > | ps-print-buffer is an interactive compiled Lisp function
> > | in `ps-print.el'.
>
> While this would work OK, it is going to be a bit tedious to
> do this for each page.
>
> An alternative approach would be to use th texinfo sources
> for the info pages. Yo will find that the info pages are
> generated from texinfo sources. There are utilities out
> there to convert the texinfo pages into various forms,
> including pdf and postscript. You then just have to send
> the file tot he printer.
That's no doubt the best solution, but here's another possibility, if you
just want a quick way to combine Info nodes so you don't have to print them
separately.
With info+.el (http://www.emacswiki.org/cgi-bin/wiki/InfoPlus), you can
merge Info nodes any way you like, creating one big buffer with all nodes if
you like, or any number of buffers, each with some of the nodes. Then just
print the buffer(s).
Command `Info-merge-subnodes' (bound to `+') merges an Info node with its
subnodes into the same buffer.
,----[ C-h f Info-merge-subnodes RET ]
| Info-merge-subnodes is an interactive compiled Lisp function in
| `info+.el'.
|
|
| (Info-merge-subnodes &optional RECURSIVE-DISPLAY-P RECURSIVE-CALL-P)
|
| Integrate current node with nodes referred to in its Menu.
|
| Displays the current Info node, together with the nodes in its Menu.
| Buffer `*Info: NODE*' is used for the display, where NODE is the name
| of the current node. The contents of this node's subnodes (the nodes
| named in this node's Menu) are included in the buffer, following the
| contents of the current node.
|
| Optional arg RECURSIVE-DISPLAY-P (prefix arg if interactive) governs
| the way menus of subnodes are treated:
|
| If nil, nothing additional happens. Subnode menus are not explored.
| Only the current node and its immediate subnodes are documented, in
| the single display buffer `*Info: NODE*'.
|
| If non-nil, then the subnodes of a node are treated in the same way
| as the parent node, recursively: If any of them has, itself, a Menu,
| then that menu's subnodes are also explored, and so on.
|
| If RECURSIVE-DISPLAY-P is zero, then a single display buffer is
| used for all of the nodes explored. Otherwise, a separate display
| buffer is used for each subnode that has a Menu (see next).
|
| Use this when you want a single, flat compilation of the current
| node and all of its subnodes. It is less appropriate when the
| current node has several levels of subnodes: The flattened
| result can be difficult to read.
|
| If RECURSIVE-DISPLAY-P is positive, then the contents of each
| subnode are displayed twice: once in the parent node's display,
| and once in the subnode's own display.
|
| Use this when the current node has several levels of subnodes
| and you want each display buffer to be self-contained.
|
| If RECURSIVE-DISPLAY-P is negative, then there is no redundancy: A
| subnode's contents are only displayed in its parent's buffer. The
| subnode's own display buffer only contains the contents of its own
| subnodes.
|
| Use this when the current node has several levels of subnodes
| and you want no redundancy between the display buffers.
|
| The user option (variable) `Info-subtree-separator' is a string to be
| inserted by `Info-merge-subnodes' just before the title of each
| node (preceding its description). By default it is "\n* ", producing
| a node title resembling a menu item. Setting this to "\f\n* " will
| cause a page break before each node description. For more on setting
| this variable, type `C-h v Info-subtree-separator'.
|
| ------
|
| Optional second arg RECURSIVE-CALL-P is only for internal use. It is
| used to indicate whether (non-nil) or not (nil) this is a recursive
| (i.e. not a top-level) call to `Info-merge-subnodes'. Non-nil
| means that this is a subnode, and that its contents should only be
| included in the present display if RECURSIVE-DISPLAY-P is also
| non-nil. For proper operation when RECURSIVE-DISPLAY-P is zero, the
| non-nil value of RECURSIVE-CALL-P should be the node name of the
| top-level call to `Info-merge-subnodes'.
|
| [back]
`----
prev parent reply other threads:[~2008-02-17 6:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-16 14:23 printing info pages geodasge
2008-02-16 16:59 ` Tassilo Horn
2008-02-16 17:30 ` Reiner Steib
[not found] ` <mailman.7487.1203181208.18990.help-gnu-emacs@gnu.org>
2008-02-17 0:59 ` Tim X
2008-02-17 6:23 ` Drew Adams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003401c8712d$ae2a3d90$2d58908d@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=timx@nospam.dev.null \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).