Re: When to release 1.0?
Joerg, I'm glad you volunteer to do any changes. But there's also something else. We had a vote in March about merging back the API Finalization branch back into Trunk. You voted +1 back then knowing the the branch had the word Finalization in it. Furthermore, we've already communicated with 0.92beta that the API is now considered stable [1]. So, if the committership feels we should take another round of API improvements, I won't block (your suggestions are all reasonable) but I won't take the lead here. Either you or someone else has to take the lead and push for it (consensus gathering, changes, documentation, communication...). I'm leaving tomorrow for Ireland and will be away for another week after ApacheCon on green holidays (Swiss style), so I wouldn't have time anyway. But I'll try to keep an eye on the lists as often as possible. [1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html On 20.06.2006 23:24:15 J.Pietschmann wrote: Jeremias Maerki wrote: Ok, if we want that 1.0 won't be out before September. Too bad. As already mentioned, changing IPD page masters worked reasonably well in 0.20.5 and I think people will expect this to work in a 1.0 release too. OTOH, if the frequency of questions on the lists are taken into account, support for collapsing table borders, even if only partial, has a much higher priority. I don't see any of the other mentioned features as a show stopper for 1.0. That remark comes pretty late, but yeah, if anyone else think this should be fixed, we should do it SOON. Well, someone should have looked at this before (I made some style related notes during the API discussion). The guide lines are - consistency with the Java RTL identifier guide lines, in particular the rule that common acronyms in identifiers are all upper case - internal consistency - avoiding redundancy We can restrict this to the essential user visible API, i.e. the packages o.a.fop.apps and o.a.fop.cli. My suggestions - Rename o.a.fop.apps to o.a.fop.api. This is a major change breaking everything, and should have been done in the same step when the Driver was replaced by the Fop class. I wont insist on this change. - If the Fop in FopFactory is the acronym for FO processor, the class should be named FOPFactory instead. Same for Fop -- FOP (precedent is the java.net.URL class). - If it's the other way around FOPException should be renamed as FopException. - MimeConstants should be renamed as MIMEConstants. - FOURIResolver should probably be renamed as plain URIResolver (the FO prefix may be deemed redundant because of the package), or as FOPURIResolver. Two consecutive acronyms in an identifier are awkward in any case. - Same for FOUserAgent -- UserAgent or FOPUserAgent - The method applyHttpBasicAuthentication should be renamed applyHTTPBasicAuthentication. - Rename the CLI parameter -param to -xsltparam or something (too generic) We could keep and deprecate the unrenamed classes in order to ease the transition. If the API is really declared stable, the beta tag can be dropped from the release number even for a pre 1.0 release. Should we hold a formal vote on the API style issue? Either way, I'd even volunteer to do the changes (it's easy enough :-). J.Pietschmann Jeremias Maerki
Re: When to release 1.0?
On Jun 21, 2006, at 08:39, Jeremias Maerki wrote: snip / Hi guys, Sorry for being late. Just been reading this thread, and apart from the other comments already made, I agree with the plan to release, and I share most of the other committer's feelings wrt the version number. Whilst 1.0 may be a bit premature, it is becoming more and more of a necessity to draw more attention to FOP. As for myself, I have only one serious issue on my list that needs being looked at, in the area of multithread safety. There's still a very suspicious static left in FOText.java, which may cause trouble -- or at least, highly erratic/unpredictable behaviour-- when multiple documents are processed concurrently in the same JVM. As a positive note: unwanted side-effects should only arise when two or more of those documents are extensively using text-decoration and/or text- transform. I'll make it a priority to finish this ASAP, so this is out of the way. As far as concerns the other 'showstoppers': I assume there will still be at least one 1.0RC before actually releasing a definitive version. Maybe we can use this to our advantage, as in: announce a release candidate RC1 while explicitly mentioning that there are still open issues and questions to be answered. We could announce the first RC sooner rather than later, and release the actual 1.0 in november (or beginning of 2007) as long as we have RC2 to RC5 in between? Important thing will be that the signal is given that we are confident enough about this product to jump over that barrier, albeit with a few reservations... Just my 2 cents. Later, Andreas
Re: keep...=always and Knuth penalties
Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. Peter Thanks, Jeremias Maerki
Re: When to release 1.0?
Jeremias Maerki wrote: Joerg, I'm glad you volunteer to do any changes. But there's also something else. We had a vote in March about merging back the API Finalization branch back into Trunk. You voted +1 back then knowing the the branch had the word Finalization in it. Furthermore, we've already communicated with 0.92beta that the API is now considered stable [1]. So, if the committership feels we should take another round of API improvements, I won't block (your suggestions are all reasonable) but I won't take the lead here. Either you or someone else has to take the lead and push for it (consensus gathering, changes, documentation, communication...). As one who took the time to write up some messy reflection code to allow my simplistic use of FOP to work with both 0.20.5 and 0.92beta based on the term API finalization, I would like to see the API actually finalize. For that matter, it would have been nice to keep 0.20.5 compatibility APIs around for very simple usages like mine (I was just doing new Driver(), setOutputStream(), setRenderer(), and getContentHandler() -- that's it, nothing fancy). Having to create reflection code to span these 2 versions is a pain and having to keep changing the reflection code as someone keeps changing the API is rather annoying -- especially since missing an API change will result in a runtime error later on down the line. I'm not saying, no, absolutely don't change the API. I am saying if you really feel you must do it once more and never again -- and loudly proclaim the mistake and *exactly* what you changed between 0.92beta and the final API so I don't have to hunt around. [I can't just recompile, of course, as my code is all using reflection as I have to support 0.20.5 until something 0.9x or later is actually officially marked as stable -- and for a bit thereafter for other 0.20.5 usages to be altered to be 0.9x API compliant.] -- Jess Holle
Re: keep...=always and Knuth penalties
On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote: Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. I'll see if it's on the laptop at home. All I remember about it was that it was a reply from one of the editors. Where were you looking? Peter
Re: keep...=always and Knuth penalties
On 21.06.2006 16:19:30 Peter B. West wrote: On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote: Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. I'll see if it's on the laptop at home. All I remember about it was that it was a reply from one of the editors. Thanks a lot! Where were you looking? Using friend Google, my mail client and http://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=index-grp=Public__FULLindex-type=ttype-index=xsl-editors Jeremias Maerki
Re: keep...=always and Knuth penalties
On Wed, 2006-06-21 at 16:24 +0200, Jeremias Maerki wrote: On 21.06.2006 16:19:30 Peter B. West wrote: On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote: Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. I'll see if it's on the laptop at home. All I remember about it was that it was a reply from one of the editors. Thanks a lot! Where were you looking? Using friend Google, my mail client and http://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=index-grp=Public__FULLindex-type=ttype-index=xsl-editors Have you tried the Disposition of Comments? I don't know how accessible they are to Google. Peter
Re: keep...=always and Knuth penalties
On 21.06.2006 16:34:20 Peter B. West wrote: On Wed, 2006-06-21 at 16:24 +0200, Jeremias Maerki wrote: On 21.06.2006 16:19:30 Peter B. West wrote: On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote: Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. I'll see if it's on the laptop at home. All I remember about it was that it was a reply from one of the editors. Thanks a lot! Where were you looking? Using friend Google, my mail client and http://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=index-grp=Public__FULLindex-type=ttype-index=xsl-editors Have you tried the Disposition of Comments? I don't know how accessible they are to Google. They are accessible through the list archive at W3C. I've looked at those I found but I found no listing of all XSL-related ones. Jeremias Maerki
[GSoC] How the work should progress
Hi all, I'd like to have the opinion from the team about how I should proceed. I'm currently at a point where I think I know enough, both from theoretical and code points of vue, to start the implementation of floats. By mimicing the handling of footnotes, I think I can have a working implementation rather quickly and easily. However, it wouldn't be very satisfying IMO. Some refactoring wouldn't be useless, and while I'm at it, why not doing it completely? I've already spent much time figuring out how the code is working. From what I've seen, some areas of the code still look experimental. I think the implementation of floats may be an opportunity to bring it to a more polished level. A refactoring would have several benefits: - this may help sorting things out, and even prepare the implementation of a first-fit algorithm (although this might be a bit too much unrelated, I'm afraid) - this may help future contributors to easier understand this area of the code and get involved more quickly - this is always better to have a clean design. Moreover, I think this is possible to make the implementation even more object-oriented, which would help sharing code between the line and page levels. - a refactoring process is more efficient and secure if one has the opportunity to think full-time about it... That's why I would propose to refactor the breaking algorithm. However, to do things properly I would need to understand a bit more of the code than just the breaking stuff. This may take some time, especially if I want to make sure that I don't introduce new errors. The implementation of side-floats may suffer from that. That was not the original intent of the SoC project, but I think this would be a benefit for Fop. WDYT? Vincent
Re: When to release 1.0?
Jeremias Maerki wrote: We had a vote in March about merging back the API Finalization branch back into Trunk. You voted +1 back then knowing the the branch had the word Finalization in it. Some things just need time to sink in. I don't want style issues block further progress. I brought this topic up only because this seems to be the very last chance for changes. If everybody is ok with as is, then just go forward. J.Pietschmann
