If the implemented behavior is select-first-fitting then it makes sense. The behavior I observed is the one you described. The wiki page described best-fitting and I had built an example based on what I expected best fit to be.
On Mon, Apr 28, 2014 at 7:27 AM, Vincent Hennebert <[email protected]>wrote: > Hi Luis, > > thanks for testing this. > > > I tested with the attached example and the result is not what >>> I expected. It is also possible that I don't understand what best fit >>> means. >>> >> > The value of the option hasn’t been changed yet but it will be when > merging to trunk. Its name will be select-first-fitting, which should > better describe the behaviour of this extension. > > > > I was expecting yellow, yellow, yellow. Instead I get yellow, blue, >>> yellow. >>> Can you please comment? >>> >> > The first variant that fits on the page is selected, which is the blue > one in this case. > > > > On 28/04/14 00:38, Luis Bernardo wrote: > >> >> Further testing showed that this only seems to work if: >> -- the multi-switch element is the last element with content in the page >> -- the alternatives are ordered from the largest to the smallest >> Since the constraints are not too restrictive, >> > > Depends what you mean by ‘work’. I’d rather call it ‘have an effect’. In > most cases the first variant will be chosen. Another one will be > selected if: > • the multi-switch ends up at the bottom of a page (not necessarily the > last one), > • there is not enough room left to fit the first variant, > • there is a later variant that is smaller than the first one. > > If there is no such variant, then nothing will be rendered. > > Does that make sense? > > > Vincent > > +1 >> >> On 4/26/14, 11:49 PM, Luis Bernardo wrote: >> >>> >>> >>> On 4/24/14, 11:58 PM, Luis Bernardo wrote: >>> >>>> >>>> Vincent, if you hold off tallying the votes till Monday then I will run >>>> some tests before I vote. >>>> >>>> On 4/22/14, 5:11 PM, Vincent Hennebert wrote: >>>> >>>>> Hi, >>>>> >>>>> as you may be aware, Seifeddine Dridi has been working for the past few >>>>> months on an extension to manage the white space available in >>>>> a document. It is based on the fo:multi-switch element and selects the >>>>> first fo:multi-case child that fits on the page. That allows to define >>>>> smaller variants in case there is not enough space left on the page. >>>>> >>>>> The approach is similar to what is described here: >>>>> http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement >>>>> >>>>> All patches, comments and discussions are available in the following >>>>> JIRA issue: >>>>> https://issues.apache.org/jira/browse/FOP-2293 >>>>> >>>>> The code is here: >>>>> http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/ >>>>> Temp_WhitespaceManagement >>>>> >>>>> >>>>> It has reached a state where we believe it is ready to be merged to >>>>> trunk. >>>>> >>>>> This vote will run until Friday, 25th April 16:00 UTC. >>>>> >>>>> +1 from me. >>>>> >>>>> Thanks, >>>>> Vincent >>>>> >>>> >>>> >>> >>
