Re: svn commit: r320826 - /xmlgraphics/fop/branches/Temp_SpaceResolution/
Both are bugs. Thanks for finding them. I'm currently working on
testing for them and fixing them.
On 19.10.2005 22:04:47 Simon Pepping wrote:
Jeremias,
Two questions, about SpaceResolver.resolve():
1. performSpaceResolutionRules2to3(firstPart, firstPartLengths);
Should the resolution not be applied to the reverse of firstPart
and firstPartLengths, because you may be locating the last space
specifier in the original order?
2. if (isFirst || isLast) {
performSpaceResolutionRule1(secondPart, secondPartLengths);
}
If isLast, then the edge of the reference area is at the
end. Should then the resolution not be applied to the reverse
of secondPart and secondPartLengths?
Regards, Simon
On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote:
I finally uploaded my space resolution work so far. It's still not
finished. When you go through the details you always find more stuff to
look into and to fix. But most of it works now and is available for
review while I work on the remaining issues. I assume there is room for
optimization here and there. So don't hesitate to jump in and help. The
enabled test cases all pass.
--
Simon Pepping
home page: http://www.leverkruid.nl
Jeremias Maerki
Re: White space handling Wiki page
I was close to throwing temporarily the proverbial towel into the ring with respect to whitespace handling. However an offline IM chat with Jeremias and writing the response to Stephen's post encouraged me to take a different approach. Instead of trying to understand whitespace handling on the basis of a detailed analysis of the spec I looked at it from the perspective: What outcome did the spec writers most likely wanted to achieve? Of course the result is just a bunch of (educated?) guesses on my part. But based on my guesses I have posted a revised algorithm on the Wiki which I hope: a) Deals sensibly with unresolved/unclear issues b) Gives consistent results in the generated output c) Moves most of the work into refinement and only leaves whitespace handling around formatter generated breaks to layout d) Is understandable by others However, I do admit it is at this stage a home cooked approach and certainly requires close scrutiny by others before any implementation into the FOP code base is attempted. Thanks Manuel
Re: White space handling Wiki page
Manuel Mall wrote: Manuel, I was close to throwing temporarily the proverbial towel into the ring with respect to whitespace handling. However an offline IM chat with Jeremias and writing the response to Stephen's post encouraged me to take a different approach. Instead of trying to understand whitespace handling on the basis of a detailed analysis of the spec I looked at it from the perspective: What outcome did the spec writers most likely wanted to achieve? Of course the result is just a bunch of (educated?) guesses on my part. Indeed. This is the approach I agree with and recommend as far as the spec is concerned. As you've found out the spec is often ambiguous. I think the best approach to implement any XSL-FO feature is; 1) work out what you think the XSL-FO WG intended. When doing this, I think it is important not to dwell too long on every single sentence - just get a gut feel of what the WG intended. 2) work through some use cases. 3) and add a pinch of common sense. But based on my guesses I have posted a revised algorithm on the Wiki which I hope: a) Deals sensibly with unresolved/unclear issues b) Gives consistent results in the generated output c) Moves most of the work into refinement and only leaves whitespace handling around formatter generated breaks to layout d) Is understandable by others However, I do admit it is at this stage a home cooked approach and certainly requires close scrutiny by others before any implementation into the FOP code base is attempted. Of course this is just my 2 cents worth and may not be considered a good idea by others. Chris
Re: SVG PDFTranscoder broken...
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 10/19/2005 12:37:56 PM: I see the problem now and I think I found a fix: http://svn.apache.org/viewcvs?rev=326600view=rev The Graphics.create() methods were simply not implemented properly. Right, thanks for fixing it for me. It looks like even with some of the more complex clipping cases everything is right. Back to trying to figure out what's wrong with gradients... ;) On this point any objection if I have it fall back to rasterizing in some cases that I don't think can be represented in PDF (mostly the complex repeat modes)?
Re: Space resolution - ready for merge
On Wed, Oct 19, 2005 at 03:13:53PM +0200, Jeremias Maerki wrote: I'm comfortable now with the space resolution code. If it's ok for everybody, I'd like to merge the space resolution branch into Trunk. I've documented the open issues I know. All these issues have a (disabled) test case to demonstrate the problem. The only thing that I will probably do right now is clean up a few LM since I've only commented older code passages dealing with spaces. I agree that the code is ready to be merged into the trunk. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Volunteer wanted - disabled-testcases.txt in XML
Jeremias Trying to ru the testcases, but I can't put my hands on en.hyp or de.hyp. Can you point me in the direction of them? MarkOn 19/10/05, Jeremias Maerki [EMAIL PROTECTED] wrote: A single XML file as I showed it in my first post. That's more easilyprocessed later when we put this information on the website.On 19.10.2005 00:22:39 Mark Gaywood wrote: Hi Sorry for the delay, but I've got some clear evenings ahead. With the text file (disabled-testcases.txt) are you envisioning a single xml replacement or one xml for each testcase? Mark -Original Message- From: Jeremias Maerki [*mailto: [EMAIL PROTECTED]*[EMAIL PROTECTED]] Sent: 15 October 2005 07:52 To: fop-dev@xmlgraphics.apache.org Subject: Re: Volunteer wanted - disabled-testcases.txt in XMLOnly a couple of things to add to what Clay already handled. On 15.10.2005 02:02:39 Mark Gaywood wrote: Jeremias, I'm set and ready to, just to be clear and I do apologise for not being on the ball straight away with what must appear to be a trivial task to most of you ,but I hope to up to your speeds and skill very soon. 1. convert the text file into an xml document with previously suggest markup Yes. 2. modify decorateWithDisabledList to load the XML document Yes. 3. filter the output of decorateWithDisabledList based a lookup passed in? Would it be too much to ask for you give me an example of an input and output for this method? The mechanism in use here is the filefilter package from Jakarta Commons IO. You find the documentation here: * http://jakarta.apache.org/commons/io/api-release/index.html?org/apache/commons/io/filefilter/package-summary.html *http://jakarta.apache.org/commons/io/api-release/index.html?org/apache/commons/io/filefilter/package-summary.html This method doesn't filter the files directly but decorates (See Design Patterns, Gang of Four) an existing file filter so that the files listed in the file you're about to convert to XML won't get returned by the FileUtils.listFiles() methods (also a Commons IO thing). Basically, you're building a rule tree here. An example: Assume a simple filter: IOFileFilter myFilter = new PrefixFileFilter(my); Passed into FileUtils.listFiles() this filter will return all files that start with my, i.e. for example myStuff.txt. What you do in decorateWithDisabledList is something like that: myFilter = new AndFilter(myFilter, new SuffixFileFilter(.xml)); This will create a modified filter which restricts the existing file filter by adding the rule that all returned files must be XML files, so myStuff.txt wouldn't be returned anymore, but myCalendar.xml will still be returned. Basically, you don't modify the filefilter rule at all, just the way the NameFileFilter in decorateWithDisabledList is constructed. Run the whole thing through the debugger once and you'll understand how this works. 4. create some website with XSLT, Cocoon and Forrest (Nice) Yes, if you want to do it. Will I need a password for login for submitting to SVN or would you prefer another method of code submission? Just download the code using SVN and create patches as described in: * http://xmlgraphics.apache.org/fop/dev/#patches*http://xmlgraphics.apache.org/fop/dev/ and *http://xmlgraphics.apache.org/fop/dev/tools.html#patches* http://xmlgraphics.apache.org/fop/dev/tools.html and submit them using Bugzilla as Clay already told you.Jeremias Maerki ' fop-dev@xmlgraphics.apache.org'Jeremias Maerki
Re: Volunteer wanted - disabled-testcases.txt in XML
Look here: http://offo.sourceforge.net/hyphenation/ http://sourceforge.net/project/showfiles.php?group_id=116740 (Download the one for fop-HEAD) On 20.10.2005 23:10:43 Mark Gaywood wrote: Jeremias Trying to ru the testcases, but I can't put my hands on en.hyp or de.hyp. Can you point me in the direction of them? Mark On 19/10/05, Jeremias Maerki [EMAIL PROTECTED] wrote: A single XML file as I showed it in my first post. That's more easily processed later when we put this information on the website. On 19.10.2005 00:22:39 Mark Gaywood wrote: Hi Sorry for the delay, but I've got some clear evenings ahead. With the text file (disabled-testcases.txt) are you envisioning a single xml replacement or one xml for each testcase? Mark -Original Message- From: Jeremias Maerki [*mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]] Sent: 15 October 2005 07:52 To: fop-dev@xmlgraphics.apache.org Subject: Re: Volunteer wanted - disabled-testcases.txt in XML Only a couple of things to add to what Clay already handled. On 15.10.2005 02:02:39 Mark Gaywood wrote: Jeremias, I'm set and ready to, just to be clear and I do apologise for not being on the ball straight away with what must appear to be a trivial task to most of you ,but I hope to up to your speeds and skill very soon. 1. convert the text file into an xml document with previously suggest markup Yes. 2. modify decorateWithDisabledList to load the XML document Yes. 3. filter the output of decorateWithDisabledList based a lookup passed in? Would it be too much to ask for you give me an example of an input and output for this method? The mechanism in use here is the filefilter package from Jakarta Commons IO. You find the documentation here: * http://jakarta.apache.org/commons/io/api-release/index.html?org/apache/commons/io/filefilter/package-summary.html * http://jakarta.apache.org/commons/io/api-release/index.html?org/apache/commons/io/filefilter/package-summary.html This method doesn't filter the files directly but decorates (See Design Patterns, Gang of Four) an existing file filter so that the files listed in the file you're about to convert to XML won't get returned by the FileUtils.listFiles() methods (also a Commons IO thing). Basically, you're building a rule tree here. An example: Assume a simple filter: IOFileFilter myFilter = new PrefixFileFilter(my); Passed into FileUtils.listFiles() this filter will return all files that start with my, i.e. for example myStuff.txt. What you do in decorateWithDisabledList is something like that: myFilter = new AndFilter(myFilter, new SuffixFileFilter(.xml)); This will create a modified filter which restricts the existing file filter by adding the rule that all returned files must be XML files, so myStuff.txt wouldn't be returned anymore, but myCalendar.xml will still be returned. Basically, you don't modify the filefilter rule at all, just the way the NameFileFilter in decorateWithDisabledList is constructed. Run the whole thing through the debugger once and you'll understand how this works. 4. create some website with XSLT, Cocoon and Forrest (Nice) Yes, if you want to do it. Will I need a password for login for submitting to SVN or would you prefer another method of code submission? Just download the code using SVN and create patches as described in: * http://xmlgraphics.apache.org/fop/dev/#patches* http://xmlgraphics.apache.org/fop/dev/ and *http://xmlgraphics.apache.org/fop/dev/tools.html#patches* http://xmlgraphics.apache.org/fop/dev/tools.html and submit them using Bugzilla as Clay already told you. Jeremias Maerki 'fop-dev@xmlgraphics.apache.org' Jeremias Maerki Jeremias Maerki
alignment-baseline and aligment-adjust properties
See the response at http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0006.html. We have taken the opposite approach and added the property values to the property defintions. We could now: a) just remove them or b) leave the values in and issue a warning when used Given that FOP 0.20.5 doesn't support this at all and it is therefore unlikely we would be breaking anything for users moving from FOP 0.20.5 to FOP trunk if we go for option a) I would recommend to apply the KISS principle in this case and just remove them. Manuel
