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: header AAA CCC AAA CCC AAA CCC BBB BBB BBB footer header DDD DDD DDD footer 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. snip/ HTH, Vincent
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.
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.
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: [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.
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.
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
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
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
