Thank you all for the comments.
I managed using a quite ugly solution but does the job: I edited the
layout.html
and included a hidden full toctree using:
<div style="display: none !important;"id="full_toctree">
{{ toctree(maxdepth=-1|toint, collapse=False,includehidden=True|tobool)
}}
</div>
This way, I can inspect the output HTML and fetch the entire toctree to
later on pass it to my PDF generator. H
ope it helps others!
On Monday, February 18, 2019 at 5:54:52 PM UTC+1, Peter Burdine wrote:
>
> See:
> https://groups.google.com/forum/#!msg/sphinx-users/0UW05Inwfac/X8bCZmlLBwAJ
> This is what I did a few years back. The builders are inconstant when
> they create events and I haven't been able to figure out how to make it
> work either.
>
> I have an extension that followed the todo example, which works great when
>> the output is latex, but for HTML it doesn't work right. The reason for
>> this seems to be that we are using Sphinx for a modular documentation
>> project so not all of the files will be included in the output. When using
>> the latex builder, we get a single doctree when the 'doctree-resolved'
>> event is called. When using the HTML builder, it gets called once for
>> every input file. Since I want to only include found items that are in the
>> final document, I found I can't trust the information I have when
>> 'doctree-resolved' is emitted since the final document structure isn't
>> complete. The only time I have found that I can trust that the document
>> has been assembled is when the 'env-updated' event is emitted, and then I
>> can browse the document tree like:
>>
>> def env_updated(app, env):
>> relations = env.collect_relations()
>> included_docs = []
>> updated_docs = []
>> # Each relation is a list in the following order [parent, prev_doc,
>> next_doc]
>> cur_doc = env.config.master_doc
>> while cur_doc:
>> included_docs.append(cur_doc)
>> doctree = env.get_doctree(cur_doc)
>> cur_doc = relations[cur_doc][2]
>>
>> This gives me a nice list of the documents in the order that they will be
>> in. I can even find all of the elements I want using:
>>
>> for docname in included_docs:
>> doctree = env.get_doctree(docname)
>> for table in doctree.traverse(my_node_type):
>> updated_docs.append(docname)
>> # Add rows to the table here...
>> return updated_docs
>>
>>
>> At the end of the handling the 'env-updated' event, I return a list of
>> documents I've modified (in my case, I appended rows to an existing table),
>> then I return the list of docnames I've modified. However, none of the
>> rows I've added to the table will show up in the final output. The code to
>> modify the table is good, it worked just fine in the 'doctree-resolved'
>> event handler, so I don't think that is the issue. Is there something I
>> need to do other the returning the list of docnames from the 'env-updated'
>> event handler to make these changes stick?
>>
>
>
> On Monday, February 4, 2019 at 3:26:25 AM UTC-8, balv...@boxfish.studio
> wrote:
>>
>> Hi Michael, thank you very much for your reply,
>>
>> I am already using wkhtmltopdf to build PDF from HTMLs. Also, I already
>> tried the singlehtml and indeed works but the problem is that it increases
>> so much the build time that it makes kind of impossible to work locally to
>> test. Using singlehtml to build the PDFs means building 1 time for the
>> documentation and n-times for each desired PDF, which can lead to building
>> time of hours. That is why I would like to avoid rebuilding the
>> documentation, simply converting the current build to PDF reduces so much
>> the time, but as mentioned, getting the *full* (infinite depth) tree
>> from the built html seems tricky.
>>
>> On Saturday, February 2, 2019 at 1:02:54 PM UTC+1, Michael Gielda wrote:
>>>
>>> Have you looked at WeasyPrint on a single html build? Don't know how
>>> well it works for your use case but that's what I would try first. It's in
>>> Python (yay), and a direct HTML to PDF converter, implementing the CSS Page
>>> spec (for stuff like headers and footers).
>>>
>>> Best regards
>>> Michael
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"sphinx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sphinx-users+unsubscr...@googlegroups.com.
To post to this group, send email to sphinx-users@googlegroups.com.
Visit this group at https://groups.google.com/group/sphinx-users.
For more options, visit https://groups.google.com/d/optout.
