On Thu, Sep 26, 2024 at 12:01:48PM -0400, Benjamin Kalish wrote: > 1. Use the value from @node or @nodedescription as appropriate instead of > content from sectioning commands. Are there instances where this > substitution wouldn't work? No author is going to need raw formatters in > node names, and I think most authors could do without them in > @nodedescription as well.
I actually think that using @nodedescription/@nodedescriptionblock is a good idea, as it is well suited for meta description (after @documentdescription). It is optional, though, so @node/sectioning commands would still be used if @nodedescription is not set. I can't see why author would not use raw formatters @nodedescription, and it would actually be even more likely in @nodedescriptionblock. But it looks like a good idea independentely of @inlineraw use. Regarding @node versus sectioning commands, it should already be possible to use @node or sectioning commands based on USE_NODES customization variable value. It leads to other changes than only meta description and keywords, it changes more generally directions and <title> (depending on splitting too). In the default case, @node is used. Not in EPUB, as in EPUB USE_NODES is set to 0 to favor sectioning commands. I have not tested the output of EPUB with USE_NODES=1, but it could be possible to try if you want to. > 2. Provide additional optional commands to provide "safe" values for > section headings. This might look like: > @node I Heart New York > @chapter I <image src="../heart.png"> New York > @chapterplaintext I Heart New York This is the kind of possibility I hinted at in my first answer, but it is not appealing at all (not generally useful, not semantic...). > p.s. I am intrigued by "Very motivated users could use the HTML formatting > API to modify the formatting", though I my level of motivation has not yet > been tested! My current workaround for my formatting woes has been to set > variable values at the command line on a per format basis and test for them > using @ifset, but if there is an easier or more idiomatic way of handling > this I would be very happy to learn about it. It is less idiomatic and much harder, but there is a whole Perl HTML customization API that allows to specify precisely the HTML output: https://www.gnu.org/software/texinfo/manual/texi2any_api/ It is still not stabilized. -- Pat