Pdx Design History

Table of Contents

• 2002-04-13
• 2002-05-18
• 2002-06-01
• 2002-06-08

2002-04-13

=include was not handling nested relative paths. That is, if we include ../../doc/dummy.pdx, and from there include ../test/testdata/dummy.pdx, we don't get the desired paths. The problem was that I was only using the last path segment on the pathstack, instead of the full stack. Now using the full stack, and passing the tests (test05). The test actually recursively includes the same files 3 times, thus the output closes with 3 copies of "line 4 line5" etc.

2002-05-18

I must have been lucky (or unlucky) re include paths, because I was concatenating the segments in reverse order. I think I have them right now. Unfortunately, my test cases work either way. I was only able to detect the problem when doing examples in the User's Guide.

Mary asked if I would provide fully-numbered lists:

   1.
     1.1.
     1.2.
   2.
     2.1.
       2.1.1.
   etc.

The backends do not have a way to do this automatically, so we would need to do the same mechansisms now used for heads. And then take control of the autogenerated numbering.

...No, the numbered_heads approach is not the right answer, because it needs to react to new labels (and levels) without assistance from a known closure. Lists in contrast know when they are being popped.

Next, I tried using OL LI's VALUE clause, but that turns out to require strict integers, not string labels with embedded dots. So we'll go with UL and provide our own labels.

Also, need to introduce a new list marker "N" for numbered.

...Seems to be working. The UL bullets look odd, but the numering is there.

I went through a lot of gyrations to get there, but the final code is pretty simple. Add a new marker. Detect an "N", and append a 0 to the liststack if one is found. When in N lists, increment the liststack top for each item, and use the whole list to build the number string. When the list is done, pop the liststack.

For Latex, used "itemize", and the same liststack mechanism.

For Docbook, use ORDEREDLIST with INHERITNUM="INHERIT".

2002-06-01

Added ability to insert blocks into table cells (e.g., lists). See test04. I've been thinking about this since I started pdx, and realized I needed to process the cells on the fly. Yet for table0-style tables (where we use the first row to determine number of cols), this is trouble. Finally decided to handle the first row separately.

This in turn led to redundant code, and thus need to refactor. Ended up with begin/end methods for table, row, and cell. Most of the processing is now in Base instead of in the drivers. The unclean aspect is that each call to driver_table_cell_begin needs to know its width, and that means using a global (in the instance sense) var for self.table_col_ndx.

The whole set of table globals needs to be captured and put on a stack if we want to nest tables. Which I'll avoid for now.

The syntax is getting pretty tedious:

    =table
    =row B<Feature> & B<Example>
    =row lists
    =cell
    This is a list
    =list *
    =item my item 1
    =item my item 2
    =end list
    =end cell
    =end table

Ok for autogenerating (though autogenerating docbook might be a better choice), but not too user-friendly. I don't see much point in pushing this further.

Also allowed slash in def name. Handy for XML-ish end tags.

2002-06-08

I'm getting more serious about the docbook backend, so tackled the numbering for sections and toc's. Mostly off-by-one errors.

Then did the verbatim escapes -- I was using the inline escapes rather than verbatim escapes.