I am currently working around this problem by using a multi-column layout in my region-body, and setting the bottom body margin to a large value so it puts a hard limit on the column height. So, say that I am working with a page that is 11in high; I'll give it four columns and set the margin-bottom to 7in, so the columns never exceed a few inches in height.
Of course, this has shortcomings: 1) The number of columns must be controlled manually. I initially wanted the number of columns to be automatically determined by the amount of source content. 2) Setting a large margin-bottom on region-body leaves a large portion of the page outside of the flow region. Thus, to put more content on the same page, I need to use block-containers with absolute positioning. This works for me for now, but I'm still going to research this. Colin On 4/3/07, Nelson, Dean <[EMAIL PROTECTED]> wrote:
It seems that you could force that list to a multi-column block? Still, that would be a significant customization. Regards, Dean Nelson Enterprise Electronics Corp -----Original Message----- *From:* Colin Shapiro [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, April 03, 2007 3:29 PM *To:* Nelson, Dean *Cc:* [email protected] *Subject:* Re: [docbook-apps] Dynamically creating an FO table based on content length Hi, Yes, this is similar to what I am trying to do. However, I don't believe that this is a DocBook-specific problem, or a shortcoming of the DocBook DTD / XSL distribution itself. I could be using my own custom DTD and I still wouldn't know how to write XSLT that can predict the physical dimensions of printed text blocks after they are generated by an FO processor. That is the heart of my question. Obviously, there is no way a stylesheet can know exactly what printed output will look like, since the FO processor has yet to do its magic. But maybe there's a good way to predict the output, somehow. If you wanted to go all-out, you could probably do the following: 1) Based on the font family, size, weight, and style that will be used, calculate the final, printed widths of each possible character (or at least letters/numbers) and store them in variables. 2) Use these values to calculate the total widths of the paragraphs/listitems/whatever you want to output. 3) Use these total widths to calculate how many lines each paragraph/listitem/whatever needs to occupy. 4) Use this information to determine how many columns are needed to contain all the lines of text produced. That, however, seems like a lot of work, and a very complicated stylesheet. Is there a better way? Colin On 4/3/07, Nelson, Dean <[EMAIL PROTECTED]> wrote: > > This was something that I was wondering myself, just yesterday. I > wanted to be able to do a list that had a certain height and would > automatically wrap to the next column on the right when the height was > exceeded. But atlas, this mere mortal failed and could not figure out how to > do it with standard Docbook features. > > I think that this is a feature that could be added to the lists in > Docbook? > > Regards, > > Dean Nelson > Enterprise Electronics Corp > > -----Original Message----- > *From:* Colin Shapiro [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, April 03, 2007 2:14 PM > *To:* [email protected] > *Subject:* [docbook-apps] Dynamically creating an FO table based on > content length > > Hi all, > > I have a problem which I can't think of a good way to solve. I realize > that I am perhaps approaching this problem incorrectly, so I hope someone > can point me in the right direction. > > Suppose that I have an arbitrary series of paragraphs in my source file, > containing an arbitrary amount of content: > > <para>This is some content.</para> > <para>This is more content.</para> > <para>This is even more content.</para> > <para>This is a longer amount of content.</para> > > Now, suppose that I want to format this source in an FO table with a > single row of cells. I want the table to have a fixed height--say, 2 > inches--so that the table never grows higher than 2 inches. I might do > this by placing block-containers within the table cells, giving them height > attributes. Then, I distribute my content among the table cells > accordingly: > > <fo:table> > <fo:table-column column-number="1"/> > <fo:table-column column-number="2"/> > > <fo:table-body> > <fo:table-row> > <fo:table-cell> > <fo:block-container height="2in"> > <fo:block>This is some content.</fo:block> > <fo:block>This is more content.</fo:block> > <fo:block>This is even more content.</fo:block> > </fo:block-container> > </fo:table-cell> > <fo:table-cell> > <fo:block-container height="2in"> > <fo:block>This is a longer amount of content.</fo:block> > </fo:block-container> > </fo:table-cell> > </fo:table-row> > </fo:table-body> > </fo:table> > > The problem, however, is that the source file can contain any number of > paragraphs of various lengths, and this will not be known until processing > time. Since I never want my table exceed 2 inches in height, I may need to > add more columns as needed to get additional cells. The idea here is that > the first cell will accommodate 2-inches-worth of content, then whatever > overflows will spill into the next cell, which will in turn accommodate 2 > inches of content, etc., and this will continue until all content is > displayed. > > I'd like a stylesheet to automatically handle this. It will determine > how much content there is, how many table columns are needed, and distribute > the content accordingly. However, this seems rather difficult to do, since > the stylesheet has no way of knowing what the final print output will look > like, how large the fonts will be, etc. > > I might be able to do something with string lengths. Calculate the > length of each paragraph, calculate the capacity of a table cell, and output > the paragraphs in table cells where they fit. But this would be based on > character counts only, which hold no bearing on the final print output when > a variable-width font is used; i.e., if the string "abcde" has a length > of "5", that doesn't tell me anything about how much physical space the text > "abcde" will occupy when printed in Helvetica font at size 12pt. > > Does what I'm getting at make sense? I hope I am being clear about my > problem; let me know if I am not. > > Thanks, > Colin > >
