AW: empty columns on multi-column-page
Hi Vincent, If the wide block is in the first column, the result looks like I expected it, but then I had a wide block in the second column and instead of moving to the next page, I got balancing again: >>> I couldn't reproduce that. Can you please post the FO file showing the >>> issue? >> I attached my test file. On page three, the first line of Block U should be >> on page four. > Hmmm. > The diagnostic is quite easy: the first column doesn't contain any elastic > space and doesn't exactly fill the page; so there's enough room for the > spanning block to squeeze in one line of content, instead of being deferred > to the next page. Set background-color="#F0F0F0" on the region-body to more > easily see what's happening. I have no idea, how elastic space is defined, but I guess, orphan-widow-control would then take care of that problem? I'll have to check but I think, there's no case, where a wide block in a two-column layout should break after one line. > (As a side note, I saw you put the fox-needs-balancing property on the > page-sequence element. I think you want to define it on the spanning block > instead.) Yes, error in the test file. I thought, I'd put fox-needs-balancing in fo:flow with default true and in fo:block with default inherit. So the spanning blocks ( which, I assume, are what I called wide blocks) don't necessarily have to know about the property in the fo-file but could as well overwrite the flow setting, if necessary. Which, by the way, works quite fine, now I just have to find, how the property is correctly transfered from Block of Flow to LayoutContainer. > What eludes me in this particular case, though, is why the algorithm didn't > put an additional line of Qs at the bottom of the first column since there > is room for it. Another think I just saw: On page two, the left column contains 41 lines, the right column one more and on page three, the first column has 43 lines. > Anyway, this suddenly makes the problem a lot more difficult, I'm afraid, > because it becomes necessary to do something on the layout side. > I'm not too keen on it, I must say, since this whole area is likely to be > revised when introducing the new approach to line- and page-breaking. > You can work around the problem by making sure that the columns will always > exactly fill the pages, i.e. by adding elastic spaces between paragraphs. > If your content is so made that at least one elastic space can be found on > every column, then you should never encounter the issue. Except if the column is filled by one single block? > Or it will occur rarely enough that you will be happy to manually fix it when > it does. No, manual fixing is bad, since I expect pdfs with up to 1000 pages. > Then it's still worth implementing the solution I proposed, but it will have > to be demoted from the status of official FOP extension to the less glossy > one of cheap unofficial hack. At any rate, I think it's your only hope to > have something working by the 5th of December... Then it's always possible to > discuss about a more definitive solution. You know how it works. If I have a working hack by next Friday, I'll never find the time to make it a clean, official extension. :-( Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
On 27.11.2008 16:33, Max Berger wrote: The recent amount of discussion shows that your branch should be integrated into trunk as soon as possible, since it touches other areas as well, and these issues need to be resolved before 1.0beta. I got the same impression, but I don't know anything about the code itself. So +0.5 from me too. J.Pietschmann
Re: empty columns on multi-column-page
Hi Georg, Georg Datterl wrote: Hi Vincent, Indeed, it worked on a small example, but a bigger example gave me an unexpected heart attack. Maybe you shouldn't take this task too seriously. I'd hate that FOP causes you health problems ;-) You have no idea how many health problems I have already avoided just because FOP did what I needed. :-) Phew, I’m feeling reassured! Although you might not want to read further :-( If the wide block is in the first column, the result looks like I expected it, but then I had a wide block in the second column and instead of moving to the next page, I got balancing again: I couldn't reproduce that. Can you please post the FO file showing the issue? I attached my test file. On page three, the first line of Block U should be on page four. Hmmm. The diagnostic is quite easy: the first column doesn’t contain any elastic space and doesn’t exactly fill the page; so there’s enough room for the spanning block to squeeze in one line of content, instead of being deferred to the next page. Set background-color="#F0F0F0" on the region-body to more easily see what’s happening. (As a side note, I saw you put the fox-needs-balancing property on the page-sequence element. I think you want to define it on the spanning block instead.) What eludes me in this particular case, though, is why the algorithm didn’t put an additional line of Qs at the bottom of the first column since there is room for it. Anyway, this suddenly makes the problem a lot more difficult, I’m afraid, because it becomes necessary to do something on the layout side. I’m not too keen on it, I must say, since this whole area is likely to be revised when introducing the new approach to line- and page-breaking. You can work around the problem by making sure that the columns will always exactly fill the pages, i.e. by adding elastic spaces between paragraphs. If your content is so made that at least one elastic space can be found on every column, then you should never encounter the issue. Or it will occur rarely enough that you will be happy to manually fix it when it does. Then it’s still worth implementing the solution I proposed, but it will have to be demoted from the status of official FOP extension to the less glossy one of cheap unofficial hack. At any rate, I think it’s your only hope to have something working by the 5th of December... Then it’s always possible to discuss about a more definitive solution. WDYT? Vincent
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Adrian, since I have not actually followed the code: +0.5 The recent amount of discussion shows that your branch should be integrated into trunk as soon as possible, since it touches other areas as well, and these issues need to be resolved before 1.0beta. Max Vincent Hennebert schrieb: > Hi Adrian, > > I don’t know much about AFP, but from the little I know I fully imagine > that this must have been all but an easy task. > I haven’t followed your work closely, but you seem to have put a lot of > effort to it. Congratulations, and here’s my +1. > > Vincent > > > Adrian Cumiskey wrote: >> Hi all, >> >> I would like to call for a merge of the AFP branch [1] back into trunk. >> >> This branch [1] contains a major rewrite of pretty much all the >> original AFP code. The majority of >> the AFP code is now homed in its own package separate from the >> renderer code in org.apache.fop.afp. >> The AFPRenderer itself is now only sone 800 or so lines long down from >> the previous 1800+ lines and >> now more properly extends the AbstractPathOrientedRenderer. There is >> also now much more shared code >> now betweeen the PDF and AFP renderers. >> >> Major new functionality in the branch includes :- >> >> * An AFPGraphics2D implementation which provides the ability to use >> Batik to drive the production of >> AFP Graphics (GOCA) output from SVG. >> * Resource group leveling, external streaming and de-duplication of >> images and graphics using >> IncludeObject and ResourceGroup. >> * Native image embedding support (e.g. JPEG, GIF, TIFF) using >> ObjectContainer and a MOD:CA Registry >> implementation. >> * More robust AFP font parsing, although this is still in need of some >> rework in the future. >> >> I realize that testing these new AFP features in FOP may not be easy >> for some of you. You can >> however use the Infoprint Solutions (IBM) AFP Workbench Viewer for >> Windows >> (http://www.ibm.com/support/docview.wss?uid=psd1P4000360) to view the >> output. >> >> [1] >> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources >> >> >> +1 from me. >> >> Adrian. > signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 43474] [PATCH] wrap-option="wrap" doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #18 from Pascal Sancho <[EMAIL PROTECTED]> 2008-11-27 05:06:36 PST --- (In reply to comment #17) wrap-option is cited 3 times in REC 1.1: [1] Section 1.2.1 Paging and Scrolling [2] Section 4.7.2 Line-building [3] Section 7.16.13 wrap-option IMHO, there is inconsistency in recommendation, especially between [2] and [3]: in [3], when wrap-option="wrap", REC says "line-breaking will occur if the line overflows the available block width" but in [2], there is no tool to do what is required in [3], as Vincent said. So, I wonder whether FOP should not enforce a break if there is no break opportunity other than between 2 normal chars, regarding the wrap-option. [1] http://www.w3.org/TR/xsl11/#d0e297 [2] http://www.w3.org/TR/xsl11/#area-linebuild [3] http://www.w3.org/TR/xsl11/#wrap-option Pascal -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
AW: empty columns on multi-column-page
Hi Vincent, > > Indeed, it worked on a small example, but a bigger example gave me an > > unexpected heart attack. > Maybe you shouldn't take this task too seriously. I'd hate that FOP causes > you health problems ;-) You have no idea how many health problems I have already avoided just because FOP did what I needed. :-) > > If the wide block is in the first column, the result looks like I > > expected it, but then I had a wide block in the second column and > > instead of moving to the next page, I got balancing again: > I couldn't reproduce that. Can you please post the FO file showing the issue? I attached my test file. On page three, the first line of Block U should be on page four. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de foxneedsbalancing.fo Description: foxneedsbalancing.fo
Re: empty columns on multi-column-page
Hi Georg, Georg Datterl wrote: Hi Vincent, I started to fool around a bit with the FOP source code and your suggestion: I've just had a quick look and there seems to be almost nothing to do on the layout side (which is good news). You just have to go on l.111 of org.apache.fop.layoutmgr.PageBreaker (handleSpanChange method) and replace the assignment appropriately. Instead of: needColumnBalancing = (childLC.getNextSpan() == Constants.EN_ALL); something like needColumnBalancing = (childLC.getNextSpan() == Constants.EN_ALL) && childLC.nextHasFoxBalancingOption(); Simply setting false already gave me the desirable result on a small example. Indeed, it worked on a small example, but a bigger example gave me an unexpected heart attack. Maybe you shouldn’t take this task too seriously. I’d hate that FOP causes you health problems ;-) If the wide block is in the first column, the result looks like I expected it, but then I had a wide block in the second column and instead of moving to the next page, I got balancing again: I couldn’t reproduce that. Can you please post the FO file showing the issue? What I’m getting is that the spanning block is deferred to the next page. Something like that: AAA CCC AAA CCC AAA CCC BBB BBB BBB DDD DDD DDD Which should match your expectations, IIC. I guess, the next step is somewhere in Phase 3, but I've yet to understand the effect of needColumnBalancing there. Any hints? ;-) Columns are first typeset as normal, that is, as if there were no spanning block that follows. Which means that the first column is filled until the bottom of the page is reached, then the second column, etc. needColumnBalancing is used to indicate that the layout must be re-made: the first column must no longer be entirely filled, instead content must be spread over the columns so that they have similar heights. HTH, Vincent
DO NOT REPLY [Bug 43474] [PATCH] wrap-option="wrap" doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #17 from Vincent Hennebert <[EMAIL PROTECTED]> 2008-11-27 03:33:03 PST --- (In reply to comment #16) > (In reply to comment #15) > > I'm sorry to chime in so late but I don't think there is anything to do on > > FOP's side WRT this issue. > > On the one hand, I agree. I have mentioned this already in the past: > wrap-option="wrap" does not include an /obligation/ to perform line-wrapping. > > > If there is no opportunity to break inside the word > > then there's nothing FOP can do. > > Wrong. At least, slightly unfortunate choice of words: FOP /can/ definitely do > /something/ in this case. > > > The wrap-option property is meant to trigger > > the line-breaking mechanism in its usual accepted meaning; that is, break > > between words or at hyphenation points inside them, not at every letter if > > available space is abnormally low, or the word abnormally big. At least, > > that's > > my understanding of this property. > > IIC, there's a subtle difference between line-WRAPPING and line-BREAKING. > Line-wrapping being the more 'blind' of the two, if you will (simply wrap to > fit the text into the available space). The Recommendation remains vague in > this respect (and purposely so, I think). I don't think so. Section 4.7.2, “Line-building”, states that “The partitioning [must occur] at legal line-breaks. [...] the rules of the language, script and hyphenation constraints in effect must permit a line-break between [two areas].” http://www.w3.org/TR/xsl11/#area-linebuild It /might/ be acceptable to relax the line-breaking algorithm somehow when the 'script' property is set to 'none', but frankly I'm not too keen on implementing a special treatment just to cope with pathological cases. The code is already complicated enough. > It does not prescribe /how/ the text > should be wrapped or broken. We have decided to follow Unicode, but > ultimately, > we always have the last word. That is: if we choose to provide an additional > fallback mechanism, there is no relevant specification that makes this wrong. > > > In my opinion, this issue must be handled upstream. That is, zero-width > > space > > characters (U+200B) must be introduced at applicable places inside the word > > to > > provide FOP with more break opportunities. > > A legitimate option, but not always as easily done as it said. To get the > effect of real dynamic content-wrapping (fit as many characters on the line as > you can), you would force the user to insert a ZWSP in between every two > characters (either that or they should make a choice of every so-many > characters). Exactly. And I bet it's less complicated to implement some XSLT function or pre-processing step to do that than a dedicated extension in FOP's layout engine. > > But I don't think this is FOP's responsibility to do that. See also the > > following FAQ entry: > > http://xmlgraphics.apache.org/fop/faq.html#cells-overflow > > Maybe not, but it would mean a big relief for many users, I think, if FOP > would > take this responsibility, even if it is not mandated... Yes, but if we reason like this FOP would soon become like those Swiss knives with ridiculous numbers of blades ;-) (Note that I have nothing against Swiss knives, I've been owning one myself for years and it serves me very well! But it has only 6 functions.) More seriously, you could take it the other way around, and find users who wouldn't be happy at all to see FOP suddenly break their texts at arbitrary places, and would rather be warned when such situations are occuring, so that they can re-work their contents. Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: empty columns on multi-column-page ( Developer needed)
Dear FOP Developer, As stated in my previous mail, we need a fop extension to deactivate the column balancer in a multi-column layout with wide blocks. On pages containing a wide block (span="all"), all columns after the first column should be empty above the wide block. A wide block in a column after the first column should move to the next page. Since we need a solution no later than Friday, Dec. 5th, 2008 we are looking for outside resources (meaning you) having enough experience and time at hand to implement this extension (and get it committed to trunk) for us. So if you can help us, please contact me with a rough estimate when you could provide the solution and how much it would cost us. I'll wait for your response until Monday, Dec. 1st, 2008 12:00 GMT. Thank you for your help. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de
DO NOT REPLY [Bug 46276] Justified text rendered poorly in AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=46276 Adrian Cumiskey <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Adrian Cumiskey <[EMAIL PROTECTED]> 2008-11-27 02:47:21 PST --- This is a bug which I verified to be present in the AFP Workbench Viewer (2.04.01.07) not in the AFP output file. The second paragraph justified nicely when tested with the Internet Explorer AFP Viewer plugin (unknown version tested) and AFP Lookup 2.40 beta 2. Adrian. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Hi Adrian, I don’t know much about AFP, but from the little I know I fully imagine that this must have been all but an easy task. I haven’t followed your work closely, but you seem to have put a lot of effort to it. Congratulations, and here’s my +1. Vincent Adrian Cumiskey wrote: Hi all, I would like to call for a merge of the AFP branch [1] back into trunk. This branch [1] contains a major rewrite of pretty much all the original AFP code. The majority of the AFP code is now homed in its own package separate from the renderer code in org.apache.fop.afp. The AFPRenderer itself is now only sone 800 or so lines long down from the previous 1800+ lines and now more properly extends the AbstractPathOrientedRenderer. There is also now much more shared code now betweeen the PDF and AFP renderers. Major new functionality in the branch includes :- * An AFPGraphics2D implementation which provides the ability to use Batik to drive the production of AFP Graphics (GOCA) output from SVG. * Resource group leveling, external streaming and de-duplication of images and graphics using IncludeObject and ResourceGroup. * Native image embedding support (e.g. JPEG, GIF, TIFF) using ObjectContainer and a MOD:CA Registry implementation. * More robust AFP font parsing, although this is still in need of some rework in the future. I realize that testing these new AFP features in FOP may not be easy for some of you. You can however use the Infoprint Solutions (IBM) AFP Workbench Viewer for Windows (http://www.ibm.com/support/docview.wss?uid=psd1P4000360) to view the output. [1] https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources +1 from me. Adrian.
