IPF Compiler bug - p tag in table cells.

[Graeme Geldenhuys]

While creating some IPF based documentation I noticed a bug in WIPFC.
The behaviour is different to the original IBM's IPFC compiler.

WIPFC complains about a invalid tag in table cell on line 8. That's the
Paragraph tag in the first cell. The IBM's IPFC compiler compiles this
document with zero errors and the resulting rendering when viewed with
IBM's VIEW.exe application is exactly the same as the second cell
rendering where the :lines. tag is used. ie: the :p. tag starts a new
line, but no blank line is inserted. This is different to when the :p.
tag is used outside a table cell. As the sample document also shows -
the text after the table.

==============[ tabletest.ipf ]========================
:userdoc.
:title.Testing Table Cells
:h1.Table test

:table cols='60' rules='both' frame='box'.
:row.
:c.This is :link reftype=hd res=18.Clock:elink. 1
:p.
This is line 2.
:row.
:c.
:lines.
This is :link reftype=hd res=18.Clock:elink. 1
This is line 2.
:elines.
:etable.

:p.
This is :link reftype=hd res=18.Clock:elink. 1
:p.
This is line 2.

:p.
:hp2.See Also:ehp2.
:ul.
:li.:link reftype=hd res=18.Clock:elink.
:eul.

:h1 res=18.Clock
:p.
This is a :hp2.Clock:ehp2. topic.

:euserdoc.

=======================================================

I double checked the IBM IPF reference documentation, and they don't
actually mention the behaviour of the :p. tag inside a table cell. But
in such a case I would assuming using the current behaviour of the IBM
IPFC.exe should be adhered to.

[Frank Beythien]

Post by Graeme Geldenhuys
While creating some IPF based documentation I noticed a bug in WIPFC.
The behaviour is different to the original IBM's IPFC compiler.
WIPFC complains about a invalid tag in table cell on line 8. That's the
Paragraph tag in the first cell. The IBM's IPFC compiler compiles this
document with zero errors and the resulting rendering when viewed with
IBM's VIEW.exe application is exactly the same as the second cell
rendering where the :lines. tag is used. ie: the :p. tag starts a new
line, but no blank line is inserted. This is different to when the :p.
tag is used outside a table cell. As the sample document also shows -
the text after the table.
==============[ tabletest.ipf ]========================
:userdoc.
:title.Testing Table Cells
:h1.Table test
:table cols='60' rules='both' frame='box'.
:row.
:c.This is :link reftype=hd res=18.Clock:elink. 1
:p.
This is line 2.
:row.
:c.
:lines.
This is :link reftype=hd res=18.Clock:elink. 1
This is line 2.
:elines.
:etable.

The documentation for openwatcom does not use the table tag AFAIK, so I
suspect nested :table :row :c :p tags were not tested.
And the wipfc source shows that no further tags are allowed inside table
cells:
/openwatcom/bld/wipfc/cpp/document.cpp

* :table (block)
* :row (block)
* :c (block)
* inline
* text
* :etable

CU
Frank

[Graeme Geldenhuys]

Hello Frank,

Post by Frank Beythien
And the wipfc source shows that no further tags are allowed inside

Sorry for the late reply. So am I understanding you correctly, that
this will not be fixed? I guess it make senses, because the :p. tag
has different behaviour inside a table cell compared to outside a table
- so it is probably a bug in the IBM IPC compiler to allow that.

But here is another strange one. In this example I used the .br tag in
the first cell to force a line break. I expected WIPFC to also complain
about an invalid tag used inside the cell, but this time WIPFC allowed
it without problems. The resulting INF or HLP file though doesn't have
a line break. The two lines in the cell appear back-to-back. I would
have expected the same output as the second table cell where :lines.
are used.


:table cols='60' rules='both' frame='box'.
:row.
:c.This is :link reftype=hd res=18.Clock:elink. 1
.br
This is line 2.
:row.
:c.
:lines.
This is :link reftype=hd res=18.Clock:elink. 1
This is line 2.
:elines.
:etable.