Bob Stayton <> writes:
> The formalgroup element was very specifically designed to support
> subfigures 1a, 1b, etc., and the same for other formal numbered
> elements like equations, examples and tables. It allows for
> autonumbering by the stylesheet, titles and captions for each, as
> well as automatically generated xrefs to specific subfigures. We
> noted that TeX supports subfigures. This is a common use case in
> technical documentation, and we could see no way to easily support
> it otherwise. We did not consider any general wrapper during this
> discussion.
I stand by my observation: if you have a rationale for grouping formal
objects, you are a teeny, tiny step from having a rationale for
grouping informal objects. (There are no other places where thereâs a
complete lack of parallelism as far as I can recall.)
Wanting to group figures so that they can be titled as subfigures
makes sense. Wanting to group them so that they donât cross a page or
column boundary, or have a common border, or a common background all
make equally good sense to me.
Persuaded to add a group for formal objects, Iâd have argued for
db:group (and possibly group-style because I really dislike fgstyle)
where you can wrap either formal or informal objects.
> 1. I think âbuildtargetâ is awfully specialized to be raised to the
> level of its own inline. There are lots of things relegated to a class
> value on âsystemitemâ that strike me as equally common: filesystem,
> macro, server, â
>
> How did âbuildtargetâ justify its own inline? Is it time to give up on
> any sense of limiting the number of elements and just raise all the
> systemitem classes up?
Any feedback on this comment?
Be seeing you,
norm
--
Norman Walsh <> | To think is not enough; you must think
http://nwalsh.com/ | of something.--Jules Renard
