xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Bauer ...@coware.de>
Subject Re: Indefinite page-height
Date Sun, 26 Mar 2006 21:05:46 GMT
Hi Andreas,

> Well... it depends. I had another glance at the related code. Where  
> exactly in finishPage have you put your code?
>
> I'm guessing here, but if you put it all the way at the top -- 
> before the calls to layoutSideRegion()-- wouldn't that solve the  
> problem?

That's what don't understand: No, putting it before that doesn't  
solve the problem.

> Hmm...
> (Integer.MAX_VALUE + 10000000 - (Integer.MAX_VALUE - difference)) =  
> 10000000 + difference
>
> Will need to take a closer look at that.

Yes, that's exactly what I don't understand either.

>
>> - Putting it into finishPart to me looks a little like a hack  
>> using implementation specifics.
>
> Yes, but ... FOP is the implementor here, no? What's 'hacky' about  
> using the specifics of our own implementation? :)

Well, sometimes programmers have to be protected from themselves...

To be more serious: finishPart may change in the future. finshPage is  
something providing a valuable and stable "event-point" I thought.

I've another thing to resolve which I put there: I need some more  
metrics for the created page. I need to know the number of lines  
created. I did an recursive approach looking for LineAreas:

private void lineCount(Metrics metrics, Area area) {
		if (area instanceof BlockParent) {
				BlockParent bp = (BlockParent) area;
				List childAreas = bp.getChildAreas();
				ListIterator iter = childAreas.listIterator();
				while (iter.hasNext()) {
						Area childArea = (Area) iter.next();
						if (childArea instanceof LineArea) {
								metrics.lineCount++;
								List inlineAreas = ((LineArea) childArea).getInlineAreas();
								ListIterator iter2 = inlineAreas.listIterator();
								while (iter2.hasNext()) {
										Area childArea2 = (Area) iter2.next();
										if (childArea2 instanceof LineArea)
												metrics.wordCount++;
								}
						}
						lineCount(metrics, childArea);
				}
		}
}

which I call in finishPage as well:

private void finishPage() {

		Metrics m = new Metrics();
		
		if (curPage.getSimplePageMaster().getPageHeight().getEnum() ==  
Constants.EN_INDEFINITE) {
				int height = (int) curPage.getPageViewport().getBodyRegion 
().getRegionViewport().getViewArea().getY();
				List spanList = curPage.getPageViewport().getBodyRegion 
().getMainReference().getSpans();
				ListIterator spanListIter = spanList.listIterator();
				while (spanListIter.hasNext()) {
								Span span = (Span) spanListIter.next();
								height += span.getHeight();
								
								int cols = span.getColumnCount();
								for (int col = 0; col < cols; col++) {
										NormalFlow flow = span.getNormalFlow(col);
										lineCount(m, flow);
								}
								
				}

Metrics is just:

     public class Metrics {
         public int lineCount = 0;
         public int wordCount = 0;
     }

Wordcount doesn't work that way, and I already figured out how it  
would work and actually I don't need the word count, but just the  
line count. There's already the FormattingResults and I'd like to add  
these metrics to it.

>
>> For me, finishPage is a more "public" point to perform the page  
>> size adjustment. But well, I'm not accustomed to the architecture  
>> and style yet to judge this. Perhaps a cleaner way would be to add  
>> something like getUsedBPD() to BodyRegion to decouple the  
>> dependencies.
>
> Could be the logic behind it is that finishPart() is guaranteed to  
> be called before finishPage(), and finishPage() contains the  
> activation of layout for the side-regions... From a certain POV,  
> the focal point of this recalculation of indefinite page-height(*)  
> is the flow layout. This would mean that my initial thoughts on  
> this are wrong, and the side-regions need no recalculation after  
> all (?)
> Even better if I'm right here...
>
> (*) Or is it BPD? Well, depends on writing-mode and/or reference- 
> orientation of the region-body...
> Grrr :) See, it could be that the total page-height ends up being:
> region-before-bpd + region-body-ipd + region-after-bpd
>
> One thing I pondered over: what if the region-body's height is its  
> ipd? What happens with text-alignment, especially justified text?  
> And start-aligned (with reference-orientation="90")? Will the text  
> 'shift' automatically when the viewport's height is altered? (I  
> assume it's not *that* simple ;))

I think that indefinite makes only sense or much more sense to be  
applied to the page-height. What should page-width = indefinite stand  
for? Well, if the writing direction is different (chinese!?) it may  
be a different story.

At least having a "shrink to fit" page height is what I need for our  
publishing system. We create classified adds using FOP and the width  
is fixed. Only the height is dynamic according to the text length.  
Actually we don't have pages here, but columns as they typically  
appear in news-papers. The resulting PDF "snippet" is placed onto a  
page within a column using something like Adobe InDesign. And the  
customer is billed for the number of lines.

Best regards,
Walter


Mime
View raw message