Re: svn commit: r442282 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/extensions/ src/java/org/apache/fop/fo/extensions/
2006/9/11, Jeremias Maerki: As mentioned last month, I just changed the property names a little bit. If anyone finds these inappropriate, please yell. This is not a big deal, but the names bother me a bit. Reading widow-content-limit makes me believe that that corresponds to the maximum authorized amount for widow content, which sounds a bit strange. What about min-widow-content? But I wouldn't mind if you keep the current names. Vincent
Re: [Xmlgraphics-fop Wiki] Update of PageLayout/PageAndLineBreaking by SimonPepping
Hi Simon, I finally took the time to read and digest your Wiki page. This is an interesting reading. A few comments: According to that representation paragraphs with inline text have legal linebreak points. I consider those legal linebreak points also as legal pagebreak points. In addition, there are legal pagebreak points between the vertical elements such as paragraphs and blocks. One issue that will have to be addressed is that widow or keep-with-previous settings may invalidate some previously believed legal breakpoints. In such cases, active nodes which contain those breakpoints in their chains will have to be deactivated; if they were the chosen best nodes, some other nodes will somehow have to be retrieved to replace them. I hope this won't be a too great difficulty. Within the inner loop, we consider the page and paragraph layout between the active and the current pagebreak point. If the active breakpoint is within a paragraph, we calculate the best line breaks from that breakpoint to the end of the paragraph. For all complete Unless the current breakpoint lies in the same paragraph. In page independent linebreaking, for each feasible breakpoint the best node is retained, which represents the best layout of the paragraph up to that point, and which, due to the dynamic principle, is part of the best layout of the whole paragraph if that layout uses this breakpoint. If line numbers matter, the best node for each line number is retained. In page dependent linebreaking, even that is not enough. We must retain the best node for each vertical offset on the page, because that is the quantity that influences page breaking. This Good point. This led me to the following thoughts: Currently the iteration over the active nodes is broken into two loops: one loop for iterating over the line numbers, one for iterating over the active nodes associated to each line number. Why? Because if line widths aren't the same they have an influence on the computation of best line breaks. Because when considering a given legal breakpoint, we must know the width of the line it would end in order to be able to compute the shrinking/stretching for that line. In fact we make a distinction between line numbers because they determine the /context/ in which linebreaks are computed. If all the lines had the same widths such a distinction wouldn't be necessary. The merging of line- and page-breakings generalizes this problem of differing contexts. This time, not only the line number counts, but also the page number, the offset from the beginning of the page, the out-of-lines to be placed, etc. I think the greatest challenge will be to identify all the elements which determine that context, and to be able to compare two contexts and say if they are equivalent or not. Considering the case 1 you describe on the wiki page, there are only two different contexts: page number even or odd. In this case the offset from the beginning of the page doesn't count. In other more complex documents this may be much more complicated. When the linewidths depend on the page number, we need to remember the best pagebreak node for each feasible pagebreak point for each page number. Otherwise, we only need to remember the best pagebreak node for each feasible pagebreak point. Note that the latter condition is true in the presence of out-of-line elements, because those are related to the content of the page, not the the page number. Small typo: not the the page number Optimization opportunity 1: We may need to reuse many times the best layout from a breakpoint to the end of the paragraph, and the best layout from the start of the paragraph to a breakpoint. Therefore we need to store a reference to the best end node for either case in the active node. If we wish to take into account the different possible heights of the part of the paragraph, we need to store references to a set of best end nodes. Especially for long page sequences, a page breakpoint may be feasible both for an odd and an even page. In that case, we need to store different end points for each, due to the different line widths on odd and even pages. This optimization is certainly true for the start of the paragraph. There will be many page layouts on which the whole paragraph fits. So, this might be handled automatically by the dynamic algorithm if we were able to identify the different contexts. Optimization opportunity 2: Do we need to consider each active node? Or can we already determine that some active nodes will never give a better layout than others? Suppose that a paragraph has two feasible breakpoints A and B, which have an equal number of lines, or even the same height, before and after the page breakpoint. Suppose that B has a higher amount of demerits than A. Can we then conclude that B will never be part of the best layout, because a better layout can always be achieved with A? Yes, we can. Same here, we would just have to detect that linebreak
Re: Configuration file problems
Jeremias, What is the problem you are trying to address: 1. Users use configuration files with errors which can be detected by the fop-configuration schema, but they do not validate it. 2. Users use configuration files with errors which cannot be detected by the fop-configuration schema. Ad 1: It is perfectly possible to let fop validate the user configuration file in a command line invocation. The problem is to ensure that the location of the schema does not become a source of errors in its turn. It is possible to write an Entity and URI Resolver which looks for 'fop-configuration.xsd' along the classpath, and for other schemas and DTDs delegates to a CatalogResolver if that is available, and otherwise returns the absolute URI of the system or schema location path. Re extensibility: A XML file is validated according to the DTD or schema that it declares (Relax-NG is an exception). The user can put a DTD or schema of his own choice in the user configuration file: !DOCTYPE fop PUBLIC '-//MYSELF//DTD My FOP Configuration XML V1.0//EN' 'http://myserver.mydomain.eu/fop-configuration.dtd' and the parser will validate against it. This means that a user can extend the configuration file at will, and that FOP cannot be assured that the config file is valid. Embedded users can always avoid validation. I do like Manuel's suggestion to supply a separate command line validation option. Note that we have not advertised the configuration schema. It is not documented anywhere. I will add some documentation to the configuration web page. Ad 2: The schema cannot enforce a specific content model depending on the type attribute. But it does a nice job limiting the possibilities: One cannot mix and match parts of different renderer configuration options. For example, it is perfectly possible to configure a PostScript renderer with the elements applicable for a PDF renderer. But it is not possible to start with a filterList, and continue with auto-rotate-landscape. It is possible to force the correct content model for each renderer type by giving them different element names, e.g. renderer-application-pdf or application-pdf for short. Regards, Simon On Sun, Sep 10, 2006 at 02:52:31PM +0200, Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. The attempt to overlay the configuration layout with an XSD is generally a good idea but with the current configuration layout, it's not a workable solution. If anyone has a good plan to improve the situation, I'm all ears. I think the configuration file needs to be built based on an XML Schema and FOP should by default validate the configuration file (hard-coded in FOP) so the users get proper feedback if they try to feed FOP with an invalid format. But that means the XML Schema must be water-tight. On the other side, we will probably lose extensibility of the configuration file format. When someone adds his own renderer, for example, he can't just have his own config values because he can't change the XML Schema. So that may mean we probably can't use XML Schema to validate the file. But then, maybe we can define the individual renderer config parts as xsd:any or something like that and let each renderer validate its own configuration (either manually or using an XSD). ATM, I can't think of a good solution but apparently, we need to change something at some point. Any ideas, thoughts? Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.eu
Re: svn commit: r442282 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/extensions/ src/java/org/apache/fop/fo/extensions/
Fair enough. Can I get a couple of other opinions? I don't mind changing the names. I just want to make sure we choose a good one. Thanks! On 12.09.2006 17:32:57 Vincent Hennebert wrote: 2006/9/11, Jeremias Maerki: As mentioned last month, I just changed the property names a little bit. If anyone finds these inappropriate, please yell. This is not a big deal, but the names bother me a bit. Reading widow-content-limit makes me believe that that corresponds to the maximum authorized amount for widow content, which sounds a bit strange. What about min-widow-content? But I wouldn't mind if you keep the current names. Vincent Jeremias Maerki
Re: Configuration file problems
On 12.09.2006 21:13:35 Simon Pepping wrote: Jeremias, What is the problem you are trying to address: 1. Users use configuration files with errors which can be detected by the fop-configuration schema, but they do not validate it. 2. Users use configuration files with errors which cannot be detected by the fop-configuration schema. Both as well as a few others. :-) Ad 1: It is perfectly possible to let fop validate the user configuration file in a command line invocation. The problem is to ensure that the location of the schema does not become a source of errors in its turn. It is possible to write an Entity and URI Resolver which looks for 'fop-configuration.xsd' along the classpath, and for other schemas and DTDs delegates to a CatalogResolver if that is available, and otherwise returns the absolute URI of the system or schema location path. Re extensibility: A XML file is validated according to the DTD or schema that it declares (Relax-NG is an exception). The user can put a DTD or schema of his own choice in the user configuration file: !DOCTYPE fop PUBLIC '-//MYSELF//DTD My FOP Configuration XML V1.0//EN' 'http://myserver.mydomain.eu/fop-configuration.dtd' and the parser will validate against it. This means that a user can extend the configuration file at will, and that FOP cannot be assured that the config file is valid. Embedded users can always avoid validation. Yes, but you already assume a non-novice user. If our goal is to have less problems, fewer support requests because of configuration errors, we have to do it fool-proof. You can't rely on everyone putting the DTD or XSD on top of the configuration file. The first time the XML doesn't validate, people remove the schema reference. I do like Manuel's suggestion to supply a separate command line validation option. Me, too. You'll still have to tell the people to use the switch after they've run into a problem. That's why I'm in favor of forcing configuration validation for the command-line (but not for embedded use). Note that we have not advertised the configuration schema. It is not documented anywhere. I will add some documentation to the configuration web page. +1 although I don't think it solves any of the problems for the group of people I'm currently looking at. Ad 2: The schema cannot enforce a specific content model depending on the type attribute. But it does a nice job limiting the possibilities: One cannot mix and match parts of different renderer configuration options. For example, it is perfectly possible to configure a PostScript renderer with the elements applicable for a PDF renderer. But it is not possible to start with a filterList, and continue with auto-rotate-landscape. It is possible to force the correct content model for each renderer type by giving them different element names, e.g. renderer-application-pdf or application-pdf for short. Exactly my point. We have to change at least the configuration layout to improve the situation. The current layout cannot be validated satisfyingly against an XSD. Sure, I overreacted again. I know that and I'm sorry. But the longer I'm on the fop-users list the more I think we have to build fool-proof software. OTOH, as long as people don't use their brains when reading the simplest of warning messages there's no hope anyway. Regards, Simon On Sun, Sep 10, 2006 at 02:52:31PM +0200, Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. The attempt to overlay the configuration layout with an XSD is generally a good idea but with the current configuration layout, it's not a workable solution. If anyone has a good plan to improve the situation, I'm all ears. I think the configuration file needs to be built based on an XML Schema and FOP should by default validate the configuration file (hard-coded in FOP) so the users get proper feedback if they try to feed FOP with an invalid format. But that means the XML Schema must be water-tight. On the other side, we will probably lose extensibility of the configuration file format. When someone adds his own renderer, for example, he can't just have his own config values because he can't change the XML Schema. So that may mean we probably can't use XML Schema to validate the file. But then, maybe we can define the individual renderer config parts as xsd:any or something like that and let each renderer validate its own configuration (either manually or using an XSD). ATM, I can't think of a good solution but apparently, we need to change something at some point. Any ideas, thoughts? Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
DO NOT REPLY [Bug 40491] New: - Out of Memory when add the attribute keep-together.within-column=always
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40491. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40491 Summary: Out of Memory when add the attribute keep- together.within-column=always Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The FO file occur out of memory. After I remove the attribute keep-together.within-column=always,it is work OK. Please take a look. Thanks, Kevin The file content: fo:root font-family=UniversCond line-height=1.0 font-size=8pt font- weight=normal xmlns:aws=aws xmlns:math=http://exslt.org/math; xmlns:msxsl=urn:schemas-microsoft-com:xslt xmlns:svg=http://www.w3.org/2000/svg; xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set xmlns:xlink=http://www.w3.org/1999/xlink; fo:simple-page-master master-name=page page-height=11in page-width=8.5in margin-top=20pt margin-bottom=28pt margin-left=0.75in margin-right=0.4in fo:region-before extent=77.362pt/ fo:region-body margin-top=77.362pt margin- bottom=46pt/ fo:region-after extent=28pt display-align=after/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page xmlns:xlink=http://www.w3.org/1999/xlink; fo:static-content flow-name=xsl-region-before /fo:static-content fo:static-content flow-name=xsl-region-after /fo:static-content fo:flow flow-name=xsl-region-body fo:block span=all id=BasicsVPUSA04AC2/ fo:table table-layout=fixed inline-progression- dimension.optimum=100% fo:table-column column-width=257.1pt/ fo:table-column column-width=15pt/ fo:table-column column-width=257.1pt/ fo:table-body display-align=before fo:table-row keep-with-next=always fo:table-cell number-columns- spanned=3 fo:block span=all space-before=4pt space-after=0pt font-size=8pt fo:table table-layout=fixed inline-progression-dimension.optimum=100% fo:table-column/ fo:table-body fo:table-row fo:table-cell fo:block font-size=2.208pt background-color=rgb (217,217,217) fo:leader/ /fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:block font-weight=bold line-height=8.192pt background-color=rgb(217,217,217) text-indent=2ptFees and Expensesfo:inline font-weight=normal as of prospectus dated /fo:inline fo:inline font-weight=normal05-01- 2006/fo:inline /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block
DO NOT REPLY [Bug 40491] - Out of Memory when add the attribute keep-together.within-column=always
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40491. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40491 --- Additional Comments From [EMAIL PROTECTED] 2006-09-12 23:22 --- Created an attachment (id=18856) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18856action=view) The issue fo file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
