On Mar 01, 2022 at 18:27, Brar Piening wrote:
> On Feb 28, 2022 at 21:06, Chapman Flack wrote:
>> I think that in other recent examples I've seen, there might be
>> (something like a) consensus forming around the Unicode LINK SYMBOL
>> 🔗 rather than # as the symbol for such things.
>
> I intentionally opted for an ASCII character as that definitely won't
> cause any display/font/portability issues but changing that is no
> problem.
TBH I don't like the visual representation of the unicode link symbol
(U+1F517) in my browser. It's a bold black fat thing that doesn't
inherit colors. I've tried to soften it by decreasing the size but that
doesn't really solve it for me. Font support also doesn't seem
overwhelming. Anyway, I've changed my patch to use it so that you can
judge it yourself.
>> ... and now that the concept is proven, how hard would it be to broaden
>> that template's pattern to apply to all the other DocBook constructs
>> (such as section headings) that emit anchors?
>
> As long as we stick to manually assigned ids in the same way my patch
> does it, it shouldn't be too hard.
Patch is attached. I don't think it should get applied this way, though.
The fact that you only get links for section headers that have manually
assigned ids would be pretty surprising for users of the docs and in
some files (e.g. protocol-flow.html) only every other section has a
manually assigned id. It would be easy to emit a message (or even fail)
whenever the template fails to find an id and then manually assign ids
until they are everywhere (currently that means all varlistentries and
sections) but that would a) be quite some work and b) make the patch
quite heavy, so I wouldn't even start this before there is really
consensus that this is the right direction.