Re: Before floats + footnotes
Luca Furini a écrit : I agree that, in a sense, the error is in the fo file, defining a fixed-height footnote separator that does not fit well the page; with an heigth of 12 pt, all would be ok. In alternative, it could be defined using a min-opt-max line height or space-*, allowing for some stretch and shrink (not sure this would be handled correctly at the moment, but this is not the point). I've had a quick look, that's not handled currently. At some place in the code the space-before set on the separator is converted into a MinOptMax(opt, opt, opt). Anyway, even if defining some elastic height for the separator would certainly help improve the situation, that's not something we can expect from users. But I don't agree with you when you say that makes a feasible node which is always preferred to too-short nodes. I'm not at all convinced that it is a feasible break. Even if the FO recommendation says that the footnote body could be placed in a page following the one with the anchor, I think it should be read in a restrictive interpretation, deferring a footnote only if there isn't any possible alternative. Actually I was describing the algorithm's behavior, and I agree with you that this is not at all desirable. In this case, it is possible to place the footnote in the same page that contains its citation, so I think that the algorithm should not be allowed to prefer a break that defers it. Note [:-)] that the footnote could appear after *many* pages, if there are lots of 12pt-high lines of normal text. Hmmm, that's not wrong ;-) In this respect, from a user perspective, footnotes and before floats are quite different: while it's completely acceptable for a figure or a table to be placed in a page following the text referring to it, I'm sure most users would be quite disappointed to find out that a footnote has been unnecessarily deferred. So, while I think the idea of the page fill ratio is very good for the placement of before floats, I think footnotes should have a different handling, a preferential treatment limiting deferments to the extremely unlikely case of an unbreakable group of lines with a lot of footnotes, a few of which does not fit in the page (or some other extreme situations). The actual problem IMO is to define the right demerits for underfull pages and deferred before-floats and footnotes in order to have a decent result (i.e., that a human would expect) in every case. I don't think it would be enough: the expected break (the one with both footnotes on page 1) is a short solution and is not recorded, it just updates lastTooShort. As long as there is not a restart (and having just 12pt-high lines it will never happen), it doesn't have a chance to be used. I think that, after all, this could be fixed just by checking some additional condition before calling handleNode() the first time (when footnotes and before floats are not not taken into account). Not sure it's that simple. Is a page containing only two lines of normal text with no deferred footnote more desirable than a full page with a deferred footnote? I think that might disturb the reader as well. That's why I got the idea of a minimum fill ratio. But obviously, as this is currently implemented that's not enough. I'll think more about it. Vincent
Re: Increase in activity?
Jeremias Maerki wrote: Do I have a slightly distorted perception or do we currently see an increase in activity, even patches, following the 0.93 release? Hi Jeremias, yes I think there has been a increase in both user and development activity in the few weeks since the New Year. Maybe as a result of the recent stable release. Chris
DO NOT REPLY [Bug 41448] - java.lang.ClassCastException: org.apache.fop.layoutmgr.inline.WrapperLayoutManager
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=41448. 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=41448 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2007-01-24 06:00 --- You've haven't attached the XSL-FO that is generated by docbook which we will need for us to make an accurate diagnosis of the problem. If I had to guess then I would say this is caused by an fo:wrapper element as an immediate child of fo:flow. This bug exists in the released 0.93 but has been fixed in SVN. -- 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: Before floats + footnotes
Vincent Hennebert wrote: I've had a quick look, that's not handled currently. At some place in the code the space-before set on the separator is converted into a MinOptMax(opt, opt, opt). If I remember correctly, the separator bpd is taken from the generated area (so there isn't any stretch or shrink) instead of the element sequence. I think I (?) did so after a few unsuccessful tries to get the dimension in a better way. Anyway, even if defining some elastic height for the separator would certainly help improve the situation, that's not something we can expect from users. I agree, the algorithm should be able to handle the most common situation without any special hint. I think that, after all, this could be fixed just by checking some additional condition before calling handleNode() the first time (when footnotes and before floats are not not taken into account). Not sure it's that simple. Is a page containing only two lines of normal text with no deferred footnote more desirable than a full page with a deferred footnote? I think that might disturb the reader as well. That's why I got the idea of a minimum fill ratio. But obviously, as this is currently implemented that's not enough. I'll think more about it. You are right, there should probably be an upper limit to the amount of footnotes, and probably a user-configurable limit would be the ideal solution, so that the users could set it in the document using an extension property. While the old code forbade pages with too few footnotes, the minimum fill ratio avoids pages with too few content lines: we should find a way to combine these techniques, without eliminating each possible solution! :-) Regards Luca
Re: Adding Named Destinations for all IDs
On Jan 24, 2007, at 01:19, Nicol Bolas wrote: Can't you just use the bookmarking feature of XSL-FO? I mean, isn't that what it's there for? Well, IIRC in PDF there's a clear distinction between bookmarks and named destinations. I'm not 100% sure, but I think that every bookmark points to a named destination, but not every destination has to be pointed to by a bookmark. XSL 1.1 indeed offers fo:bookmark, but there does not seem to be an object corresponding to a PDF destination... There is the id attribute, but nothing in the Rec compels a FO processor to treat specified ids as anchor points (unless they are referenced by another FOs ref-id property). Cheers, Andreas
Re: Adding Named Destinations for all IDs
On Jan 24, 2007, at 22:10, Nicol Bolas wrote: If that's true, what is the point of a named destination without a bookmark? An anchor point in the document that can be pointed to directly from outside, so that a browser can jump to it when the named destination is appended to the base URL... There does not have to be a bookmark *in* the document that points to that destination. Cheers, Andreas
Re: Adding Named Destinations for all IDs
On 24.01.2007 21:20:50 Andreas L Delmelle wrote: On Jan 24, 2007, at 00:15, Jay Bryant wrote: Hi Jay, I spent the afternoon reading the FOP source code and the PDF specification, and, if I understand things correctly, I need to add to the catalog. To do that, I thought I'd extend PDFObject to create an object called PDFDestination and then modify PDFRoot to get the destinations into the catalog. Does that make sense or did I miss something in my (admittedly brief) study of the existing code? Makes a lot of sense, as a basis... I seem to remember doubts being raised as to whether it should be made standard or handled by resurrecting the fox:destination extension. Adding named destinations for each and every id in the document may not always be desirable, so it may be better to leave this choice up to the end-user. Right, we were talking about an extension attribute to enable a named destination as replacement for fox:destination. Jeremias Maerki
Re: Adding Named Destinations for all IDs
On Jan 24, 2007, at 22:16, Andreas L Delmelle wrote: On Jan 24, 2007, at 22:10, Nicol Bolas wrote: If that's true, what is the point of a named destination without a bookmark? An anchor point in the document that can be pointed to directly from outside, so that a browser can jump to it when the named destination is appended to the base URL... There does not have to be a bookmark *in* the document that points to that destination. To elaborate a bit further, with named destinations one could roughly do the following: in somedoc.fo: fo:block id=chapter1a fox:destination=true ... fo:basic-link external-destination=./other-doc.pdf#chapter2b ... in other-doc.fo: fo:block id=chapter2b fox:destination=true ... fo:basic-link external-destination=./somedoc.pdf#chapter1a ... You don't need bookmarks for that. Andreas
Re: Increase in activity?
I agree. I suspect it's a function of what I call 'If you release it, they will come.' :-D On 1/24/07, Chris Bowditch [EMAIL PROTECTED] wrote: Jeremias Maerki wrote: Do I have a slightly distorted perception or do we currently see an increase in activity, even patches, following the 0.93 release? Hi Jeremias, yes I think there has been a increase in both user and development activity in the few weeks since the New Year. Maybe as a result of the recent stable release. Chris -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
