On Sun, Mar 02, 2025 at 02:19:26PM +0000, Gavin Smith wrote:
> On Sun, Mar 02, 2025 at 12:59:27PM +0100, pertu...@free.fr wrote:
> > On Sun, Mar 02, 2025 at 11:43:37AM +0000, Gavin Smith wrote:
> > > On Sun, Mar 02, 2025 at 12:27:49PM +0100, pertu...@free.fr wrote:
> > > Could we look at extending the htmlxref.cnf format?
> > >
> > > As well as mono/chapter/section/node, like:
> > >
> > > GS = ${G}/software
> > > hello mono ${GS}/hello/manual/hello.html
> > > hello chapter ${GS}/hello/manual/html_chapter/
> > > hello section ${GS}/hello/manual/html_section/
> > > hello node ${GS}/hello/manual/html_node/
> > >
> > > - there could be suffixed versions giving the transliteration status.
> > >
> > > It could be something like "node.translit" to give the location of
> > > an online manual split by node, which nodes are named using
> > > transliteration:
> > >
> > > hello node.translit ${GS}/hello/manual/html_node/
> >
> > Another option could be to consider that all the split possibilities of
> > a manual have the same transliteration/link type option, and use another
> > line like
> >
> > hello type translit
> > ...
> >
> > emacs type utf8
> >
> >
> > and there would be the possibility to set also plain/default/expand to
> > override a previous entry and reset to the default
>
> Since manuals only have one or two entries it seems harmless to have an
> extra line for each splitting option. This is only for manuals that
> need it (and I am not aware of which those manuals are).
>
> I want to keep the htmlxref.cnf format simple. With "hello type translit",
> "translit" is not a web URL, so this rule would not follow the pattern
> of existing rules.
Using suffixes do not follow the pattern of existing rules either, as it
is like adding another column, but separating with . instead of spaces.
Probably, the best way, if we want to allow per manual information would
be to add a new column, like
hello node default URL
This would not be backward compatible, though.
> (However, I'm not certain that .translit etc. suffixes would be the
> end of augmenting the htmlxref.cnf format, so we should think if there
> are any other factors that would affect HTML cross-references.)
Maybe we could have a version for the file format such that it is easy to
extend the format?
--
Pat
