From: Keith Packard <keithp@keithp.com>
To: Jonathan Corbet <corbet@lwn.net>, Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
linux-doc@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] A first shot at asciidoc-based formatted docs
Date: Thu, 11 Feb 2016 07:18:10 -0800 [thread overview]
Message-ID: <86si0z1djh.fsf@hiro.keithp.com> (raw)
In-Reply-To: <20160210135651.7dbaa1f6@lwn.net>
[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]
Jonathan Corbet <corbet@lwn.net> writes:
> asciidoc->HTML on its own isn't viable, I think; we do have people wanting
> other formats. Though one might well ask when somebody last successfully
> generated PDF...maybe it's not worth the trouble. I would like epub
> someday...
I'm hopeful that I can hack up asciidoc to generate usable HTML
directly. Once we've got HTML, we've got epub.
If we don't want to use docbook for pdf, asciidoc has a native latex
backend. That's in about the same shape as the html backend. Would that
be better than docbook?
> There's also people who actually use the man-page output. I don't think
> that should require the xml step; getting rid of that might make it
> possible to do "make mandocs" and have it finish before the next merge
> window opens...
Adding a troff backend to asciidoc would be simple enough; I'm not sure
what other method you'd suggest here.
> We talked about that a bit in Geelong; the short-term idea was to generate
> a TOC and use CSS to place it correctly. Daniel, if I heard you correctly,
> you thought that would be a fine solution that would remove the need for
> chunked output. Keith seemed interested in looking into this too.
Here's an example that takes the docbook output with some simple CSS
hacks to place the TOC alongside the document in a separate scrolling
list. With a small bit of javascript, I'm pretty sure that could have
collapsible entries.
--
-keith
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 810 bytes --]
next prev parent reply other threads:[~2016-02-11 15:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 23:28 [RFC] A first shot at asciidoc-based formatted docs Jonathan Corbet
2016-01-25 23:28 ` [PATCH 1/4] kernel-doc: add support for asciidoc output Jonathan Corbet
2016-01-25 23:28 ` [PATCH 2/4] docproc: handle asciidoc templates Jonathan Corbet
2016-01-25 23:28 ` [PATCH 3/4] Docs: Makefile tweaks for " Jonathan Corbet
2016-01-25 23:28 ` [PATCH 4/4] Docs: add a sample asciidoc template Jonathan Corbet
2016-01-26 12:08 ` [RFC] A first shot at asciidoc-based formatted docs Jani Nikula
2016-01-26 12:08 ` [RFC 01/10] kernel-doc: rewrite usage description, remove duplicated comments Jani Nikula
2016-01-26 12:08 ` [RFC 02/10] kernel-doc: add support for asciidoc output Jani Nikula
2016-01-26 12:08 ` [RFC 03/10] kernel-doc: support printing exported and non-exported symbols Jani Nikula
2016-01-26 12:08 ` [RFC 04/10] kernel-doc: add support for printing DOC: comments with escaped names Jani Nikula
2016-01-26 12:08 ` [RFC 05/10] scripts: add asciidoc-includes to extract includes from asciidoc Jani Nikula
2016-01-26 12:08 ` [RFC 06/10] scripts: add a kernel-doc helper for special invocation Jani Nikula
2016-01-26 12:08 ` [RFC 07/10] scripts: add tool for generating asciidoc dependencies and rules Jani Nikula
2016-01-26 12:08 ` [RFC 08/10] scripts: add a crude converter from DocBook tmpl to asciidoc Jani Nikula
2016-01-26 12:08 ` [RFC 09/10] Documentation: convert gpu.tmpl to gpu.txt Jani Nikula
2016-01-26 12:08 ` [RFC 10/10] Documentation: build asciidoc documentation Jani Nikula
2016-01-26 12:17 ` [RFC] A first shot at asciidoc-based formatted docs Daniel Vetter
2016-01-26 12:38 ` Jani Nikula
2016-01-26 14:48 ` Jonathan Corbet
2016-01-26 14:52 ` Jonathan Corbet
2016-02-10 0:09 ` Jonathan Corbet
2016-02-10 8:07 ` Daniel Vetter
2016-02-10 14:03 ` Jani Nikula
2016-02-10 16:12 ` Jani Nikula
2016-02-10 20:56 ` Jonathan Corbet
2016-02-11 15:18 ` Keith Packard [this message]
2016-02-10 20:45 ` Jonathan Corbet
2016-02-10 23:01 ` Keith Packard
2016-02-11 13:44 ` Jani Nikula
2016-02-11 15:21 ` Keith Packard
2016-02-13 3:20 ` Keith Packard
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86si0z1djh.fsf@hiro.keithp.com \
--to=keithp@keithp.com \
--cc=corbet@lwn.net \
--cc=daniel.vetter@ffwll.ch \
--cc=jani.nikula@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.