||*()*|| Hi, Gabor. >>>I hesitate, since this one is more compact, while it might lead to >>>misunderstanding. >> >> I tend to agree. >> >> With that, should the stylesheets be modified to say, insert a hard >> line break or should I use a heading above each <classsynopsis>? >> I personally would prefer rendering like <funcsynopsis>, where a line >> break is inserted afterwards, would certainly be more consistent with >> the other documentation.
GH> Presentation changes should be done in the stylesheets. To tell the truth I'd like to see ready output html design for rendering classes and their methods. Epecially how to combine them with existing function references to keep documentation clear for newbies, who doesn't understand all that OO stuff nicely and at the same time make new docs convenient to use by OO gurus. AFAIR, it is a long term TODO, but we need to start from something. For me it is preferrable to start with some screenshots or .images. of possible output designs. Keep alternatives on one page to leave comments and progress info open for everybody who would like to offer something. After we choose the best way to render classes to keep documentation clear for newbies and still usable for everyone else, we can start altering templates or think about missed functionality in DocBook. DocBook team is very flexible, so if will show them why we need DocBook to be altered, then, probably, we might reconsider the need of our own standard. t --
