Re: WIKI update to FOP IDE Setup Guide
On 17.08.2005 17:08:12 Manuel Mall wrote: Just did my first FOP WIKI update. I added instructions for NetBeans to http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide. Hope that's OK. Please yell if I shouldn't do this or should do it differently. Rest assured that we WOULD yell if we didn't like something. Everything's in order and very much appreciated! Thanks! Jeremias Maerki
Eclipse with JDK 1.5 (was: Re: [Xmlgraphics-fop Wiki] Update of FOPIDESetupGuide by ManuelMall)
I don't do native JDK 1.5 development (i.e. no generics etc.) but regularly compile and test with 1.5 and so far absolutely no problems. On 17.08.2005 19:31:14 Peter B. West wrote: How's Eclipse with 1.5 nowadays? Jeremias Maerki
Re: Eclipse with JDK 1.5
Jeremias Maerki wrote: I don't do native JDK 1.5 development (i.e. no generics etc.) but regularly compile and test with 1.5 and so far absolutely no problems. On 17.08.2005 19:31:14 Peter B. West wrote: How's Eclipse with 1.5 nowadays? Thanks. When I tried it ( a while ago now) it was the 1.5 features that caused the trouble. I thought it might have settled down by now. Peter --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
Re: Plain old line-breaking
I can't talk for Luca, but I don't think we have explicit design docs for that part. I think there is some useful content in the mail archives (search for Knuth). Other than that, I realized that the algorithm described in Knuth's Digital Typography is now in our codebase quite literally (although by now with some extensions). I had no trouble tracing back code parts to the book. Understanding the algorithm itself as described by Knuth gets you 80% of the way to start the implementation as I see it. On 18.08.2005 15:05:15 Peter B. West wrote: Is there any design documentation about plain old line Knuth breaking, as implemented by Luca? I see lots of stuff in the Wiki about page breaking, but can't see the original. Jeremias Maerki
DO NOT REPLY [Bug 36238] - text-align=justify doesn't work on custom fonts
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=36238. 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=36238 [EMAIL PROTECTED] changed: What|Removed |Added URL||http://marc.theaimsgroup.com ||/?t=11242949732r=1w=2 -- 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: DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved
I have yet to look at this more closely, but I have the impression that it would not be the right approach to do URI resolution in the ParsedURL area, but it should actually occur beforehand. As the name suggests ParsedURL's job is to parse and provide access to a URL. A URI is a more general concept and URI resolution should probably happen before ParsedURL goes into action. ParsedURL is a very intriguing concept to at least partly replace java.net.URL. That's why I'd like ParsedURL to end up in XML Graphics Commons if possible (FOP would profit). But it is a lower-level concern/facility than URI resolution. So I'd instinctively do URI resolution in a different area, so that a URIResolver could be provided as a transcoding hint (i.e. non-global). I hope I can have a closer look later. On 16.08.2005 12:28:09 Thomas DeWeese wrote: Hi all, On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote: This is actually not about relative paths, but actual URI resolution. If you look at the JUnit test case I committed earlier [1] I use the URIResolver to resolve an URI funky:myimage123 to one of the bgimg bitmaps in our test directory (a file URL). That's how people can specify abstract URIs instead of concrete URLs to point to resources whose location is not known at deployment time. And it's where XML Commons Resolver jumps in to provide a widely used mapping from URIs to URLs. [1] http://svn.apache.org/viewcvs?rev=232788view=rev Manuel Mall wrote: Alright, this means we need to set the FOP resolver on the SVG processor. Not sure if Batik supports the javax.xml.transform.URIResolver interface. May be any Batik people lurking on this list can shed more light on this? All Batik URL resolution is handled by our ParsedURL implementation. The only 'problem' with the ParsedURL class is that it doesn't have a very direct connection to a UserAgent, so configuration is done on a per JVM (really classloader) basis. So it would be simple to add support for URIResolver in ParsedURL but it wouldn't be a parameter on the 'batik.transcode.Transcoder' class it would be global. I'm not sure if this is a problem or not (I didn't follow all of the discussion above). There is also the potential issue of dragging in a new dependency for an interface with a single method that only takes/returns primitive types. ;) Jeremias Maerki
Re: Plain old line-breaking
Jeremias Maerki wrote: I can't talk for Luca, but I don't think we have explicit design docs for that part. I think there is some useful content in the mail archives (search for Knuth). Other than that, I realized that the algorithm described in Knuth's Digital Typography is now in our codebase quite literally (although by now with some extensions). I had no trouble tracing back code parts to the book. Understanding the algorithm itself as described by Knuth gets you 80% of the way to start the implementation as I see it. Unfortunately, the book was sacrificed to the weight restrictions. I'll get it mailed over. Peter --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 14:08 --- I have finally found where the problem lies: 1) in the sample file there is a trailing space at the end of the centered text 2) the sequence of elements created for a space inside centered text is glue - penalty - glue - box - penalty - glue 3) the method LineLayoutManager.endSequence() removes penalty and glue elements at the end of the sequence, before adding the final elements; thus, the LineLM removes only the two last elements in the sub-sequence representing a space, leaving the other 4 elements and corrupting the resulting sequence So, the bug could be either in 1 (there should not be a trailing space) or 3 (elements removal should be more sophisticated), or maybe in both. As white space handling is not a code section I know very well, I'm going to fix the endSequence() method. :-) -- 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 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 15:53 --- (In reply to comment #6) I have finally found where the problem lies: 1) in the sample file there is a trailing space at the end of the centered text ...because the linefeed after Result is converted into a space character, AFAICT. This is because of the default values for linefeed-treatment and whitespace-treatment (both handled inside fo.flow.Block.handleWhiteSpace() during refinement). 2) the sequence of elements created for a space inside centered text is glue - penalty - glue - box - penalty - glue 3) the method LineLayoutManager.endSequence() removes penalty and glue elements at the end of the sequence, before adding the final elements; thus, the LineLM removes only the two last elements in the sub-sequence representing a space, leaving the other 4 elements and corrupting the resulting sequence So, the bug could be either in 1 (there should not be a trailing space) No, I don't think so. I think this is white-space-collapse specified to kick in during area tree generation. or 3 (elements removal should be more sophisticated), or maybe in both. Only 3 IMO. As white space handling is not a code section I know very well, I'm going to fix the endSequence() method. :-) Not the reason I'd have chosen, but I think it's the right place to fix it. :-) I know white space handling pretty well by now and the linefeed that is converted to a space in this case seems to be correct. It seems like white- space-collapse is the thing that is not working properly. I've also found something else earlier about leading spaces when white-space cannot collapse. I haven't fixed that problem, yet, but it's another story anyway. At any rate, we need good test cases to check for all the combinations. But I don't know if the layout engine facility is good enough to check for all the details that come into play here. -- 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 36238] - text-align=justify doesn't work on custom fonts
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=36238. 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=36238 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 17:01 --- I have tried several times to get a collection of fonts into the FOray repository, but have been unable to get it done. There seem to be a lot of free fonts out there, but the ones I have found still have licensing restrictions that would prevent distribution of them. Another problem is that there are quite a few axes WRT fonts, and you could end up needing a fairly large number of fonts to cover the various issues, especially if you want to create tests that will handle poorly-constructed fonts properly. One less-than-ideal alternative might be to identify and document some commonly- used typefaces for which almost everyone will have a license, or perhaps to document the URL for downloading free fonts, so that everyone can at least go get the same thing from that location. Another alternative is to appeal to the user base to see if someone would take on the project of creating a set of fonts that could be used for testing. Since beauty of output is not the main object, hand-drawn stuff would be fine. -- 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 15119] - fo:external-graphic and border properties
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=15119. 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=15119 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Summary|fo:external-graphic and |fo:external-graphic and |border properties |border properties -- 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: Percentages in XSL-FO
I have just documented the rules with respect to determining the base value for percentage calculations on the WIKI [1]. I also looked at the fop-dev messages related to the code in this area ([2] and [3]). If my analysis in [1] is correct we have broadly speaking 4 different cases to consider: 1) Percentages resolved against property values (mainly font-size) in the fo tree. That is the easy case and can be done during fo tree construction similar to some other relative properties. This would get rid of the need to carry the property lists into the LengthBase (see [3]). 2) Percentages resolved against dimensions (ipd, bpd, padding rectangle, etc.) in the area tree (current area, parent area, ancestor block, etc.). This is the hard case - discussion below. 3) Special case dealing with intrinsic sizes of e-g and i-f-o (2 properties). This could be handled locally. 4) Special case for resolution against region (1 property). Again this could be handled locally. [2] deals with the case 2) above and problems in the current system. The current system uses the fo tree to simulate upwards navigation through the areas. It is the LMs responsibility to add dimension information to the FOs which is then used for percentage resolution. The alternative proposed is for the LMs to construct a context object which is passed to the property getValue() function. This context object (working name PropertyResolutionContext) will provide the means for the property resolution code to get to the relevant dimensions, e.g. provide getters like getParentAreaIPB(), getContainingBlockBPD(), getIntrinsicHeight(), The context object internally could make use of the information stored in the current LayoutContext (may be by defining PropertyResolutionContext as an interface LayoutContext can implement it?) as well as in the area tree constructed so far. I'll stop here - does this makes sense so far? Worth pursuing further? Remember I am new to this and be grateful for any 'gotchas' and the like to be pointed out to me. Manuel On Fri, 19 Aug 2005 04:20 pm, Jeremias Maerki wrote: On 18.08.2005 17:32:54 Manuel Mall wrote: I am currently looking at the XSL-FO spec with respect to resolving percentages in property values because it was mentioned on this list that the current system in FOP needs improvements. For many properties the spec refers to the 'closest ancestor block area that is not a line area'. This again is the same as 'containing block'. However, I also came across a description saying 'closest area ancestor that was generated by a block-level formatting object'. Now are these the same things: 'closest ancestor block area that is not a line area' == 'closest area ancestor that was generated by a block-level formatting object'? It sounds to me like they are the same or do I miss some subtle difference? It's probably the same although I can't shake the feeling, either, that there could be a subtle difference. But I'm pretty sure that the intent is for it to have the same effect. I think it boils down to having good test cases which document all the different possibilities. Based on these we can in time find out if there are indeed some differences by looking at each and every case. BTW, my original mail to suggest a refactoring of the percentage handling mechanism (just for reference): http://marc.theaimsgroup.com/?l=fop-devm=110630658730554w=2 I don't claim that my proposal is the right way to pursue this but I still think it probably offers the best flexibility even if it probably complicates the layout managers a bit. Thanks for looking at this. It's on my list but not for just now. Jeremias Maerki [1] http://wiki.apache.org/xmlgraphics-fop/PropertyHandling/Percentages [2] http://marc.theaimsgroup.com/?l=fop-devm=110630658730554w=2 [3] http://marc.theaimsgroup.com/?l=fop-devm=110442946030972w=2
Re: Plain old line-breaking
Peter B. West wrote: Is there any design documentation about plain old line Knuth breaking, as implemented by Luca? I see lots of stuff in the Wiki about page breaking, but can't see the original. As Jeremias told, there isn't much official documentation about the basics of the new breaking algorithm. A wiki page, or maybe more than one, could be very useful, even to keep track of the points that could need some more work. I have thought of writing it some times ... but unfortunately I never found the time to do it! :-( Regards Luca
DO NOT REPLY [Bug 36248] - total number of pages with empty block :ClassCastException in KnuthInlineBox
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=36248. 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=36248 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 20:57 --- InlineLM does not check whether it receives a list of KnuthElements or of KnuthSequences, like LineLM does. It blindly assumes the latter, while PageNumberLM returns the former. Hence the wrong cast to a KnuthSequence. A cheap solution would be to let InlineLM do the same as LineLM. That is not fail safe but would cover very many cases. -- 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.
