Keith Packard writes:
> The goal would be to create an html document which could be used without
> javascript, and that would work without css as well.
I've managed to hack up asciidoc to generate the TOC within the
document, rather than requiring javascript. The changes are fairly
minor, and se
Jani Nikula writes:
> One of the chief complaints with the current pipeline (and some of the
> proposals) has been the need to install lots of tools with lots of
> dependencies. I would like to avoid the need to install bleeding edge
> tools and stick to what's already widely available in distros
Jonathan Corbet 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 asci
On Thu, 11 Feb 2016, Keith Packard wrote:
> I think it should be pretty easy to hack asciidoc to add diversions to
> hold TOC contents while generating the rest of the doc and then replay
> the diversion into the final document.
One of the chief complaints with the current pipeline (and some of t
Jonathan Corbet writes:
> [Adding Keith since you said you wanted to be a part of this - let us know
> when you've had enough!]
Thanks.
> - I would like to format directly to HTML if at all possible.
Agreed. asciidoc's docbook path seems to only increase the amount of
software involved.
>
On Wed, 10 Feb 2016 16:03:38 +0200
Jani Nikula wrote:
> I'd like to clarify the end goal a bit more before deciding what to do
> next. In particular, is the aim to have asciidoc->HTML only or dual
> asciidoc->HTML and asciidoc->XML->whatever? Or independent
> asciidoc->HTML first, with the existi
On Wed, 10 Feb 2016 09:07:22 +0100
Daniel Vetter wrote:
> I think for 4.6 it'd be best to go with the hybrid asciidoc->docbook
> toolchain, since that's less disruptive. And with that we can also
> fully concentrating on the frontend, and how it'll look and behave.
That can be fine, I'd just lik
On Wed, 10 Feb 2016, Jani Nikula wrote:
>> On Wed, Feb 10, 2016 at 1:09 AM, Jonathan Corbet wrote:
>>> - I'm not sold on the new inclusion mechanism. Creating thousands of
>>>little files and tracking them for dependencies and such doesn't seem
>>>like a simplification or a path toward
[Sorry this turned out a long email, I didn't have the time to write a
short one.]
On Wed, 10 Feb 2016, Daniel Vetter wrote:
> On Wed, Feb 10, 2016 at 1:09 AM, Jonathan Corbet wrote:
>> On Tue, 26 Jan 2016 14:08:45 +0200
>> Jani Nikula wrote:
>>
>>> I'm afraid we've done some overlapping work
On Wed, Feb 10, 2016 at 1:09 AM, Jonathan Corbet wrote:
> On Tue, 26 Jan 2016 14:08:45 +0200
> Jani Nikula wrote:
>
>> I'm afraid we've done some overlapping work in the mean time, but I'm
>> happy we've both looked at the tool chain, and can have a more
>> meaningful conversation now.
>
> [Addin
On Tue, 26 Jan 2016 14:08:45 +0200
Jani Nikula wrote:
> I'm afraid we've done some overlapping work in the mean time, but I'm
> happy we've both looked at the tool chain, and can have a more
> meaningful conversation now.
[Adding Keith since you said you wanted to be a part of this - let us know
On Tue, 26 Jan 2016 07:48:21 -0700
Jonathan Corbet wrote:
> For HTML-page splitting, we can see if the tools can help us, consider
> splitting the template files, or do the splitting in a postprocessing
> step. Docproc (or whatever replaces it) could also maybe do that work.
> It doesn't seem to
On Tue, 26 Jan 2016 14:08:45 +0200
Jani Nikula wrote:
> I'm afraid we've done some overlapping work in the mean time, but I'm
> happy we've both looked at the tool chain, and can have a more
> meaningful conversation now.
Overlapping work is just how this kernel thing works :)
> I first took ro
On Tue, 26 Jan 2016, Daniel Vetter wrote:
> On Tue, Jan 26, 2016 at 1:08 PM, Jani Nikula wrote:
>> I first took roughly the same approach as you did. I was really
>> impressed with the speed and the beauty of the produced HTML. The
>> trouble is, neither asciidoc nor asciidoctor can produce chunk
On Tue, Jan 26, 2016 at 1:08 PM, Jani Nikula wrote:
> On Tue, 26 Jan 2016, Jonathan Corbet wrote:
>> So here is a proof-of-concept series showing how a fully asciidoc-based
>> toolchain might work. Lots of hackery here, this isn't meant to be applied
>> to anything at this point, but it's a good
On Tue, 26 Jan 2016, Jonathan Corbet wrote:
> So here is a proof-of-concept series showing how a fully asciidoc-based
> toolchain might work. Lots of hackery here, this isn't meant to be applied
> to anything at this point, but it's a good start. What this series has is:
>
> - Jani Nikula's pat
So here is a proof-of-concept series showing how a fully asciidoc-based
toolchain might work. Lots of hackery here, this isn't meant to be applied
to anything at this point, but it's a good start. What this series has is:
- Jani Nikula's patch adding asciidoc output to kernel-doc. Thanks for
17 matches
Mail list logo
