Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> If we're doing nicer markup+CSS for this, then it might make sense to
> find a better solution for this kind of entry with multiple signatures
> (which was already an issue in the previous version):
Yeah, agreed. I would like to be able to have multiple signature blocks
in one table cell, which the current hack can't handle. There aren't
quite enough cases to make this mandatory, but it would be nicer.
It seems do-able if we explicitly mark signature blocks with their
own role, say
<entry role="functableentry">
<para role="funcsignature">
text || anynonarray → text
</para>
<para role="funcsignature">
anynonarray || text → text
</para>
<para>
description ...
Then the CSS can key off of the role to decide what indentation to apply
to the para. While I mostly see how that would work, I'm not very sure
about whether we can make it work in the PDF chain too.
Not sure whether it'd be worth inventing additional roles to apply to
description and example paras, or whether that's just inducing carpal
tunnel syndrome to no purpose. We'd want to keep the role label on the
<entry>s anyway I think, and that context should be enough as long as
we don't need different formatting for descriptions and examples.
But maybe Peter's notion of "semantic markup" requires it anyway.
regards, tom lane
