xmlgraphics-fop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Xmlgraphics-fop Wiki] Update of "WhitespaceManagement" by LucaFurini
Date Wed, 07 Feb 2007 17:03:10 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by LucaFurini:
http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement

The comment on the change is:
A couple of questions and a comment about implementation

------------------------------------------------------------------------------
  
     * fox:best-fit-block and fox:best-fit-alternative perhaps? "alternative" seems somewhat
too generic. "best-fit-block" stresses that this is about block-progression-direction only.
  
+  * What about rewording this example using a single, standard block containing inline /
block level alternatives? Would it be a different use case, a more general (or more particular)
one, or just a different "perspective"? [LF]
+ 
+  * As (in general) we could not know how many lines each alternative will create, we may
need a way to define a  priority between the alternative (a priority attribute?) so that,
if both the n-th alternative and the m-th one lead to the creation of K lines the application
knows which one to use. [LF]
+ 
  == Thoughts for a possible implementation ==
  
  First thought is to implement it similarly to a block-container with stretch and shrink.
The implementation could measure the min/opt/max of every alternative and could calculate
a combined min/opt/max from that. Creating Knuth elements for this combined min/opt/max is
easy (a single box plus glue for the whole best-fit block with no break opportunity in between).
After the page breaking, generating the contents of a particular alternative is easy and can
be done the same way as for block-container.
  
  What's critical is the optimum BPD for the whole block. Assuming you are creating a catalog
with each article starting with the same larger structure. After that you have some variable
length content. Since the first block always takes some space you will want to keep it together.
This can lead to larger white areas on a page after the end of an article. You may be able
to fill that with additional content, an additional picture perhaps. But that should only
happen if there's really room to waste. So in this case the optimum value is 0pt. Maybe each
alternative would have to have an id attribute and the best-fit block will contain a reference
to the preferred alternative. The preferred alternative's optimum height will then become
the best-fit block's optimum height. In the case where you don't want any additional content
in the normal case, you'd specify an empty alternative and assign its id to the best-fit block.
  
+ The general situation in which the alternative blocks could be broken seems quite similar
to the MultiLayoutSequence one. [LF]
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org


Mime
View raw message