AW: hack to avoid memory overflow with tables
Glen Mazza wrote: FOP's goals should be (1) to be compliant/accurate with the spec The Area Tree is an implementation specification: either the XSL editors remove it from the specs or they specify it precisely as a portable, device-independent print file format. I ran Chuck Paussa's FO schema thru Castor. Anything goes and is formally valid. (2) be able to generate the largest numbers of huge files in the smallest amount of time. Is the design optimized for big DocBooks, accounting reports 15'000 uniform pages long, many small business documents? Reminder on renderer requirements: o Data: basic draw objects (current FOP uses nothing else from the area tree). o Physical printers: pages in a sequential data stream o AWT viewer: random access to pages o PDF: finished pages may be shipped to the renderer, accepted page references don't cause page break changes. To me, multiple layout strategies is really like saying multiple applications. (After all, the layout handler and renderers *form* an XSL FO formatter.) Is there a common agreement on FOP components, processing modes (push/pull), intermediate data storage and the suitable interfaces? An overall design given, plugins and multiple layout strategies can be defined and evaluated. Most likely the findings will be: there is one layout strategy. Playing with spacing and balancing, hyphenation is switched off on demand. Plus some performance tips like: do not use forward page references, auto-sized big tables, text columns ... Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Peter B. West wrote: While I don't denigrate any of these ongoing efforts, I am increasingly of the view that everything occurring between the reading of the fo xml and the layout of the area tree is interconnected in very nasty and intricate ways. The description of this process in the Rec (I resisted the obvious temptation here) has done many developers, including the FOP developers, a great disservice. It's this intertwining that makes me skeptical about pluggable layout. It may be feasible, but I don't see that it is feasible until we have a very good understanding of the way layout will be achieved, and a full picture of the flow of control in the first full implementation. My naive understanding of the Area Tree is that it could / should be constructed as a view of the FO tree. It should not, for example, IMO, contain any Strings at all, but objects in it should contain offset and size values for the parent FOText object in the FO tree. Similarly, perhaps it should not contain the trait values at all, but should compute them from the parent on-the-fly. The FO tree should normalize the values as much as possible (which in many cases is completely), then the Area tree can complete whatever computation is necessary before returning the value to use. I realize that this violates your compute-it-once principle, but I was frankly confused by that principle. It seemed to me that the intertwining issues that you mention utterly prevent compute-it-once. Second, and more importantly, regardless of what design is used in the Area Tree, there is nothing that prevents us from factoring code that is common to more than one LayoutStrategy into a module that is usable by any LayoutStrategy. If there are issues that force things to be intertwined, then those could be common code. Factoring out the high-level control is still a valuable and achievable step forward, but I'm not sure about control of when layout is started, when FO trees are destroyed. I assume that refers to the patient vs. eager layout discussion. At that level, certainly, control values can be factored out. Actually the two examples listed are, in my mind, examples of the high-level control issues that we want factored out. Patient vs. eager is only part of the story. Also included here are such issues as reusing session and document objects in embedded environments. I don't want to discourage your efforts, but I think you will need to keep these things in mind. I will. Thanks. If I come back humbled from the effort, perhaps at least some useful documentation will emerge. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Chris Bowditch wrote: What you say is true, but I think you missed one thing from your analysis: what if solution A took x seconds and B took x+2 seconds, but B had a greater level of compliance and produced better results than solution A? Then you would want to give the users the choice between better results or performance. Which solution you choose would then depend on the requirements of the situation. I dont think you could just discard solution B because it is slower. You would try to work with A, but if the document was too complex to get good results with A, then the user could switch to using B Well said, and I think it even goes deeper than this. It may actually be /useful/ to have non-compliant LayoutStrategies. If a minimally compliant LayoutStrategy required 120% memory, or 2x processing time over a leaner but noncompliant LayoutStrategy (like our maintenance branch code), there will be some, especially in embedded environments, that will prefer the noncompliant LayoutStrategy. It may be possible within a LayoutStrategy to allow the user to configure some of these tradeoffs as well. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Response below (one of these glorious days, I can stop using Outlook...) -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 7:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: hack to avoid memory overflow with tables FOP is ultimately a mathematical entity, so we should be able to avoid the matter-of-opinion conclusions that would lead to multiple layout strategies. While I believe this is generally true, I remain skeptical that there is always a perfect layout strategy available every time. I think this might especially be true in cases of overconstraint relaxing or recovering from anomalous documents. My first impression is that either of these processes will largely be governed by heuristics, and it's my experience that where heuristics are involved, matters of opinion quickly follow. Moreover, is FOP really that far from, say, the HTML rendering engine in a web browser with respect to layout decisions? I see a lot of interpretations and opinions going on in those engines, which is why two browsers sometimes interpret my HTML table layouts in different ways. While there can be plenty of discussion of how best to obtain #1 and #2, once it is determined that solution A takes x seconds and solution B takes x + 2 seconds, you tend to go with solution A. So over the long term, multiple layout strategies may not be needed. They may not, but I think they might. I can safely say that I haven't read all of the FO spec, but I do see the word may cropping up from time to time with respect to spec compliance. I don't think we can create a single layout strategy that correctly selects the correct side of that may every time. For certain classes of documents (which, for argument's sake, aren't readily detectable in a programmatic way), the choice has to be made, and why not leave that choice in the hands of programmers and operators? I just mention these sorts of things because, all too often, spec compliance eventually becomes a matter of opinion anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
--- Rhett Aultman [EMAIL PROTECTED] wrote: Moreover, is FOP really that far from, say, the HTML rendering engine in a web browser with respect to layout decisions? I see a lot of interpretations and opinions going on in those engines, which is why two browsers sometimes interpret my HTML table layouts in different ways. Exactly--note there are two *different* browsers, each choosing to implement the HTML standard differently, each hoping their decision is the best for the most number of users. To me, multiple layout strategies is really like saying multiple applications. (After all, the layout handler and renderers *form* an XSL FO formatter.) There are already plenty of teams trying to implement the XSL FO spec, each making its own decisions on which layouts/goals/tradeoffs, etc. are best. FOP is one of them--hopefully it will make the right decisions to have a large market share. FOP's goals should be (1) to be compliant/accurate with the spec, and (2) be able to generate the largest numbers of huge files in the smallest amount of time. Instead of pluggable layout strategies, it may be better to have compiler switches for the various output types that would allow the user to make goal #1 vs. goal #2 tradeoffs where appropriate. We can put them in the CLI, and others wishing to build a GUI on top of FOP can nicely include them on options screens, etc. Glen __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RC4 (was Re: hack to avoid memory overflow with tables)
J.Pietschmann schrieb: Hi all, now that there are a few more modifications in the maintenance branch, waht about including the fixes mentione here: http://marc.theaimsgroup.com/?l=fop-userm=105371539508744w=2 It would need some testing (read 0.20.5rc4) Nooo, no more RCs for 0.20.5 please It's almost one year after the last release and as it seems quite stable now so I would really like to make the release soon. Yes I know we agreed on 0.20.5 beeing the last release from maintenance branch but making RCs after RCs is IMHO worser than making changes after the last release and providing daily builds or whatever. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hack to avoid memory overflow with tables
My thoughts tend to go in the direction to factor out support subsystems like fonts, PDF, SVG etc. These are areas where a lot of improvements have happened during the last months and I'm currently ending up applying bugfixes in two places. As Peter I see a lot of complications in trying to bring the two layout engines under one umbrella, though if you find a good way I'm certainly not going to stand in the way. I've decided to stay out of the layout engine (for now) because I've never invested enough time to really be of use in there. So my place is currently the support subsystems because that's where I can really make a difference. On 27.05.2003 19:32:07 Victor Mote wrote: Jeremias Maerki wrote: I'm slowly getting the impression it may be better if we really totally modularize FOP (splitting it up into several independently usable subprojects) so development is only split in the layout field which is the major problem-child here. But that alone would take long enough and I can't even imagine how much it will hurt the redesign. You're on the right track, but I don't know that we need separate subprojects. I am just starting to implement an idea that I have been kicking around for several weeks. I want to create a LayoutStrategy that is either abstract or an interface, and which can be subclassed/implemented by each concrete strategy. We currently have two -- one in the redesign branch, and one in the maintenance branch. The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be releasing code from the trunk). This would allow us to start releasing code from the trunk, and would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc. This is something we really should do eventually anyway, and IMO it is better to do sooner than later. snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
From: Glen Mazza [EMAIL PROTECTED] snip/ 1.) Generate multiple document types accurately. 2.) Generate a high number of very large documents in a very short amount of time, with high, very large, and very short taken to their mathematical limits. While there can be plenty of discussion of how best to obtain #1 and #2, once it is determined that solution A takes x seconds and solution B takes x + 2 seconds, you tend to go with solution A. So over the long term, multiple layout strategies may not be needed. What you say is true, but I think you missed one thing from your analysis: what if solution A took x seconds and B took x+2 seconds, but B had a greater level of compliance and produced better results than solution A? Then you would want to give the users the choice between better results or performance. Which solution you choose would then depend on the requirements of the situation. I dont think you could just discard solution B because it is slower. You would try to work with A, but if the document was too complex to get good results with A, then the user could switch to using B Chris _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
--- Chris Bowditch [EMAIL PROTECTED] wrote: From: Glen Mazza [EMAIL PROTECTED] snip/ 1.) Generate multiple document types accurately. 2.) Generate a high number of very large documents in a very short amount of time, with high, very large, and very short taken to their mathematical limits. While there can be plenty of discussion of how best to obtain #1 and #2, once it is determined that solution A takes x seconds and solution B takes x + 2 seconds, you tend to go with solution A. So over the long term, multiple layout strategies may not be needed. What you say is true, but I think you missed one thing from your analysis: what if solution A took x seconds and B took x+2 seconds, but B had a greater level of compliance and produced better results than solution A? No--that wasn't missed, except that I wasn't clear on #1 when I said accurate--it also meant compliant with the spec. In the case given above, if A is not in compliance it would be tossed out to begin with. FOP must first be a reference implementation of the XSL-FO standard (#1). As for producing better results (after compliance)--I would like to think the system designed could be such that the renderers are user-pluggable and -extensible--but my current knowledge of FOP is not formed enough to comment intelligently on that. Back to studying... ;) Glen Then you would want to give the users the choice between better results or performance. Which solution you choose would then depend on the requirements of the situation. I dont think you could just discard solution B because it is slower. You would try to work with A, but if the document was too complex to get good results with A, then the user could switch to using B Chris _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
From: Glen Mazza [EMAIL PROTECTED] snip/ As for producing better results (after compliance)--I would like to think the system designed could be such that the renderers are user-pluggable and -extensible--but my current knowledge of FOP is not formed enough to comment intelligently on that. Back to studying... ;) If I am understanding you correctly, then you are talking about having pluggable renderers instead of pluggable layout solutions? Surely producing better results is down to both the layout engine and renderer, which brings us back to the need for pluggable layout engines Chris _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Jeremias Maerki wrote: I'm slowly getting the impression it may be better if we really totally modularize FOP (splitting it up into several independently usable subprojects) so development is only split in the layout field which is the major problem-child here. But that alone would take long enough and I can't even imagine how much it will hurt the redesign. You're on the right track, but I don't know that we need separate subprojects. I am just starting to implement an idea that I have been kicking around for several weeks. I want to create a LayoutStrategy that is either abstract or an interface, and which can be subclassed/implemented by each concrete strategy. We currently have two -- one in the redesign branch, and one in the maintenance branch. The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be releasing code from the trunk). This would allow us to start releasing code from the trunk, and would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc. This is something we really should do eventually anyway, and IMO it is better to do sooner than later. There are three issues: 1) Some will not like this approach as it seems to draw resources away from the redesign. I'll not reargue this issue again now unless it is needed. In short, nothing is being done on redesign now, so how can it possibly be hurt by anything? Also, eliminating thrashing between two branches will help all of us find resources to work on layout redesign. 2) Some will think that bringing the maintenance branch layout into the redesign will reintroduce the maintenance branch problems. Obviously, this should be avoided, and I think it can be. There are no doubt methods and data which will need to be moved around to get the maintenance branch layout modularized, but it seems possible. 3) It would be helpful to resolve some of our high-level control issues before starting down this path, or at least as part of this project. Moving control of when layout is started, when FO trees are destroyed, etc. up to higher-level objects will be extremely helpful in isolating these subsystems from each other and allowing multiple layout strategies. I see the sequence as follows: 1. Resolve design of, then implement the high-level control changes. This is the Session / Document / Rendering Context issue discussed on the Avalonization wiki, section entitled Startup Concepts Proposal at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization 2. Isolate the (existing redesign) layout by forcing all contact with the layout systems to run through the LayoutStrategy. Every layout class except the Stategy implementation becomes non-public (I think). 3. Drop in the maintenance branch layout as an implementation of LayoutStrategy, keeping it isolated as well. Even if this effort is unsuccessful for some reason, or the redesign layout is completed before this can be done, steps one and two above are still needed useful. I really didn't want to mention any of this until it was done, but I wanted to encourage Jeremias' train of thought. Also, coming to an agreement on steps one and two, and completing them, makes step three much easier. If we can reach a consensus on items 1 and 2, I'll start on them right away. I don't think they are big tasks, but they are pervasive and design-oriented, and I think they require your approval. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
--- Victor Mote [EMAIL PROTECTED] wrote: The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be releasing code from the trunk). FOP is ultimately a mathematical entity, so we should be able to avoid the matter-of-opinion conclusions that would lead to multiple layout strategies. I see FOP's goals as twofold: 1.) Generate multiple document types accurately. 2.) Generate a high number of very large documents in a very short amount of time, with high, very large, and very short taken to their mathematical limits. While there can be plenty of discussion of how best to obtain #1 and #2, once it is determined that solution A takes x seconds and solution B takes x + 2 seconds, you tend to go with solution A. So over the long term, multiple layout strategies may not be needed. Glen __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hack to avoid memory overflow with tables
Victor, Jeremias, Just a couple of notes on the discussion below. It is a mistake to say, because there is no great ferment of coding, that nothing is being done on the redesign of layout. I, for one, am currently giving the layout a great deal of thought, triggered in my case by the requirements of integrating the alt.design FO tree. I'm sure the Keiron is in the same boat, as are you, Jeremias and, I think, Jorg (my mailer may scramble this). While I don't denigrate any of these ongoing efforts, I am increasingly of the view that everything occurring between the reading of the fo xml and the layout of the area tree is interconnected in very nasty and intricate ways. The description of this process in the Rec (I resisted the obvious temptation here) has done many developers, including the FOP developers, a great disservice. It's this intertwining that makes me skeptical about pluggable layout. It may be feasible, but I don't see that it is feasible until we have a very good understanding of the way layout will be achieved, and a full picture of the flow of control in the first full implementation. Factoring out the high-level control is still a valuable and achievable step forward, but I'm not sure about control of when layout is started, when FO trees are destroyed. I assume that refers to the patient vs. eager layout discussion. At that level, certainly, control values can be factored out. I don't want to discourage your efforts, but I think you will need to keep these things in mind. Peter Victor Mote wrote: Jeremias Maerki wrote: I'm slowly getting the impression it may be better if we really totally modularize FOP (splitting it up into several independently usable subprojects) so development is only split in the layout field which is the major problem-child here. But that alone would take long enough and I can't even imagine how much it will hurt the redesign. ... In short, nothing is being done on redesign now, so how can it possibly be hurt by anything? ... It would be helpful to resolve some of our high-level control issues before starting down this path, or at least as part of this project. Moving control of when layout is started, when FO trees are destroyed, etc. up to higher-level objects will be extremely helpful in isolating these subsystems from each other and allowing multiple layout strategies. I see the sequence as follows: 1. Resolve design of, then implement the high-level control changes. This is the Session / Document / Rendering Context issue discussed on the Avalonization wiki, section entitled Startup Concepts Proposal at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization 2. Isolate the (existing redesign) layout by forcing all contact with the layout systems to run through the LayoutStrategy. Every layout class except the Stategy implementation becomes non-public (I think). 3. Drop in the maintenance branch layout as an implementation of LayoutStrategy, keeping it isolated as well. Even if this effort is unsuccessful for some reason, or the redesign layout is completed before this can be done, steps one and two above are still needed useful. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: table overflow and markers on 20.2
[EMAIL PROTECTED] wrote: The markers work fine except in one instance: if ROW4 and ROW5 overflow into the next page, the retrieve marker will pull ROW5MARKERDATA1 and ignore ROW4MARKERDATA1 even though ROW 4 is a distinctly new row. If more than two rows overflow, it seems to work OK (i.e. if ROW3,ROW4 and ROW5 overflow, it pulls from ROW3). This could have something to do with the spilling algorithm. The ROW4 is added to a page, with markers, then it is discovered not to fit, the layout is undone and the row goes onto the next page. It is quite possible that markers aren't handled properly in this case. There *could* be problems with rendering areas if the marker isn't the first child of the FO it marks, though I was unsuccessful so far to construct one. I do get several ERROR [fop]:fo:marker must be an initial child,and 'marker-class-name' must be unique for same parent messages, Markers which cause the latter message are ignored. You should fix these errors. The first message can already be caused by whitespace preceding the marker, like fo:table-cell fo:marker ... (you see the whitespace, don't you?) This is usually not a real pressing problem, though it is always advisable to fix error messages as well as warnings, lest you ignore something important. but I thought these were a function of markers in 20.2. Duh? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: table overflow and markers on 20.2
J.Pietschmann: Let me restate the line: but I thought these were a function of markers in 20.2. as but I thought these were a function of the unfinished markers in 20.2. Sorry if I offended. Thanks for the info. -Lou J.Pietschmann [EMAIL PROTECTED] on 08/01/2002 09:30:29 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: table overflow and markers on 20.2 [EMAIL PROTECTED] wrote: The markers work fine except in one instance: if ROW4 and ROW5 overflow into the next page, the retrieve marker will pull ROW5MARKERDATA1 and ignore ROW4MARKERDATA1 even though ROW 4 is a distinctly new row. If more than two rows overflow, it seems to work OK (i.e. if ROW3,ROW4 and ROW5 overflow, it pulls from ROW3). This could have something to do with the spilling algorithm. The ROW4 is added to a page, with markers, then it is discovered not to fit, the layout is undone and the row goes onto the next page. It is quite possible that markers aren't handled properly in this case. There *could* be problems with rendering areas if the marker isn't the first child of the FO it marks, though I was unsuccessful so far to construct one. I do get several ERROR [fop]:fo:marker must be an initial child,and 'marker-class-name' must be unique for same parent messages, Markers which cause the latter message are ignored. You should fix these errors. The first message can already be caused by whitespace preceding the marker, like fo:table-cell fo:marker ... (you see the whitespace, don't you?) This is usually not a real pressing problem, though it is always advisable to fix error messages as well as warnings, lest you ignore something important. but I thought these were a function of markers in 20.2. Duh? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7323] - Content overflow in fo:table-cell if content too long
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7323. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7323 Content overflow in fo:table-cell if content too long [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-06-03 08:18 --- This is, strictly speaking, a feature rather than a bug. Without opportunities to insert automatic line breaks, or hyphenation, long character strings are allowed to overflow the box they are in. How the overflow is handled is determined by the overflow property in effect. The default value is auto, which can be interpreted as whatever fits. http://www.w3.org/TR/xsl/slice7.html#overflow, in particular FOP implements only the overflow=visible setting. FOP does not yet support any other setting (actually, this is a bug, already reported multiple times). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7323] - Content overflow in fo:table-cell if content too long
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7323. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7323 Content overflow in fo:table-cell if content too long [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows NT/2K |All Platform|PC |All - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7323] New: - Content overflow in fo:table-cell if content too long
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7323. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7323 Content overflow in fo:table-cell if content too long Summary: Content overflow in fo:table-cell if content too long Product: Fop Version: 0.20.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If a fo:table-cell contains a single word (consisting only of characters) that does not fit into the cell's block area (i.e., it is too long), that word is outputted anyway, overlapping with any content on the right side to the cell. I prepared an example .fo file which demonstrates he problem: ?xml version=1.0 encoding=iso-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple- page-master widows=3 orphans=3 margin-right=20mm margin-left=20mm margin- bottom=20mm margin-top=20mm page-width=210mm page-height=297mm master-name=a4 fo:region-before extent=10mm/ fo:region-body margin-bottom=10mm margin- top=10mm/ fo:region-after extent=10mm/ /fo:simple-page-master /fo:layout- master-set fo:page-sequence master-reference=a4 fo:flow flow-name=xsl-region- body fo:table fo:table-column column-width=30mm/ fo:table-column column- width=140mm/ fo:table-header border-bottom-width=1pt border-bottom- style=solid fo:table-row fo:table-cell border-end-style=solid border-end- width=1pt fo:block font-size=10pt font-weight=bold margin-left=2pt margin- right=2ptDatum/fo:block /fo:table-cell fo:table-cell border-end- style=solid fo:block font-size=10pt font-weight=bold margin-left=2pt margin- right=2ptMassnahme/fo:block /fo:table-cell /fo:table-row /fo:table- header fo:table-body fo:table-row fo:table-cell border-end-style=solid fo:block font-size=10pt text-align=start font-weight=normal padding-before=10pt margin-left=2pt margin-right=2pt21.03.2002 13:59:37/fo:block /fo:table-cell fo:table-cell inline-progression-dimension=95mm block-progression-dimension=95mm width=95mm border-end-style=solid !-- CRITICAL LINE START -- fo:block font- size=10pt text-align=start font-weight=normal padding-before=10pt margin- left=2pt margin- right=2ptDiesisteinTestobeinüberlangeswortüberdenrandhinausgeschriebenwirdodernichtmalschauenwennjagibtseinproblem:)/fo:block !-- CRITICAL LINE END -- /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
overflow support
Folks: Is overflow=hidden supported on a block? I'm trying to get my block data to truncate at the cell boundary. TIA, -Lou - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
table-cells and clipping (overflow=hidden)
Title: table-cells and clipping (overflow=hidden) Hello, I've got a problem with tables and clipping. In my document, content of a table cell shouldn't exceed the tabel cell. For this reason I tried to use the clip or overflow property, but it doesn't work. Content containing spaces is wrapped, but other content exceed the cell. This is a snippet from my code: ... fo:table-row fo:table-cell fo:block clip=auto overflow=hidden1.7976931348623157E308/fo:block /fo:table-cell fo:table-cell fo:block clip=auto overflow=hiddenyou can't read this/fo:block /fo:table-cell ... Is this my fault or a bug in FOP? I'm not too good in XSL:FO... is there another way of defining things matching my needs? Best regards, Jens Jens von Pilgrim 4flow AG Berlin, Germany
overflow=hidden and big images...
Hi Folks! I wanted to put a logo on a letter using a block-container where I put my image in. The image should be clipped if it is too big. But all that happens is that the image disapears. Also if I used overflow=visible the image disapears. Is that a bug or a feature?? Christian __ DIRON Wirtschaftsinformatik GmbH Co. KG Christian Beer ([EMAIL PROTECTED]) Daimlerweg 39-41Tel. : +49(251)979-200 48163 Muenster Fax : +49(251)979-2020 Germany Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: overflow=hidden and big images...
Fop doesn't support block-container. See: http://xml.apache.org/fop/implemented.html Regards, Etwin - Original Message - From: Beer, Christian [EMAIL PROTECTED] To: Fop-liste (E-Mail) [EMAIL PROTECTED] Sent: Tuesday, October 23, 2001 4:09 PM Subject: overflow=hidden and big images... Hi Folks! I wanted to put a logo on a letter using a block-container where I put my image in. The image should be clipped if it is too big. But all that happens is that the image disapears. Also if I used overflow=visible the image disapears. Is that a bug or a feature?? Christian __ DIRON Wirtschaftsinformatik GmbH Co. KG Christian Beer ([EMAIL PROTECTED]) Daimlerweg 39-41Tel. : +49(251)979-200 48163 Muenster Fax : +49(251)979-2020 Germany Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: overflow=hidden and big images...
That page must be out of date. I use block-container is several places successfully. Scott -Original Message- From: Etwin van Krimpen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 10:40 AM To: [EMAIL PROTECTED] Subject: Re: overflow=hidden and big images... Fop doesn't support block-container. See: http://xml.apache.org/fop/implemented.html Regards, Etwin - Original Message - From: Beer, Christian [EMAIL PROTECTED] To: Fop-liste (E-Mail) [EMAIL PROTECTED] Sent: Tuesday, October 23, 2001 4:09 PM Subject: overflow=hidden and big images... Hi Folks! I wanted to put a logo on a letter using a block-container where I put my image in. The image should be clipped if it is too big. But all that happens is that the image disapears. Also if I used overflow=visible the image disapears. Is that a bug or a feature?? Christian __ DIRON Wirtschaftsinformatik GmbH Co. KG Christian Beer ([EMAIL PROTECTED]) Daimlerweg 39-41Tel. : +49(251)979-200 48163 Muenster Fax : +49(251)979-2020 Germany Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: overflow=hidden and big images...
Actually, it does, although not completely. jw -Original Message- From: Etwin van Krimpen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 9:40 AM To: [EMAIL PROTECTED] Subject: Re: overflow=hidden and big images... Fop doesn't support block-container. See: http://xml.apache.org/fop/implemented.html Regards, Etwin - Original Message - From: Beer, Christian [EMAIL PROTECTED] To: Fop-liste (E-Mail) [EMAIL PROTECTED] Sent: Tuesday, October 23, 2001 4:09 PM Subject: overflow=hidden and big images... Hi Folks! I wanted to put a logo on a letter using a block-container where I put my image in. The image should be clipped if it is too big. But all that happens is that the image disapears. Also if I used overflow=visible the image disapears. Is that a bug or a feature?? Christian __ DIRON Wirtschaftsinformatik GmbH Co. KG Christian Beer ([EMAIL PROTECTED]) Daimlerweg 39-41Tel. : +49(251)979-200 48163 Muenster Fax : +49(251)979-2020 Germany Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
overflow
Hi*, how can I get an overflow=hidden or something similar in a fo:table-row? I'm using the old Version 0.16. Thanks, Karin Thaens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
How to get information about overflow...
Hi list!
I have fop-code to create a postcard (page-height=105mm
page-width=148mm) where
on the first page there is an image and on the second page there should be
text on
the left and space on the right (for the address).
This snippet should create the text on the left:
fo:page-sequence master-name=second-page
fo:flow flow-name=xsl-region-body
!-- height = page-height - (margin-top + margin-bottom)
width = (page-width - (margin-left + margin-right)) / 2 - 1 --
fo:block-container width=68mm height=95mm position=absolute
top=0mm left=0mm overflow=hidden
fo:block font-size={$Font-Size} font-family={$Font-Family}
font-weight={$Font-Weight} font-style={$Font-Style}
color={$Font-Color} overflow=hidden
!-- Space for the signature-line... --
fo:block space-after.optimum=10pt
#160;
/fo:block
!-- text... --
xsl:for-each select=Text/p
fo:block language=de hyphenate=true
xsl:value-of select=text()/
/fo:block
/xsl:for-each
!-- ... --
That works fine, if the text is short enough. If it is too long for the
page,
there is no warning (like ) but the text is missing...
I thought that overflow=hidden should do the trick, but it doesn't!!
Please help!!
Greetings
Christian beer
__
DIRON Wirtschaftsinformatik GmbH Co. KG
Christian Beer ([EMAIL PROTECTED])
Daimlerweg 39-41Tel. : +49(251)979-200
48163 Muenster Fax : +49(251)979-2020
Germany Email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Sequence master for overflow
Hi all, I'd like to specify a particular page-master (regions) for the first page and another page-master (other regions) for rest of the doc wich is the overflow of the first page. How could I do so ? Other question : Is it possible to avoid the page break into a block ? (page-break-inside=avoid doesn't seem to be supported) Thanks for helping. Romain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
overflow-paginate
I am looking for help with overflow-paginate function of XSL. I have data elements that overflow the block sizes and overflow-paginate=8.00in doesn't seem to be workning for me. Robyn MacDuff [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2170] - Table Column overflow - endless loop
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2170 *** shadow/2170 Wed Jun 13 21:56:55 2001 --- shadow/2170.tmp.18535 Mon Jun 18 01:39:14 2001 *** *** 2,9 | Table Column overflow - endless loop | ++ |Bug #: 2170Product: Fop | ! | Status: NEW Version: all | ! | Resolution:Platform: PC | | Severity: MajorOS/Version: Windows NT/2K | | Priority: Other Component: pdf renderer| ++ --- 2,9 | Table Column overflow - endless loop | ++ |Bug #: 2170Product: Fop | ! | Status: RESOLVEDVersion: all | ! | Resolution: FIXED Platform: PC | | Severity: MajorOS/Version: Windows NT/2K | | Priority: Other Component: pdf renderer| ++ *** *** 1632,1634 --- 1632,1637 /fo:flow /fo:page-sequence /fo:root + + --- Additional Comments From [EMAIL PROTECTED] 2001-06-18 01:39 --- + Works as of FOP 0.19 \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
