[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-cvs
Subject:    [Xmlgraphics-fop Wiki] Update of "WhitespaceManagement" by JeremiasMaerki
From:       Apache Wiki <wikidiffs () apache ! org>
Date:       2007-02-09 15:38:31
Message-ID: 20070209153831.27771.23421 () eos ! apache ! osuosl ! org
[Download RAW message or body]

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 JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement

The comment on the change is:
some more thoughts

------------------------------------------------------------------------------
  
  [VH] Unless I missed something this will work only if the min/opt/max of the \
several alternatives are overlapping. If each alternative has only a fixed length, \
you can't create a min/opt/max representing them, because glue is a continuous value \
(not a discrete one). Suppose you have 3 alternatives of fixed lengths 8, 10 and 12. \
You can't simply create a min/opt/max of 8/10/12: what if the glue is stretched so \
that the block ends up having a size of 11? There is no suitable alternative for such \
a length.  
+     * [JM] I see the problem. However, I don't think it would be a problem to \
simply add additional whitespace for the surplus stretch (in your example, length 10 \
is chosen and 1 unit whitespace added). We should probably look at how we do the area \
generation in this case. I'd keep it simple and let the  best-fit element create a \
viewport/reference pair. You could then let the display-align/text-align properties \
define how the content should be placed inside the container. + 
  However, if the situation is similar to the one on the picture below, it becomes \
possible to create a combining min/opt/max:  
   http://people.apache.org/~vhennebert/wiki/WhiteSpaceManagement/whiteSpaceManagement.png
  
  If this is not the case, I don't see any other possibility than computing break \
points once for each alternative... which will quickly lead to combinatorial \
explosion. If we implemented a best-fit strategy in addition to the current total-fit \
one, we could reduce the complexity a lot by making a decision at the end of each \
page. Anyway, it seems to me that this whole approach has an interest only with a \
best-fit strategy.  
+ [JM] With the addition of the inline-progression-direction variant, the \
implementation gets more complicated. Since it's about two different orientations, I \
assume the two implementations would have to be done separately, i.e. best-fit-block \
and best-fit-inline. + 

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


[prev in list] [next in list] [prev in thread] [next in thread]