Re: Work on ChangingIPDHack Finished
Hi, Vincent Hennebert wrote: > Hi Simon, > > Thank you for giving a go at testing the branch. I could reproduce the > hyphenation and flow_changing-ipd_4.xml problems. Regarding the stretch > issue, could you send me a sample FO file? I suspect that this may be > normal in the sense that the layout policy is slightly different when > there is changing IPD: Instead of being full total-fit, it’s ‘n-pages > total fit’ i.e., total-fit over the number of pages that have the same > ipd. When the ipd changes, the best node /so far/ is selected, which may > be different from the node that is part of the optimal solution, had the > ipd remained the same. I had a look at the file Simon sent me off-list, and this is indeed what happens. Basically, the first page contains n lines with the ChangingIPD version, and n + 2 with the Trunk. The n-lines version is the one that is closest to the spaces’ natural lengths. In the n + 2 version spaces are shrunk quite a bit. The n-lines version has less demerits than the n + 2 one, so it’s the one that is chosen by the algorithm before re-generating the Knuth elements for the next page with a different width. But it appears that chosing the n + 2 version leads to less total demerits, so this is why it is selected by the Trunk. I committed yesterday fixes for the other bugs that Simon rose. Thanks again for testing, Vincent
Re: Work on ChangingIPDHack Finished
Hi Simon, Thank you for giving a go at testing the branch. I could reproduce the hyphenation and flow_changing-ipd_4.xml problems. Regarding the stretch issue, could you send me a sample FO file? I suspect that this may be normal in the sense that the layout policy is slightly different when there is changing IPD: Instead of being full total-fit, it’s ‘n-pages total fit’ i.e., total-fit over the number of pages that have the same ipd. When the ipd changes, the best node /so far/ is selected, which may be different from the node that is part of the optimal solution, had the ipd remained the same. Simon Pepping wrote: > In testcase flow_changing-ipd_4.xml, when I put all content in 1 page > sequence, the paragraphs in the list do not appear. > > In the same testcase, the space between the table and paragraph 1_5 is > not rendered. This one is a known limitation. Since the table doesn’t support changing ipd its elements are put as they are on the next page, and layout is re-started after the table, at paragraph 1_5. The SpaceResolver then believes that the paragraph starts the sequence, so treats the space as if it were starting the page, so discards it since its conditionality is left to "discard". I’m not planning to fix that problem since it involves too many changes in the SpaceResolver. The work-around is to set the conditionality to "retain". Thanks, Vincent
Re: Work on ChangingIPDHack Finished
In testcase flow_changing-ipd_4.xml, when I put all content in 1 page sequence, the paragraphs in the list do not appear. In the same testcase, the space between the table and paragraph 1_5 is not rendered. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Work on ChangingIPDHack Finished
When the page contains stretch or shrink, your changingIPDHack applies more stretch than the trunk code. I could make a difference of two lines more on an A4 page height with trunk code with fairly strong stretch and shrink. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Work on ChangingIPDHack Finished
Vincent, Nice work. I did find a problem: When hyphenation is on, the unfinished paragraph at the end of a page is started from the beginning on the next page. When the page is really small, like one may do for testing, this throws FOP even in an endless loop, because each page ends somewhere in the first paragraph. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Work on ChangingIPDHack Finished
Hi All, I’m basically finished with the implementation of the hack to handle pages of different widths. As a remainder, tables and lists aren’t supported; this means that they will flow on the new page without taking the new width into account. So if there is a switch between e.g. a landscape page and a portrait page, part of the table/list will be silently rendered outside of the page. This is a limitation that I a not willing to fix as this implies too much work on something that will be made obsolete by the new layout approach anyway. All of the other FOs should be supported. I committed some simple test cases in the branch, but I’d be grateful if people could test it with their own (possibly real-life) FO files. I’d like to do it in two steps: first ask for feedback here (I know there are plenty of people silently watching this list ;-) ), then broaden the audience and ask on the users list. To ease the lives of users I’ll probably set up a web page in my personal area at people.apache.org, and provide links to ready-made binary archives, just like official releases. People who aren’t keen on building the branch from sources can feel free to wait for that phase. The branch is to be found here: http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack Or, for European users: http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack My hope is that if there are any ‘big’ bugs left that make FOP crash, they will be spotted in the first phase, and can quickly be fixed and re-tested in short commit/copy update/re-build/re-test cycles. Something that power users shouldn’t be afraid of, whereas too frequent updates of the web page might confuse less knowledgeable users. Thanks, Vincent
