Re: Preparing for the first release
On Tue, 15 Nov 2005 06:48 am, Jeremias Maerki wrote: I agree with you two. Therefore, I've resurrected status.xml, added it to our website again and prepared it so we can start using it after the release. BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release I suggest to add to this list: Compliance page: Remove reference to Trunk and replace by 'Latest Release'. That is the compliance page to compare the old fop 0.20.5 release against the latest released version of fop. Deltas between the latest release and the current trunk version are tracked using status.xml. On every new release compliance changes to be transferred from status.xml to compliance.ihtml. If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Fine with me. snip/ Jeremias Maerki Manuel
Re: fo:marker and white space
Debugging shows: The FOText instances under fo:marker (just before and after the fo:block) don't get processed for whitespace treatment. Block.handleWhitespace isn't accessible to it. That's why the whitespace isn't removed and causes additional lines. The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. So, this is a bug, to be fixed after the release I guess. On 15.11.2005 05:56:19 Manuel Mall wrote: I was looking at clipping warnings generated by examples/fo/markers/hide.fo when I noticed that white space around fo:marker seems significant with respect to the output generated when the marker is retrieved, e.g.: fo:marker fo:block some text /fo:block /fo:marker when retrieved produces: empty line some text empty line while: fo:markerfo:blocksome text/fo:block/fo:marker just generates: some text I am suspicious that this is wrong and both inputs should produce the same output. For a test case and its output see: http://people.apache.org/~manuel/fop/marker_test.xml http://people.apache.org/~manuel/fop/marker_test.pdf Manuel Jeremias Maerki
Re: Preparing for the first release
Jeremias Maerki wrote: I agree with you two. Therefore, I've resurrected status.xml, added it to our website again and prepared it so we can start using it after the release. BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. Sorry to be picky, but the word alpha gives the impression that the release is alpha quality. I'd say it was beta quality by now. Anyway, I thought in the past we had agreed on calling it 0.90pr1, with pr meaning preview, which in IMHO sounds better than alpha - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Sounds good. Chris
Re: Preparing for the first release
On 15.11.2005 10:28:19 Chris Bowditch wrote: Jeremias Maerki wrote: I agree with you two. Therefore, I've resurrected status.xml, added it to our website again and prepared it so we can start using it after the release. BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. Sorry to be picky, but the word alpha gives the impression that the release is alpha quality. I'd say it was beta quality by now. Anyway, I thought in the past we had agreed on calling it 0.90pr1, with pr meaning preview, which in IMHO sounds better than alpha On the release plan we had 0.90 alpha 1 [1]. It's the first release of a totally new codebase so without more (positive) feedback from users (so far we only have bug reports) I'm more inclined to an alpha release right now, soon followed by a beta release when we have more feedback. For example, we don't have any experience of FOP working in a multi-threaded environment. I haven't had time to do testing in this area lately. Furthermore, memory is still quickly eaten up in the current state. It would make me very uneasy to use something like this in a production environment right now. I agree, from the feature POV, it's at least beta quality but that only covers the layout engine due to its many tests. But if the majority believes a beta is better, that's fine with me. [1] http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Sounds good. Chris Jeremias Maerki
Re: Preparing for the first release
Jeremias Maerki schrieb: I agree with you two. Therefore, I've resurrected status.xml, added it to our website again and prepared it so we can start using it after the release. BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. I don't think we need to vote on alpha/preview release (preview release as in will be available on cvs.apache.org/builds/fop and not on the official www.apache.org/dist) but should do it nevertheless. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Ok. Christian
Re: Preparing for the first release
Jeremias Maerki wrote: On 15.11.2005 10:28:19 Chris Bowditch wrote: Sorry to be picky, but the word alpha gives the impression that the release is alpha quality. I'd say it was beta quality by now. Anyway, I thought in the past we had agreed on calling it 0.90pr1, with pr meaning preview, which in IMHO sounds better than alpha On the release plan we had 0.90 alpha 1 [1]. True, I didn't notice it until now. It's the first release of a totally new codebase so without more (positive) feedback from users (so far we only have bug reports) I'm more inclined to an alpha release right now, soon followed by a beta release when we have more feedback. I don't feel that strongly about this, but I do think the word alpha will put a lot of people off using it. By naming it beta or preview, I think we are putting the message out that its ready for testing by the public. For example, we don't have any experience of FOP working in a multi-threaded environment. I haven't had time to do testing in this area lately. Furthermore, memory is still quickly eaten up in the current state. It would make me very uneasy to use something like this in a production environment right now. I agree, from the feature POV, it's at least beta quality but that only covers the layout engine due to its many tests. But if the majority believes a beta is better, that's fine with me. Most sensible folks wouldn't use a beta or preview release in production either. But there are always exceptions to the rule. Chris
DO NOT REPLY [Bug 37505] New: - SEVERE FOP Exceptions should be thrown!
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=37505. 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=37505 Summary: SEVERE FOP Exceptions should be thrown! Product: Fop Version: 0.20.5 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: critical Priority: P2 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I trace a bug because I saw the following exception in my log file. After inspecting my code, I noticed that this is just a log entry probably written by FOP/Batik ... the exception itself wasn't thrown further to my calling application. At least for the new FOP 1.0 version, such exceptions shouldn't be swalled by FOP - a SEVERE problem should always result in an Exception for the calling application. 2005-11-15 10:14:35.277 SEVERE Thread-227: svg graphic could not be built: file:/c:/temp/TJ9VV4pz1+FP0cz0bG6gDtdoar7QLGq0bTMTGOQ5bd4=/Perf.svg:28 The attribute 'transform' of the element path is invalid org.apache.batik.bridge.BridgeException: file:/c:/temp/TJ9VV4pz1+FP0cz0bG6gDtdoar7QLGq0bTMTGOQ5bd4=/Perf.svg:28 The attribute 'transform' of the element path is invalid at org.apache.batik.bridge.SVGUtilities.convertTransform(SVGUtilities.java:852) at org.apache.batik.bridge.AbstractGraphicsNodeBridge.createGraphicsNode (AbstractGraphicsNodeBridge.java:92) at org.apache.batik.bridge.SVGShapeElementBridge.createGraphicsNode (SVGShapeElementBridge.java:50) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:182) at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:148) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:188) at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:148) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:188) at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:148) at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:120) at org.apache.batik.bridge.SVGImageElementBridge.createSVGImageNode (SVGImageElementBridge.java:328) at org.apache.batik.bridge.SVGImageElementBridge.createGraphicsNode (SVGImageElementBridge.java:118) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:182) at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:148) at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:76) at org.apache.fop.render.pdf.PDFRenderer.renderSVGDocument(PDFRenderer.java:590) at org.apache.fop.render.pdf.PDFRenderer.renderSVGArea(PDFRenderer.java:549) at org.apache.fop.svg.SVGArea.render (SVGArea.java:98) at org.apache.fop.render.pdf.PDFRenderer.renderForeignObjectArea (PDFRenderer.java:533) at org.apache.fop.layout.inline.ForeignObjectArea.render(ForeignObjectArea.java:89) at org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:516) at org.apache.fop.layout.LineArea.render (LineArea.java:519) at org.apache.fop.render.AbstractRenderer.renderBlockArea (AbstractRenderer.java:485) at org.apache.fop.layout.BlockArea.render(BlockArea.java:117) at org.apache.fop.render.AbstractRenderer.renderBlockArea (AbstractRenderer.java:485) at org.apache.fop.layout.BlockArea.render(BlockArea.java:117) at org.apache.fop.render.AbstractRenderer.renderAreaContainer (AbstractRenderer.java:451) at org.apache.fop.layout.AreaContainer.render(AreaContainer.java:88) at org.apache.fop.render.AbstractRenderer.renderAreaContainer (AbstractRenderer.java:451) at
Re: Preparing for the first release
Jeremias Maerki schrieb: On 15.11.2005 10:50:07 Christian Geisert wrote: [..] I don't think we need to vote on alpha/preview release (preview release as in will be available on cvs.apache.org/builds/fop and not on the official www.apache.org/dist) but should do it nevertheless. But that won't make infrastructure very happy because that will create a lot of traffic on Apache infrastructure if the release isn't mirrored. Furthermore, we want to give out a signal that we're back in the business and that means an announcement through various channels. And that in turn will create traffic. I would strongly suggest we send it out through the distribution system, i.e. a vote is necessary. But an official release means it will be available forever on http://archive.apache.org/dist/xml/fop/ And http://www.apache.org/dev/mirrors.html says: Essentially, any release that you do not consider ready for prime time should go here. [people.apache.org:/www/cvs.apache.org/] I agree with you on the traffic issue. -- Christian
Re: Preparing for the first release
On 15.11.2005 11:42:31 Christian Geisert wrote: Jeremias Maerki schrieb: On 15.11.2005 10:50:07 Christian Geisert wrote: [..] I don't think we need to vote on alpha/preview release (preview release as in will be available on cvs.apache.org/builds/fop and not on the official www.apache.org/dist) but should do it nevertheless. But that won't make infrastructure very happy because that will create a lot of traffic on Apache infrastructure if the release isn't mirrored. Furthermore, we want to give out a signal that we're back in the business and that means an announcement through various channels. And that in turn will create traffic. I would strongly suggest we send it out through the distribution system, i.e. a vote is necessary. But an official release means it will be available forever on http://archive.apache.org/dist/xml/fop/ Is that so bad? And http://www.apache.org/dev/mirrors.html says: Essentially, any release that you do not consider ready for prime time should go here. [people.apache.org:/www/cvs.apache.org/] Sure, but we want people to try the software and that's kind of prime time. The part you're quoting also says: pre-releases aimed at the developer community, but not at end users. I'd like to aim at end users. I want their feedback. Some people will only start looking at the new code when we provide them with a precompiled binary. I agree with you on the traffic issue. -- Christian Jeremias Maerki
Missing file mk1logo.tif
The example fo examples/fo/advanced/giro.fo wants a graphics called mk1logo.tif. That file doesn't appear to be in svn. Any one come across that file or has a local copy or knows anything about this? Manuel
Re: Volunteer wanted - disabled-testcases.txt in XML
Hi Manuel, I'm still intending to do this, but I misjudged the time I had available. I'm not sure when I'll be able to spend the right amount of time and effort on this solution. Let me know if this is OK MarkOn 15/11/05, Manuel Mall [EMAIL PROTECTED] wrote: On Wed, 19 Oct 2005 06:22 am, 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?Hi Mark,curious if you still intend to do this?If not please let us know.Thank you very muchManuel Mark
Re: Preparing for the first release
Hi Jeremias, Not to rain on your parade, but doesn't there need to be a vote on fop-dev by committers on the release before bringing it to the PMC? Also doesn't a formal vote need to run at least one full week? I understand your desire to get the release out but... Jeremias Maerki [EMAIL PROTECTED] wrote on 11/14/2005 05:48:36 PM: BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable?
Re: Missing file mk1logo.tif
mk1logo.tif seems to never have made it into the repository. Here's the revision when this made it into the repository: http://svn.apache.org/viewcvs?rev=194119view=rev The whole thing seems to come from here: http://www.elovirta.com/2001/06/28/giro/ I can't find any post in the archives that suggests that Jarno Elovirta formally donated his example to the project. I assume he sent it to Arved Sandstrom directly back then. Given that the file would need some touch-up anyway I'd say we simply remove the file. If anyone wants to contact Jarno to clear that up, please do. On 15.11.2005 12:16:05 Manuel Mall wrote: The example fo examples/fo/advanced/giro.fo wants a graphics called mk1logo.tif. That file doesn't appear to be in svn. Any one come across that file or has a local copy or knows anything about this? Manuel Jeremias Maerki
Re: Preparing for the first release
Oh, I got sunshine outside. Not even fog today. :-) No, there's no need for a committer vote prior to the PMC vote. In terms of the Apache bylaws the PMC is the only body that can do project decisions [1]. BTW, this is a topic that's currently discussed on legal-discuss [2]. Where did you read this that a vote has to run a full week? AFAIK, the normal period is 72 hours [3]. I think it would be worthwhile if everybody here would reread the pages about how the ASF works. There have been quite a few improvements on these pages lately. The board and the members also made up their minds some more aboute certain topics. Even I should probably reread them again, although as a member I get a lot of that through the members list already. Reading those pages shows, for example, why the XML project had to split up. While we're at it: There are even voices that projects shouldn't micromanage committer sets anymore. For us, that would mean: All Batik committers become FOP committers and vice-versa. But that's for later. So far, it was just a stray comment on one of the lists. [1] http://www.apache.org/foundation/how-it-works.html#pmc-members [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ [3] http://www.apache.org/foundation/voting.html On 15.11.2005 13:59:45 thomas.deweese wrote: Hi Jeremias, Not to rain on your parade, but doesn't there need to be a vote on fop-dev by committers on the release before bringing it to the PMC? Also doesn't a formal vote need to run at least one full week? I understand your desire to get the release out but... Jeremias Maerki [EMAIL PROTECTED] wrote on 11/14/2005 05:48:36 PM: BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Jeremias Maerki
Re: Missing file mk1logo.tif
On Tue, 15 Nov 2005 09:15 pm, Jeremias Maerki wrote: mk1logo.tif seems to never have made it into the repository. Here's the revision when this made it into the repository: http://svn.apache.org/viewcvs?rev=194119view=rev The whole thing seems to come from here: http://www.elovirta.com/2001/06/28/giro/ I can't find any post in the archives that suggests that Jarno Elovirta formally donated his example to the project. I assume he sent it to Arved Sandstrom directly back then. Given that the file would need some touch-up anyway I'd say we simply remove the file. If anyone wants to contact Jarno to clear that up, please do. Hmm, this makes me hesitate especially after reading thread http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200511.mbox/browser which Jeremias pointed to in another post today. None of the examples/fo files have an Apache licence header. As indicated above some of their origins may be clouded and possibly predate the times when legal and licensing issues became a topic of serious concern for the ASF. Can we (or more specifically the PMC members) be sure that there are no legal issues with any of these files? If there is doubt should they be in the repository or even in the planned release? On 15.11.2005 12:16:05 Manuel Mall wrote: The example fo examples/fo/advanced/giro.fo wants a graphics called mk1logo.tif. That file doesn't appear to be in svn. Any one come across that file or has a local copy or knows anything about this? Manuel Jeremias Maerki Manuel
Re: Preparing for the first release
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 11/15/2005 08:28:11 AM: In terms of the Apache bylaws the PMC is the only body that can do project decisions [1]. It appears that they are the 'binding body' from the ASF point of view, but as a PMC member I would really like to see an invitation for the collection of other points of view (i.e. a vote on dev/user for a release). In this case I'm sure it will be greeted with enthusiasm, but I'm really hesitant to set precedent based on the 'best case' situation. BTW, this is a topic that's currently discussed on legal-discuss [2]. From a quick read I take away that the ASF requires 3 +1 from PMC members (oddly unvetoable), but that individual PMC's can have additional requirements, such as a positive vote from committers. As chair it appears that this is your call, so I'll just provide my 2 cents. Where did you read this that a vote has to run a full week? AFAIK, the normal period is 72 hours [3]. I think reading 'at least 72 hours' as 'normal period' is a little misleading. It is far to common for people to disappear for a week's vacation meaning that with just 72hrs an issue can come up be voted before someone sipping margarita's in the Bahamas even knows what has happened. I know that Batik always used 1 week for important votes for exactly this reason. It can of course be terminated earlier if all binding voters reply before the time is up. I think it would be worthwhile if everybody here would reread the pages about how the ASF works. There have been quite a few improvements on these pages lately. The board and the members also made up their minds some more aboute certain topics. I think a clear distinction should be made between the minimum required by the ASF and what we think is reasonable. Especially because in my mind the constituent projects under the XML-Graphics PMC are probably more independent than many. To be honest it makes me quite uncomfortable that at least in theory Batik could be 'forced' to have a release by FOP (even in spite of strong objections from the Batik community). Now I don't consider this a serious concern right now but the fact that the passability exists is IMHO bad. Even I should probably reread them again, although as a member I get a lot of that through the members list already. Reading those pages shows, for example, why the XML project had to split up. While we're at it: There are even voices that projects shouldn't micromanage committer sets anymore. For us, that would mean: All Batik committers become FOP committers and vice-versa. But that's for later. So far, it was just a stray comment on one of the lists. Well, once again I think that having shared committership among the xml-graphics-commons packages is a good thing (it's a set of code that is needed/used fairly heavily by both projects), however I think it would be a poor choice to have a common set of committers for the core of FOP and Batik, one would essentially have to 'trust' the other projects committers to have good judgement, and what to do if they violate that trust? They may make good/useful contributions to the other project, so revoking committership may overly harsh (at least for one project). [1] http://www.apache.org/foundation/how-it-works.html#pmc-members [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ [3] http://www.apache.org/foundation/voting.html On 15.11.2005 13:59:45 thomas.deweese wrote: Hi Jeremias, Not to rain on your parade, but doesn't there need to be a vote on fop-dev by committers on the release before bringing it to the PMC? Also doesn't a formal vote need to run at least one full week? I understand your desire to get the release out but... Jeremias Maerki [EMAIL PROTECTED] wrote on 11/14/2005 05:48:36 PM: BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Jeremias Maerki
Re: Preparing for the first release
Hi Thomas Don't take what I wrote too much by the letter. Always add a little common sense. See below. On 15.11.2005 15:49:39 thomas.deweese wrote: Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 11/15/2005 08:28:11 AM: In terms of the Apache bylaws the PMC is the only body that can do project decisions [1]. It appears that they are the 'binding body' from the ASF point of view, but as a PMC member I would really like to see an invitation for the collection of other points of view (i.e. a vote on dev/user for a release). In this case I'm sure it will be greeted with enthusiasm, but I'm really hesitant to set precedent based on the 'best case' situation. I've always intended to CC fop-dev for the release vote, but the vote will happen on [EMAIL PROTECTED] Everyone from the project is invited to vote and to express their opinion. If one of the non-PMC committers has a justified objection, nobody is ever going to ignore that. At least, I will see to that. In the end, though, and from a legal POV, it's the PMC's call. That's also why I sent out another note that all committers who care about the project are invited to join the PMC. It's what the board encourages nowadays. BTW, this is a topic that's currently discussed on legal-discuss [2]. From a quick read I take away that the ASF requires 3 +1 from PMC members (oddly unvetoable), but that individual PMC's can have additional requirements, such as a positive vote from committers. As chair it appears that this is your call, so I'll just provide my 2 cents. It's not my call, it's the PMC's. It's only my call when I see something go extremely wrong like it happened in the Avalon project. If we as a PMC want to establish such an additional requirement, we can of course do that. Every PMC member is free to propose something like that. We'll then discuss it on the [EMAIL PROTECTED] list and if necessary vote on it. But as I said, adding some common sense, an objection from a committer won't be ignored, so I don't think such an additional rule is strictly necessary. Where did you read this that a vote has to run a full week? AFAIK, the normal period is 72 hours [3]. I think reading 'at least 72 hours' as 'normal period' is a little misleading. It is far to common for people to disappear for a week's vacation meaning that with just 72hrs an issue can come up be voted before someone sipping margarita's in the Bahamas even knows what has happened. I know that Batik always used 1 week for important votes for exactly this reason. It can of course be terminated earlier if all binding voters reply before the time is up. Fair enough. It's certainly a bad sign if somebody would want to rush through a vote when someone who will certainly object to the matter at hand was away. On the other side, you have to keep the project alive and always having to wait on the last person holds things up unnecessarily. That's why it's good if committers drop a short note to the list when they are away for a longer period. I think it would be worthwhile if everybody here would reread the pages about how the ASF works. There have been quite a few improvements on these pages lately. The board and the members also made up their minds some more aboute certain topics. I think a clear distinction should be made between the minimum required by the ASF and what we think is reasonable. Of course. My current focus is to go towards the rules the board wants to see followed, foremost of all: better oversight. Especially because in my mind the constituent projects under the XML-Graphics PMC are probably more independent than many. Please explain. I'm a little worried about that comment. To be honest it makes me quite uncomfortable that at least in theory Batik could be 'forced' to have a release by FOP (even in spite of strong objections from the Batik community). Now I don't consider this a serious concern right now but the fact that the passability exists is IMHO bad. Seriously, Thomas, such a thing will never happen. You know that the PMC members theoretically have write access to the Batik codebase but no non-Batik PMC member is ever going to touch the Batik codebase without invitation. It's a matter of respect. If this would be a real problem we would need to split up XML Graphics into two projects. Even I should probably reread them again, although as a member I get a lot of that through the members list already. Reading those pages shows, for example, why the XML project had to split up. While we're at it: There are even voices that projects shouldn't micromanage committer sets anymore. For us, that would mean: All Batik committers become FOP committers and vice-versa. But that's for later. So far, it was just a stray comment on one of the lists. Well, once again I think that having shared committership among the xml-graphics-commons packages is a good thing (it's
Re: Hyphenation
Manuel Mall wrote: Hmm, just changed the value to 3000 (I think that's the value suggested in the article) and there is no change in hyphenation behaviour with the above mentioned example. That makes me a bit suspicious... I traced the beheviour of the breaking algorithm applied to the first paragraph of the example (the one with 4 consevutive lines ending with a hyphen) and it seems to me that the algorithm works well: the chosen set of breaks has about 15000 demerits, while the existing three alternatives either have some more demerits and the same quantity of consecutive flagged lines or about 3 demerits. It seems that out example, and in particular its first paragraph, perfectly follow Murphy's laws! Tomorrow I should have some time to implement hyphenation-ladder-count and fix the penalty values for justified / unjustified text. Regards Luca
Re: fo:marker and white space
On Nov 15, 2005, at 10:03, Jeremias Maerki wrote: snip / The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Extracting handleWhitespace() into a separate class would, in any case, be A Good Thing. My 2 cents. Cheers, Andreas
Re: Missing file mk1logo.tif
No, we cannot be sure if there are any legal issues unless we perform a complete legal audit of the full FOP codebase. We'd have to go through EVERYTHING. I think that's not in anybody's interest, nor would not doing this be neglecting our duties. IMO it was a good move to remove the hyphenation patterns because there we knew (more or less) where the original files came from and we had license headers indicating an ugly mix of licenses. The example files are most probably files that were sent by users, even giro.fo. Jarno Elovirta was on this mailing for some time, after all. If we found code or things like the hyphenation patterns that might be a problem from a legal POV, we'd need to go after it. There's certainly not much harm if we by chance have some example FO file in our repo that somebody plucked from the net somewhere without asking and it was before our time here in the project. As I said, I'd remove the file. I may add a similar demo file in a few weeks showing a Swiss giro form that I want to do anyway, maybe even as a XSLT snippet to be used by anyone who wants. On 15.11.2005 15:15:22 Manuel Mall wrote: On Tue, 15 Nov 2005 09:15 pm, Jeremias Maerki wrote: mk1logo.tif seems to never have made it into the repository. Here's the revision when this made it into the repository: http://svn.apache.org/viewcvs?rev=194119view=rev The whole thing seems to come from here: http://www.elovirta.com/2001/06/28/giro/ I can't find any post in the archives that suggests that Jarno Elovirta formally donated his example to the project. I assume he sent it to Arved Sandstrom directly back then. Given that the file would need some touch-up anyway I'd say we simply remove the file. If anyone wants to contact Jarno to clear that up, please do. Hmm, this makes me hesitate especially after reading thread http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200511.mbox/browser which Jeremias pointed to in another post today. None of the examples/fo files have an Apache licence header. As indicated above some of their origins may be clouded and possibly predate the times when legal and licensing issues became a topic of serious concern for the ASF. Can we (or more specifically the PMC members) be sure that there are no legal issues with any of these files? If there is doubt should they be in the repository or even in the planned release? On 15.11.2005 12:16:05 Manuel Mall wrote: The example fo examples/fo/advanced/giro.fo wants a graphics called mk1logo.tif. That file doesn't appear to be in svn. Any one come across that file or has a local copy or knows anything about this? Manuel Jeremias Maerki Manuel Jeremias Maerki
Re: fo:marker and white space
Sounds like a good plan to me. Would you go after that? On 15.11.2005 18:06:13 Andreas L Delmelle wrote: On Nov 15, 2005, at 10:03, Jeremias Maerki wrote: snip / The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Extracting handleWhitespace() into a separate class would, in any case, be A Good Thing. My 2 cents. Cheers, Andreas Jeremias Maerki
[VOTE] Release FOP Trunk as FOP 0.90alpha1
This is it. Just to make it clear again: This is a a release vote and therefore a PMC vote, but every FOP committer is invited to place his vote or raise any objections. Noone gets ignored. Although fop-dev is in the CC, please place your votes on [EMAIL PROTECTED] Even though I haven't fully finished all of the documentation, yet, I'd like to start the vote. I'll have everthing finished by tomorrow evening (CET). I don't intend to do any more code changes, only the last documentation updates. http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR shows the release plan and the status of the proceedings. I know of no legal problems needing attention. The external dependencies are well documented and every JAR in the lib directory is accompanied by its license. Hyphenation files have been removed. The unknown origin of some long-existing example FO files is not a problem IMO. 0.90alpha1 will carry a big warning sign in the README file that the software is a preview release and should not be used in production unless thoroughly tested for the target environment. It is intended to let everybody know that FOP is back in business and to produce feedback on our new piece of software from users that don't (or can't) download the code from SVN. I'd like to propose to release FOP SVN Trunk as version 0.90alpha1. +1 from me, obviously. Jeremias Maerki
block children of inlines fixed?
On the Wiki, ReleasePlanning: fo:inline - Does not support block-level objects as children (isn't that fixed?) Mostly, but perhaps not completely. I seem to recall that Finn reported an Exception related to a LM not recognizing the double list structure of Knuth elements returned by some inline level LMs. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Exceptions
Today, 15 November 2005, revision 344223 only gives an exception on the first test file. Simon On Thu, Sep 01, 2005 at 02:45:30PM +0200, Finn Bock wrote: Hi Running the NIST test suite I get 2 table related exceptions and 1 KnuthElement related exception: java.lang.NullPointerException org.apache.fop.layoutmgr.table.GridUnit.resolveBorder(GridUnit.java:246) org.apache.fop.layoutmgr.table.GridUnit.resolveBorder(GridUnit.java:230) org.apache.fop.layoutmgr.table.TableRowIterator.resolveStartEndBorders(TableRowIterator.java:480) org.apache.fop.layoutmgr.table.TableRowIterator.buildGridRow(TableRowIterator.java:419) org.apache.fop.layoutmgr.table.TableRowIterator.prefetchNext(TableRowIterator.java:294) ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=test-page-master margin-right=1.0in margin-bottom=1.0in margin-top=0.2in margin-left=1.0in page-width=8.5in page-height=11in fo:region-body margin-bottom=1.0in margin-right=1.0in margin-top=0.2in margin-left=1.0in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=test-page-master fo:flow flow-name=xsl-region-body fo:block space-after.optimum=0.4in space-after.maximum=0.4in This test evaluates the border-before-color property on a table-body FO. The border-before-color property (see red border) for the next table-body FO was set to red. /fo:block fo:table border-collapse=collapse-with-precedence fo:table-body border-before-style=solid border-before-color=red fo:table-row fo:table-cell fo:block The border above should be red. /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root -- Simon Pepping home page: http://www.leverkruid.nl
Re: block children of inlines fixed?
inline_block_nested_3.xml is disabled and produces a NPE. I assume it's that. So it is one of our known problems. :-) That's exactly where I see the XML-ification of the disabled-testcases.txt come into play. We will be able to more clearly document what we can't do right now and what our known issues are. On 15.11.2005 20:31:17 Simon Pepping wrote: On the Wiki, ReleasePlanning: fo:inline - Does not support block-level objects as children (isn't that fixed?) Mostly, but perhaps not completely. I seem to recall that Finn reported an Exception related to a LM not recognizing the double list structure of Knuth elements returned by some inline level LMs. Jeremias Maerki
URL of FOP trunk web pages
The wiki page ReleasePlanFirstPR says Copy xdocs/trunk to xdocs/0.90alpha1 to create the release documentation when it's good enough. That is very unstable. Wouldn't xdocs/0.90 be good? I need to create a reference to the hyphenation pages in OFFO. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: URL of FOP trunk web pages
On Nov 15, 2005, at 1:20 PM, Simon Pepping wrote: The wiki page ReleasePlanFirstPR says Copy xdocs/trunk to xdocs/0.90alpha1 to create the release documentation when it's good enough. That is very unstable. Wouldn't xdocs/0.90 be good? I need to create a reference to the hyphenation pages in OFFO. xdocs/0.90/ makes the most sense to me. That way, we only have to 'mv' it all more than once for each release version. There shouldn't be too many changes between 0.90alpha1, 0.90alpha2, 0.90beta1, etc. Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: URL of FOP trunk web pages
Good point. In addition to what you propose, what about an empty directory /latest which simply contains a .htaccess file that redirects you to the latest release? That would be a stable URL. I can set that up. On 15.11.2005 22:20:58 Simon Pepping wrote: The wiki page ReleasePlanFirstPR says Copy xdocs/trunk to xdocs/0.90alpha1 to create the release documentation when it's good enough. That is very unstable. Wouldn't xdocs/0.90 be good? I need to create a reference to the hyphenation pages in OFFO. Jeremias Maerki
Re: fo:marker and white space
On Wed, 16 Nov 2005 03:45 am, Jeremias Maerki wrote: Sounds like a good plan to me. Would you go after that? I have no problems with the suggestion to move the white space handling from Block into its own class so other fo's that need it can make use of it. However, I still need to be convinced that pushing it down to inline level is actually of benefit. I am afraid we will end up with the same problem we now have at LM level, that is text for a paragraph needs to be analysed across fo boundaries and the current LM structures are very much in the way of doing that. Whitespace needs to be handled across fo boundaries as well. The current iterator structure was designed to exactly facilitate that. It seems to be doing it well and I see no reason to replace it. Manuel On 15.11.2005 18:06:13 Andreas L Delmelle wrote: On Nov 15, 2005, at 10:03, Jeremias Maerki wrote: snip / The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Extracting handleWhitespace() into a separate class would, in any case, be A Good Thing. My 2 cents. Cheers, Andreas Jeremias Maerki
Re: Hyphenation
On Wed, 16 Nov 2005 12:14 am, Luca Furini wrote: Manuel Mall wrote: snip/ Tomorrow I should have some time to implement hyphenation-ladder-count and fix the penalty values for justified / unjustified text. Not sure what other committers and the PMC think but as a vote on the release has started I would suggest no further changes to the codebase unless agreed? What I am saying is - by all means do the development but don't put it back into svn until after the release. Of course this would apply to all committers who have Work In Progress not just Luca. Is that reasonable or am I 'out of line' here? Regards Luca Manuel
DO NOT REPLY [Bug 37521] New: - TableColLength throws misleading exception; s/PercentageBaseContext/PercentBaseContext/
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=37521. 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=37521 Summary: TableColLength throws misleading exception; s/PercentageBaseContext/PercentBaseContext/ Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Note how the very kind getValue():double tells that the method is deprecated, but does so such that `grep -rl PercentageBaseContext src` only yields TableColLength. If TableColLength is modified using the attached patch, the grep is at least a lot more accurate (even if no further toward solving what's wrong with RTFHandler). startColumn: Must call getValue with PercentageBaseContext java.lang.UnsupportedOperationException: Must call getValue with PercentageBaseContext at org.apache.fop.fo.properties.TableColLength.getValue(TableColLength.java:94) at org.apache.fop.render.rtf.RTFHandler.startColumn(RTFHandler.java:490) at org.apache.fop.render.rtf.RTFHandler.invokeDeferredEvent(RTFHandler.java:1315) at org.apache.fop.render.rtf.RTFHandler.recurseFONode(RTFHandler.java:1342) at org.apache.fop.render.rtf.RTFHandler.recurseFONode(RTFHandler.java:1364) at org.apache.fop.render.rtf.RTFHandler.recurseFONode(RTFHandler.java:1400) at org.apache.fop.render.rtf.RTFHandler.recurseFONode(RTFHandler.java:1400) at org.apache.fop.render.rtf.RTFHandler.recurseFONode(RTFHandler.java:1358) at org.apache.fop.render.rtf.RTFHandler.endPageSequence(RTFHandler.java:208) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:156) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:307) -- 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 37521] - TableColLength throws misleading exception; s/PercentageBaseContext/PercentBaseContext/
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=37521. 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=37521 --- Additional Comments From [EMAIL PROTECTED] 2005-11-16 03:21 --- Created an attachment (id=16976) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16976action=view) Corrects (a type-o?) the Exception thrown from getValue -- 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.
