DO NOT REPLY [Bug 53005] indexterm inside a footnote from docbook
https://issues.apache.org/bugzilla/show_bug.cgi?id=53005 Pascal Sancho pascal.san...@takoma.fr changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Pascal Sancho pascal.san...@takoma.fr 2012-03-30 08:15:04 UTC --- Please, can you: 1/ reformulate short description matching FOP vocabulary (indexterm and docbook are not handled by FOP)? 2/ attach a short XSL-FO (xml + xslt result) that demonstrates the issue? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: resolved, fixed bugs since FOP1.0 that need to be closed
On 28/03/12 17:39, Glenn Adams wrote: snip/ If we did have a full QA process, we would assign resolved bugs to someone to check and transition to verified state. Then one of the following would be designated to transition the bug to closed state: (1) original submitter, (2) fixer, (3) QA, or (4) PM. Leaving a bug in resolved state (according to the fixer's perspective) does not close the loop on the bug (at least in my opinion). In fact, it remains an open bug as far as bugzilla is concerned, e.g., closed bugs are displayed in strike-out style, while resolved bugs are not. The reason I am raising this now is because I am reviewing the bug list since the FOP 1.0 release in order to prepare information for a possible upcoming FOP 1.1 release. In doing this review, I found some bugs marked as resolved+fixed and others as closed+fixed. This makes it more difficult to compile and classify the status of bugs, and results in inconsistent views about the status of given bugs or FOP as a whole. The number of closed fixed bugs (54) is negligible compared to resolved fixed (908). I’d say that in our project, this is the closed fixed status that’s abnormal... I still don’t see what it brings you to close bugs? If we ‘automatically’ close them after 2 weeks have passed like you suggest below, then they wouldn’t be any more ‘verified’ than bugs that are simply ‘resolved’. ‘Verified’ implies that someone took out some steps to check that the bug was actually fixed, which wouldn’t be the case if it’s arbitrarily closed. Are you trying to get a list of bugs that have been fixed since 1.0 was released? Given that no attention is being paid to the ‘Version’ field, I don’t know how you can get that. Plus we may well have fixed bugs that were created at the time of 0.95, and not updated to include 1.0 after it was released, and if the bug was still present. We can decide to be more diligent in managing our bugs database, but we would have to clean it up first, and given the number of open issues, that would be /a lot/ of work. In the meantime, we have a status.xml file at the root of the project that lists the issues that have been resolved, and that are worth mentioning in a release announcement. In my experience, this status.xml file is fairly well maintained, and can safely be relied upon. Much more safely than our Bugzilla, at any rate. I would prefer that we attempt to take the effort to allow the original submitter to comment upon resolved+fix bugs and close the bug, and, if after some time has passed (e.g., 2 weeks) without the submitter doing this, then the fixer (or any committer) may close. One reason to do this is that the original submitter may not agree that the fix actually fixes the problem they reported. In which case they tend to react fairly quickly, and re-open the bug anyway. Sometimes (most of the time?) the original reporter is no longer involved, so it doesn’t really matter any more whether the bug has been fixed for them or not. If you or another committer prefers not to take the extra steps of closing bugs you have fixed, then I would be happy to close them out so you don't need to bother with it. Please let me know if you would like me to do this for you. If I’m convinced that closing bugs brings us some benefit, I will certainly do it. ATM though, I still don’t see the interest. So yes, I’d be grateful if you could do that for me for the moment. Thanks, Vincent
Re: on changing fop documentation sources to markdown
Makes sense to me. However, I don't think it's necessary to have all documentation as such. Perhaps just the Day to day stuff can be translated (things that are more likely to change). That's my current plan, anyway (although I don't yet know how to make that happen). Ye olde documentation can remain on xdoc format, or better yet get converted to Docbook format. Web Maestro Clay My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On Mar 29, 2012, at 9:22 PM, Glenn Adams gl...@skynav.com wrote: If I understand correctly, it is proposed that the FOP doc sources be changed from the current forrest based format (and XML format) to markdown format. If this is correct, then I would like to voice my objection to making this change. I am all for improving FOP documentation and management process; however, I am very leery about changing from an XML source format to a non-XML format, especially one that is as semantically sparse as the markdown format. If a change is to be made, then I would suggest that some XML format remain as the source format, and that markdown be one of a number of possible output (publishing) formats. Overall, I would prefer spending scarce resources on improving the depth, breadth, accuracy, and currency of FOP documentation content, rather than on switching to a different source format, management, or publishing format. I also feel it is very important to continue using FOP documentation to create some output format. I am not prepared to give up our dog food, as that provides one more set of tests on FOP, that would otherwise be missing. Given the sparseness of FOP test coverage, the more content we formally run FOP on, the better. G.
Re: A proposal to change the configuration and deployment of FOP
Hi Jeremias, Thanks for your feedback! On Wed, Mar 28, 2012 at 7:08 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter, can you please explain what problem you're trying to solve? From the Wiki pages I cannot derive that. And what do you mean by the separation of configuration and deployment? I'm particularly clueless as to how an API affects deployment here. By configuration I refer to the process of configuring the Fopfactory; both through direct programmatic means and via the parsing of the fop.xconf. By deployment I refer to the creation of the FOUserAgent and Fop object. The problems we wish to solve are ones of maintainability and simplicity, and modest in scope: We think that having an unmodifiable FopFactory would allow developers to make certain assertions with absolute confidence about the state of the system; from the point when the Fop object is created (what I was unhelpfully referring to as deployment) to the closing of the render output stream. Currently, classes that contribute to the FOP process have access to the FopFactory and can conceivably modify it. Although this does not actually occur in the code-base, extension code with access to the FopFactory could, causing non-trivial bugs to emerge. There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. Absolutely. We are trying to make minimal API changes to achieve our objectives. The updates we are making to allow the external control of all IO will require more substantial changes to the API, and therefore we considered this a good time to make further changes. Assuming that breaking changes are inevitable during FOP's lifetime, I suppose we have to judge the impact of frequent minor breaks against infrequent major breaks and the associated development costs. I think that the designed public API (which has been previously discussed) of FOP and the actual public API (classes/members with visible access modifiers) are generally not close enough; and the wider the API, the harder we all have to work maintain backwards compatibility. The current API is the product of long discussions and a positive vote back in 2005/2006. It was roughly modelled after the JAXP pattern with TransformerFactory and Transformer. I'd say that the API has proven to be solid over the years. We do not propose a big change to this API and I am confident that they will are faithful to the ambitions of the API requirements [1]. Referring to the hard requirements HR1-15: HR1 Our proposal should make it configuration more consistent, there were disparities between how FOP was configured (an empty fop.xconf would configure FOP differently to the case when none was supplied!) HR3 I think we have simplified API by making the distinction between config and deployment explicit. HR4 We will fully document. HR6 Immutability configuration help to reduce concurrency related issues. HR10 This is addressed as part of the wider URI resolution work. HR13 All examples will be updated. The remaining requirements have not affected by the proposal. If we do proceed with these changes as part of the wider URI resolution work, we would expect them to be included into trunk as part of a later major revision. [1] http://wiki.apache.org/xmlgraphics-fop/ApiRequirements On Wed, Mar 28, 2012 at 7:08 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Peter, can you please explain what problem you're trying to solve? From the Wiki pages I cannot derive that. And what do you mean by the separation of configuration and deployment? I'm particularly clueless as to how an API affects deployment here. There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. The current API is the product of long discussions and a positive vote back in 2005/2006. It was roughly modelled after the JAXP pattern with TransformerFactory and Transformer. I'd say that the API has proven to be solid over the years. For reference: http://wiki.apache.org/xmlgraphics-fop/ApiRequirements http://wiki.apache.org/xmlgraphics-fop/ApiDesign On 28.03.2012 12:02:27 Peter Hancock wrote: Hello, As part of our work addressing URI resolution in FOP [1], Mehdi and myself have been considering making changes to the configuration and deployment of FOP. Our proposal will introduce breaking changes to the public API that will affect code that embeds FOP. Please review our proposal [2] and provide feedback. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration Jeremias Maerki
Re: resolved, fixed bugs since FOP1.0 that need to be closed
On Fri, Mar 30, 2012 at 2:46 AM, Vincent Hennebert vhenneb...@gmail.comwrote: On 28/03/12 17:39, Glenn Adams wrote: snip/ If we did have a full QA process, we would assign resolved bugs to someone to check and transition to verified state. Then one of the following would be designated to transition the bug to closed state: (1) original submitter, (2) fixer, (3) QA, or (4) PM. Leaving a bug in resolved state (according to the fixer's perspective) does not close the loop on the bug (at least in my opinion). In fact, it remains an open bug as far as bugzilla is concerned, e.g., closed bugs are displayed in strike-out style, while resolved bugs are not. The reason I am raising this now is because I am reviewing the bug list since the FOP 1.0 release in order to prepare information for a possible upcoming FOP 1.1 release. In doing this review, I found some bugs marked as resolved+fixed and others as closed+fixed. This makes it more difficult to compile and classify the status of bugs, and results in inconsistent views about the status of given bugs or FOP as a whole. The number of closed fixed bugs (54) is negligible compared to resolved fixed (908). I’d say that in our project, this is the closed fixed status that’s abnormal... I agree that there appears to have been no policy to follow through on bug transitions after reaching resolved state. I'm suggesting that we attempt to agree on a policy and implement it, and I'm suggesting that we should transition every bug to closed state. If some devs prefer not to do this (e.g., because they don't see any need to do so), I would be happy to perform the final steps as a service for the group. I still don’t see what it brings you to close bugs? If we ‘automatically’ close them after 2 weeks have passed like you suggest below, then they wouldn’t be any more ‘verified’ than bugs that are simply ‘resolved’. ‘Verified’ implies that someone took out some steps to check that the bug was actually fixed, which wouldn’t be the case if it’s arbitrarily closed. Ideally we would have sufficient resources to perform a separate verification and review process for each resolved bug, after which the bug is formally closed. However, we do not in have these resources, so that is probably a more likely explanation for the current state of the FOP buglist. I would suggest it is better to arbitrary close resolved bugs even if a verification step has not been performed. This will be apparent from the bug's history information, so it would be easy enough to go back and find bugs that actually did go through the verified state. Are you trying to get a list of bugs that have been fixed since 1.0 was released? Actually, it was fairly easy to do this by qualifying a search for RESOLVED+FIXED with a condition that STATUS changed after 2010-07-20. The search link I provided in my original posting above contained that condition. Given that no attention is being paid to the ‘Version’ field, I don’t know how you can get that. Plus we may well have fixed bugs that were created at the time of 0.95, and not updated to include 1.0 after it was released, and if the bug was still present. OK, that's a possibility. We can decide to be more diligent in managing our bugs database, but we would have to clean it up first, and given the number of open issues, that would be /a lot/ of work. Actually, I very much want to clean up and triage our bug list. The task I'm discussing now is just a first, and more innocuous step in this process. In the meantime, we have a status.xml file at the root of the project that lists the issues that have been resolved, and that are worth mentioning in a release announcement. In my experience, this status.xml file is fairly well maintained, and can safely be relied upon. Much more safely than our Bugzilla, at any rate. Understood. However, in the long term, I wonder if it is a good idea to maintain two databases of changes. DRY. As an analogy, isn't this one of the reasons that the use of @author is discouraged: because that information is captured in SVN. In any case, I'm not suggesting we eliminate status.xml, at least not any time soon. Ideally, every status entry would make a reference to a bug #. Most do (at least those changes since FOP1.0 release), but some do not. For example, there a few bug fix entries that do not reference a bug #. I expect this is because a committer noticed a bug and fixed it without entering a bugzilla bug. I realize this takes a few more steps, but it would be better for tracking purposes if *every* status entry referred to a bug #. I would prefer that we attempt to take the effort to allow the original submitter to comment upon resolved+fix bugs and close the bug, and, if after some time has passed (e.g., 2 weeks) without the submitter doing this, then the fixer (or any committer) may close. One reason to do this is that the original submitter
Re: on changing fop documentation sources to markdown
On Fri, Mar 30, 2012 at 7:00 AM, Clay Leeds the.webmaes...@gmail.comwrote: Makes sense to me. However, I don't think it's necessary to have all documentation as such. Perhaps just the Day to day stuff can be translated (things that are more likely to change). There aren't too many docs whose content change on a frequent basis. Probably only the status.xml content. That's my current plan, anyway (although I don't yet know how to make that happen). Ye olde documentation can remain on xdoc format, or better yet get converted to Docbook format. I certainly have no problem with using MD as the source format for README and similar content, and would suggest these be converted to MD. I do have a problem with replacing current XML marked up xdoc sources with MD sources, though I'd be open to considering this on a case by case basis if there is good cause. Regarding XML source formats, right now we have xdoc, and it would take some effort for probably questionable results to convert to another XML schema. Plus that would require some additional learning curve or tool change for authors, so I'm not sure about changing to another XML format. For output formats, obviously we need HTML, but if it is useful to output MD, then I see no problem with someone adding that to the publish build process. I think it is useful to also continue publishing in PDF output format as well, if for no other reason than to exercise FOP. Otherwise, I don't have any strong preferences. For example, I have no love for forrest if another doc management system will be an improvement. So if you can find a way to transition to CMS as the doc management system while still reusing the existing source formats and output formats (modulo the above), then I have no objection to that. Web Maestro Clay My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On Mar 29, 2012, at 9:22 PM, Glenn Adams gl...@skynav.com wrote: If I understand correctly, it is proposed that the FOP doc sources be changed from the current forrest based format (and XML format) to markdown format. If this is correct, then I would like to voice my objection to making this change. I am all for improving FOP documentation and management process; however, I am very leery about changing from an XML source format to a non-XML format, especially one that is as semantically sparse as the markdown format. If a change is to be made, then I would suggest that some XML format remain as the source format, and that markdown be one of a number of possible output (publishing) formats. Overall, I would prefer spending scarce resources on improving the depth, breadth, accuracy, and currency of FOP documentation content, rather than on switching to a different source format, management, or publishing format. I also feel it is very important to continue using FOP documentation to create *some* output format. I am not prepared to give up our dog food, as that provides one more set of tests on FOP, that would otherwise be missing. Given the sparseness of FOP test coverage, the more content we formally run FOP on, the better. G.
DO NOT REPLY [Bug 3824] MIF option with tables
https://issues.apache.org/bugzilla/show_bug.cgi?id=3824 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|blocker |normal --- Comment #3 from Glenn Adams gl...@skynav.com 2012-03-30 20:32:32 UTC --- move to normal priority, pending further action -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 19228] [PATCH] Child LayoutContext is null in certain circumstances
https://issues.apache.org/bugzilla/show_bug.cgi?id=19228 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|blocker |normal --- Comment #2 from Glenn Adams gl...@skynav.com 2012-03-30 20:35:19 UTC --- move to normal priority, pending further action -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50435] access denied (java.util.PropertyPermission org.apache.fop.fo.properties.use-cache read)
https://issues.apache.org/bugzilla/show_bug.cgi?id=50435 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|blocker |normal --- Comment #2 from Glenn Adams gl...@skynav.com 2012-03-30 20:36:06 UTC --- move to normal priority, pending further action -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 36935] table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
https://issues.apache.org/bugzilla/show_bug.cgi?id=36935 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|blocker |normal --- Comment #9 from Glenn Adams gl...@skynav.com 2012-03-30 20:37:30 UTC --- move to normal priority, pending further action -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32970] Sticking words in generated PDF document
https://issues.apache.org/bugzilla/show_bug.cgi?id=32970 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 Severity|critical|normal -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #37 from Glenn Adams gl...@skynav.com 2012-03-30 22:23:28 UTC --- (In reply to comment #36) As there is still no new release, I can't go into an evaluation phase. So, I'm waiting for a release to use to get some time to built a reproducable test case. Is there any planned dead line for a new FOP release? can you use a nightly build [1] to test? see also [2] [1] http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ [2] http://ci.apache.org/builders/fop-trunk/ -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52736] Cannot generate JPEG as output format
https://issues.apache.org/bugzilla/show_bug.cgi?id=52736 Luis Bernardo lmpmberna...@gmail.com changed: What|Removed |Added OS/Version||All --- Comment #1 from Luis Bernardo lmpmberna...@gmail.com 2012-03-30 23:28:23 UTC --- Can you provide more information and an example? Do you call that ImageWriter directly? FOP selects it? And if so, how did you configure it? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
