docbook2mdoc/README - diff

Return to README CVS log

Up to [cvsweb.bsd.lv] / docbook2mdoc

version 1.4, 2019/04/06 13:30:21

version 1.6, 2019/04/12 16:40:53

Line 13 For these, you will have to look at 4.5 documentation

Add one "struct element" initializer to the elements[] array in the

Add one "struct alias" initializer to the aliases[] array in the

file parse.c, containing the name of element as it appears in DocBook

file parse.c *or* one "struct nodeprop" initializer to the properties[]

documents and the "enum nodeid" constant of the node to be generated.

array in the file node.c, but not both. The first struct member is

the name of the element as it appears in DocBook documents.

There are several special cases:

* If docbook2mdoc(1) never needs to produce any output for the

Line 47 There are several special cases:

Line 48 There are several special cases:

one explicit formatting decision based on the presence, absence,

or content of the element - add an enum constant for the new

node to the declaration of "enum nodeid" in the file node.h.

Preserve the alphabetic ordering.

Use properties[] in node.c and preserve the alphabetic ordering.

Add such a constant if only if the code will use it at least at

one place in addition to the definition of the elements[] array.

one place.

In the latter case, implement formatting in the file docbook2mdoc.c.

Line 60 include:

Line 61 include:

* Nodes to be represented by in-line macros that are parsed and

callable often get away with merely opening a macro scope

with macro_open(), letting the subsequent loop take care of

any children. In this case, the second, smaller switch

any children.

statement often needs to call macro_closepunct() to handle

closing delimiters.

* Nodes to be represented by one single stand-alone macro sometimes

get away with calling macro_line(), or macro_nodeline() if an