Re: svn commit: r422509 - /xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
Hmm, XML Schema might not be a suitable enough means to map our configuration schema. I've just tried to make my main debug config file validate with your schema. I've had to extend it a bit but still ended up having a validation error I did not quite understand. It kept asking for the fonts or xml-handler elements although they are both optional. I've never done much XML Schema and never liked it much. I don't know much about RelaxNG either, but I repeatedly hear that it's more flexible. I know that you can define several variants of the same element by chosing the type using an attribute (renderer with mime attribute). I don't know if that can be done in XML Schema. Shrug. I can upload my changes but due to the fact that they don't work for me makes me hesitant to upload them. On 16.07.2006 21:40:22 Simon Pepping wrote: On Sun, Jul 16, 2006 at 07:31:52PM -, [EMAIL PROTECTED] wrote: Author: spepping Date: Sun Jul 16 12:31:52 2006 New Revision: 422509 URL: http://svn.apache.org/viewvc?rev=422509view=rev Log: A W3C schema for FOP user configuration files Added: xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd (with props) Once too often I lost time due to a slightly wrong configuration file. FOP tries to find the elements it knows about; it does not give feedback on elements that it does not know about. This schema should help users discover which of their elements FOP does not recognize. Probably the content of some elements can be constrained further. Please, do so if you see such an element. If this schema is a good idea, I will document it on the configuration page of the web site. Jeremias Maerki
[GSoC] BreakingAlgorithm: simplify handling of activeLines
Hi All, Good news: before-floats are working. There probably are bugs and place for improvement but I think it is time to submit a first patch, so that you may see what I've done. I'm currently cleaning up and documenting my code, and I think the handling of the activeLines array may be simplified: currently, for a line l, activeLines[2*l] points to the first active node for this line, and activeLines[2*l+1] points to the last node. But the last node is never directly accessed, only by starting at the first one and following the links. There must be a reason for this code but I don't see it. Perhaps this is related to some older code which since was removed? Or have I missed something? However, if it is ok I'll simplify that in my patch. Vincent
Re: Invitation to Cocoon's GetTogether
Jeremias Maerki wrote: Andreas, what about you? Could you make it to the Cocoon GetTogether? One or two days of Hackathon (discussions, hacking, fun). Anyone else? Jörg, Chris, Finn, Peter, Vincent maybe? Sorry I can't make it either! Chris
Re: Images in FOP 0.92beta
[EMAIL PROTECTED] wrote: Hi Jeremias, snip/ Well I figure that the thread will just be blocked in queue.remove most of the time unless it has something to do. I don't think there is much overhead for a thread in the types of systems we are targeting (i.e. not small constrained devices). Note that this is one thread that is used for all CleanerThread sub objects (so it's not like you are likely to spawn lots of threads). Don't forget that a lot of folk deploy FOP/Batik inside Web containers or Application Servers, where spawning new Threads is considered illegal. snip/ Chris
Re: [GSoC] BreakingAlgorithm: simplify handling of activeLines
Vincent Hennebert wrote: Hi All, Good news: before-floats are working. There probably are bugs and place for improvement but I think it is time to submit a first patch, so that you may see what I've done. I'm currently cleaning up and documenting my code, and I think the handling of the activeLines array may be simplified: currently, for a line l, activeLines[2*l] points to the first active node for this line, and activeLines[2*l+1] points to the last node. But the last node is never directly accessed, only by starting at the first one and following the links. Perhaps I misunderstand your question, but I think the last active node in a line is used when adding yet another active node for that line at the end of the linked list. In BreakingAlgorithm:addNode(): activeLines[headIdx + 1].next = node; On the other hand, a different data structure of nodes might very well open up different improvement. The current structure of using a linked list for each line, is just the best I could come up with at the time. regards, finn
Re: [GSoC] BreakingAlgorithm: simplify handling of activeLines
On Mon, Jul 17, 2006 at 02:08:54PM +0200, Finn Bock wrote: Vincent Hennebert wrote: I'm currently cleaning up and documenting my code, and I think the handling of the activeLines array may be simplified: currently, for a line l, activeLines[2*l] points to the first active node for this line, and activeLines[2*l+1] points to the last node. But the last node is never directly accessed, only by starting at the first one and following the links. Perhaps I misunderstand your question, but I think the last active node in a line is used when adding yet another active node for that line at the end of the linked list. In BreakingAlgorithm:addNode(): activeLines[headIdx + 1].next = node; On the other hand, a different data structure of nodes might very well open up different improvement. The current structure of using a linked list for each line, is just the best I could come up with at the time. In my own implementation I use Java Collections, a list of lists. Once the active nodes have been separated by line number, there is no reason to preserve any remaining order. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: svn commit: r422509 - /xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
The attached file fails to validate with the XSD as found in the repo. But then, it's probably just one more of these cases that software does not really want to just work. Probably just a bug in my editor. On 17.07.2006 21:22:13 Simon Pepping wrote: On Mon, Jul 17, 2006 at 10:32:30AM +0200, Jeremias Maerki wrote: Hmm, XML Schema might not be a suitable enough means to map our configuration schema. I've just tried to make my main debug config file validate with your schema. I've had to extend it a bit but still ended up having a validation error I did not quite understand. It kept asking for the fonts or xml-handler elements although they are both optional. I've never done much XML Schema and never liked it much. I don't know much about RelaxNG either, but I repeatedly hear that it's more flexible. I know that you can define several variants of the same element by chosing the type using an attribute (renderer with mime attribute). I don't know if that can be done in XML Schema. Shrug. I think XML Schema is the usual schema language for this sort of files. I would have been happy to use Relax-NG, but it is less popular, and the number of validators is smaller. In fact, Relax-NG allows one to express that filterList is only valid with the mime attribute value application/pdf, etc. In my version fonts is optional. xml-handler does not occur. What does your config file contain? Jeremias Maerki userconfig-tmp.xml Description: Binary data
DO NOT REPLY [Bug 40062] New: - [PATCH] TIFF Publishing
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=40062. 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=40062 Summary: [PATCH] TIFF Publishing Product: Fop Version: 0.92 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] A bilevel CCITT Group 4 TIFF file is not published correctly when its fill order equals 2. In file org/apache/fop/image/TIFFImage.java, the loadOriginalData() function does not take into account the TIFF_FILL_ORDER field (when equals 2, byte table should be flipped - as in xmlgraphics TIFFFaxDecoder class). -- 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.
DO NOT REPLY [Bug 40062] - [PATCH] TIFF Publishing
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=40062. 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=40062 --- Additional Comments From [EMAIL PROTECTED] 2006-07-17 21:24 --- Created an attachment (id=18614) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18614action=view) TIFFImage,java difference 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.
DO NOT REPLY [Bug 40062] - [PATCH] TIFF Publishing
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=40062. 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=40062 --- Additional Comments From [EMAIL PROTECTED] 2006-07-17 21:26 --- Created an attachment (id=18615) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18615action=view) TIFF test 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.
Re: [GSoC] Auto-table layout questions
Hello everyone, I've been doing a little test using the following xsl-fo. Everything works fine except when I suppress all the column-width=... in the first table then FOP doesn't give any warnings and the second table simply disappears. I'm not sure why this is happening. Patrick ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; !-- defines the layout master -- fo:layout-master-set fo:simple-page-master master-name=first page-height=29.7cm page-width=21cm margin-top=1cm margin-bottom=2cm margin-left=2.5cm margin-right=2.5cm fo:region-body margin-top=3cm/ fo:region-before extent=3cm/ fo:region-after extent=1.5cm/ /fo:simple-page-master /fo:layout-master-set !-- starts actual layout -- fo:page-sequence master-reference=first fo:flow flow-name=xsl-region-body !-- this defines a title level 1-- fo:block font-size=18pt font-family=sans-serif line-height=24pt space-after.optimum=15pt background-color=blue color=white text-align=center padding-top=3pt Auto table layout test /fo:block !-- this defines a title level 2-- fo:block font-size=16pt font-family=sans-serif space-after.optimum=15pt text-align=center A simple table -- fixed layout /fo:block !-- normal text -- fo:block text-align=startThis simple table uses table-layout=fixed which works fine with Apache FOP 0.92beta. /fo:block !-- table start -- fo:table table-layout=fixed width=100% border-collapse=separate fo:table-column column-width=30mm/ fo:table-column column-width=30mm/ fo:table-column column-width=100mm/ fo:table-body fo:table-row fo:table-cell fo:blockone/fo:block/fo:table-cell fo:table-cell fo:blocktwo/fo:block/fo:table-cell fo:table-cell fo:blockthree: a little more texte is nice./fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockun/fo:block/fo:table-cell fo:table-cell fo:blockdeux/fo:block/fo:table-cell fo:table-cell fo:blocktrois/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockuno/fo:block/fo:table-cell fo:table-cell fo:blockdos/fo:block/fo:table-cell fo:table-cell fo:blocktres/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockeins/fo:block/fo:table-cell fo:table-cell fo:blockzwei/fo:block/fo:table-cell fo:table-cell fo:blockdrei/fo:block/fo:table-cell /fo:table-row /fo:table-body /fo:table !-- table end -- !-- normal text -- fo:block text-align=startThis is normal text. /fo:block !-- NEW PAGE * -- !-- this defines a title level 2-- fo:block font-size=16pt font-family=sans-serif space-after.optimum=15pt text-align=center break-before=page A simple table -- auto-table layout /fo:block !-- normal text -- fo:block text-align=startThis the same simple table but using table-layout=auto which IS NOT supported by Apache FOP 0.92beta. /fo:block !-- table start -- fo:table table-layout=auto width=100% border-collapse=separate fo:table-column / fo:table-column / fo:table-column / fo:table-body fo:table-row fo:table-cell fo:blockone/fo:block/fo:table-cell fo:table-cell fo:blocktwo/fo:block/fo:table-cell fo:table-cell fo:blockthree: a little more texte is nice./fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockun/fo:block/fo:table-cell fo:table-cell fo:blockdeux/fo:block/fo:table-cell fo:table-cell fo:blocktrois/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockuno/fo:block/fo:table-cell fo:table-cell fo:blockdos/fo:block/fo:table-cell fo:table-cell fo:blocktres/fo:block/fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:blockeins/fo:block/fo:table-cell fo:table-cell fo:blockzwei/fo:block/fo:table-cell fo:table-cell fo:blockdrei/fo:block/fo:table-cell /fo:table-row /fo:table-body /fo:table !-- table end -- !-- normal text -- fo:block text-align=startThe desired optimal result here is to have the third column made larger so that the text can fit without a line-break. /fo:block /fo:flow /fo:page-sequence /fo:root Jeremias Maerki wrote: Uh, no. I just wanted to point out that auto is not a valid value for column-width. What you probably meant was the case when the
