Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Formatting issues in PDF version of HTTP Connectors Load Balancing Guide|
|Product:||[Community] Publican||Reporter:||Jared MORGAN <jmorgan>|
|Component:||publican||Assignee:||Jeff Fearn <jfearn>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Ruediger Landmann <rlandman>|
|Version:||2.5||CC:||mmcallis, mmurray, publican-list, r.landmann|
|Fixed In Version:||3.0.0||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-10-30 23:11:44 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jared MORGAN 2011-05-18 20:06:41 EDT
Description of problem: Some <task> blocks are missing from the PDF version of the guide. The <task> <title> is present, and a space has been reserved for the content, however the rest of the task is missing. Some <task> have been mashed together Version-Release number of selected component (if applicable): publican v2.5 How reproducible: 100% Steps to Reproduce: 1. Open html-single and pdf version of the HTTP Connectors Load Balancing Guide 2. Search for "Task: Configure Apache to Load mod_jk" 3. Search for the section title "Configure a Load-balancing Proxy Using the HTTP Connector" Actual results: For reproduction step 2, in the PDF, the task title is present, but the task body with the procedure is missing For reproduction step 3, The task and graphic are mashed together. There are other instances of this in the document. It only seems to happen when the <task> is rendered in the bottom 3rd of the page. It is like FOP is trying to keep the <task> block together as best it can on one page. Expected results: All mis-formatted <task> entries are paginated correctly.
Comment 3 Jeff Fearn 2011-05-19 05:25:42 EDT
The problem here is that with the admonition and the programlisting the task is longer than a single page and FOP 0.95 can't handle a keep-together.within-column element, in this case the task, being longer than a single page. Removing keep-together.within-column can cause things to page break at odd locations and it's been a log standing policy to accept the page length limitation on such items. I doubt anyone will really care, but it's probably best to ask on the publican-list if you want it changed. FOP 1.0 might fix this, so it might be worth talking to Rudi about getting it tested.
Comment 4 Jared MORGAN 2011-05-19 20:24:36 EDT
Thanks Jeff I'll pose the question in a RFE on publican-list. I'll also reference this bug so people know what I'm on about. Thanks for your help. Cheers Jared
Comment 6 Jared MORGAN 2011-10-10 18:18:09 EDT
Could I please get an update on this issue, Jeff? I'm getting review comments back from the JBoss Enterprise Application Platform Engineering QE reporting this issue again . I followed due process and emailed the list to ask if anyone had objections to the change, and no one responded to the email. Can we take silence as acceptance and roll this change in please, Jeff? Is there some other due process I need to do before this change could be implemented? Just let me know if I need to do anything else, and I'll make it happen. Cheers Jared  https://issues.jboss.org/browse/JBPAPP-5299?focusedCommentId=12633452&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12633452
Comment 7 Jeff Fearn 2011-10-10 18:36:18 EDT
FOP issues are way down the priority list. It requires a large QA effort to vet changes across 22 languages. Hopefully we can switch to wkhtmltopdf soon and never have to worry about stinky FOP again. Cheers, Jeff.
Comment 8 Jared MORGAN 2011-10-10 18:50:19 EDT
(In reply to comment #7) > FOP issues are way down the priority list. It requires a large QA effort to vet > changes across 22 languages. > > Hopefully we can switch to wkhtmltopdf soon and never have to worry about > stinky FOP again. > > Cheers, Jeff. No problems, Jeff. I understand your point of view with regard to this. I'll update the JIRA with the current status.