From bugzilla at redhat.com Wed Aug 7 20:04:48 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 07 Aug 2013 20:04:48 +0000 Subject: [publican-list] [Bug 701929] RFA: Customising brands section In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=701929 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.landmann at redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=WhKUjLWso5&a=cc_unsubscribe From bugzilla at redhat.com Wed Aug 7 20:05:22 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 07 Aug 2013 20:05:22 +0000 Subject: [publican-list] [Bug 701929] RFA: Customising brands section In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=701929 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tTSvpkJ5Io&a=cc_unsubscribe From bugzilla at redhat.com Wed Aug 7 20:05:51 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 07 Aug 2013 20:05:51 +0000 Subject: [publican-list] [Bug 701929] RFA: Customising brands section In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=701929 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.2 |3.3 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LgdAbR0lrM&a=cc_unsubscribe From zdover at redhat.com Thu Aug 8 07:33:20 2013 From: zdover at redhat.com (Zac Dover) Date: Thu, 8 Aug 2013 03:33:20 -0400 (EDT) Subject: [publican-list] Publican 3.2 is now out!!! Get it now!!!!!! In-Reply-To: <1200477312.13161638.1375947172795.JavaMail.root@redhat.com> Message-ID: <635048227.13162019.1375947199994.JavaMail.root@redhat.com> We are happy to announce the release of Publican 3.2! The highest-priority fixes and enhancements in this release add improvements and considerable flexibility to Publican-driven websites, allowing heavier brand customisation. In particular, brands can now ship web templates and site-level JavaScript. Interoperability with docs generated outside Publican is also better, allowing custom "img_dir" and "extras" directories, and support for a wider range of DocBook 4 conditions (all of them now!) This version of Publican continues to improve the quality of PDFs we produce with wkhtmltopdf, with many bugfixes and enhancements to presentation. We also pass options to wkhtmltopdf to give you more control of the PDF layout, and support s as well as individual s for the first time ever. BUT we haven't forgotten FOP lovers too! You can now switch between PDF engines with the --pdftool option on the command line. For translators, Publican 3.2 fixes strings getting broken up (or losing pieces completely) when certain tags were nested inside other tags. It also prevents a common problem where revision numbers got tangled up when "update_po" was run multiple times on the same content. Publican 3.2 supports /some/ languages when a project uses only the language subtag to identify a language (for example, ja), but we still always recommend using a locale subtag too (ja-JP). We also include a new action: "publican trans_drop", which takes a snapshot of a book's XML and uses it as the basis for POT files, thus minimising the chances of writers inadvertently breaking translators' work. And a few other things to make life easier: * programming languages are now case-insensitive in the "language" attribute (no more guessing about what the Kate highlighting engine prefers!) * entities in CDATA tags are left unresolved * XML is supported in add_revision messages All together, there are about 60 things fixed or added to this new version of Publican; you can find a more complete description of what's new in the Release Notes at: http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Release_Notes/index.html You can find the tarball at: https://fedorahosted.org/releases/p/u/publican/Publican-v3.2.0.tar.gz and the SRPM at: https://fedorahosted.org/releases/p/u/publican/publican-3.2.0-0.el6.src.rpm Thanks to everyone involved in Publican 3.2 testing! This includes Laura Bailey, Jodi Biddle, Petr Bokoc, Tomas Capek, Steve Gordon, Tim Hildred, Dan MacPherson, Katie Miller, Misha Husnain Ali, Dayle Parker, Petr Penicka, Martin Prpic, Scott Radvan, Bruce Reeler, and Gemma Sheldon. I apologize to anyone I may have missed. Thanks to everyone who worked on the release notes! This includes (and I'm going alphabetically here): Laura Bailey, Misha Husnain Ali, R?diger Landmann, Dayle Parker, Scott Radvan, Bruce Reeler, and Gemma Sheldon. J. Zachary Dover Content Author II Engineering Content Services Red Hat Asia Pacific Brisbane, Australia zdover at redhat.com From miesfeld at gmail.com Thu Aug 8 19:20:50 2013 From: miesfeld at gmail.com (Mark Miesfeld) Date: Thu, 8 Aug 2013 12:20:50 -0700 Subject: [publican-list] Some help with Publican failures Message-ID: Our project uses DocBook source for our documentation. Some time ago we switched to Publican to produce the final PDF files. I got things working with Publican 2.8.2 and have been stuck there because, although there were some problems, I could at least produce the final PDF file. Today I made the effort to upgrade to Publican 3.1.5 so that hopefully I can move on to 3.2.0 when an install rpm is available. I installed wkhtmltopdf from a link Jeff provided last month: http://jfearn.fedorapeople.**org/wkhtmltopdf/ where he also said: All of these changes are compatible with Publican 3.1.5 The two main problems I have, Jeff suggested that wkhtmltopdf would fix. Now with 3.1.5 I have 2 problems: 1.) While building I start getting these errors for every single page. It starts with page 511: file:///usr/share/publican/book_templates/header.html?page=511 Error: Failed loading page file:///usr/share/publican/book_templates/header.html?page=1726§ion=Revision History&title=ooRexx Documentation 4.2.3 ooDialog Reference 4.2.3&subsection=X&frompage=1&subsubsection=A.9.10. setCursorPos&topage=1723&doctitle=ooRexx Documentation 4.2.3 ooDialog Reference 4.2.3&webpage=tmp/en-US/html-pdf/index.html&time=10:09 AM&date=8/8/13 (sometimes it will work just to ignore this error with --load-error-handling ignore) I get one error for both header.html and footer.html. The files do exist at the location and it would seem that the first 500 pages things work What does the error message mean? 2.) Then things just abend: Error: Failed loading page file:///usr/share/publican/book_templates/footer.html?page=1726§ion=Revision History&title=ooRexx Documentation 4.2.3 ooDialog Reference 4.2.3&subsection=X&frompage=1&subsubsection=A.9.10. setCursorPos&topage=1723&doctitle=ooRexx Documentation 4.2.3 ooDialog Reference 4.2.3&webpage=tmp/en-US/html-pdf/index.html&time=10:09 AM&date=8/8/13 (sometimes it will work just to ignore this error with --load-error-handling ignore) QPaintDevice: Cannot destroy paint device that is being painted wkhtmltopdf died, PDF generation failed. Check log for details. at /usr/bin/publican line 921 What log, where? This book is, admittedly, a little large. Can wkhtmltopdf just not handle a large book? Any ideas or help? Thanks -- Mark Miesfeld -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Thu Aug 8 23:53:35 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 09 Aug 2013 09:53:35 +1000 Subject: [publican-list] Some help with Publican failures In-Reply-To: References: Message-ID: <52042F7F.90905@redhat.com> On 08/09/2013 05:20 AM, Mark Miesfeld wrote: > Our project uses DocBook source for our documentation. Some time ago we > switched to Publican to produce the final PDF files. > > I got things working with Publican 2.8.2 and have been stuck there because, > although there were some problems, I could at least produce the final PDF > file. > > Today I made the effort to upgrade to Publican 3.1.5 so that hopefully I > can move on to 3.2.0 when an install rpm is available. > > I installed wkhtmltopdf from a link Jeff provided last month: > > http://jfearn.fedorapeople.**org/wkhtmltopdf/ > > where he also said: All of these changes are compatible with Publican 3.1.5 > > The two main problems I have, Jeff suggested that wkhtmltopdf would fix. > > Now with 3.1.5 I have 2 problems: > > 1.) While building I start getting these errors for every single page. It > starts with page 511: > > file:///usr/share/publican/book_templates/header.html?page=511 > > Error: Failed loading page > file:///usr/share/publican/book_templates/header.html?page=1726§ion=Revision > History&title=ooRexx Documentation 4.2.3 ooDialog Reference > 4.2.3&subsection=X&frompage=1&subsubsection=A.9.10. > setCursorPos&topage=1723&doctitle=ooRexx Documentation 4.2.3 ooDialog > Reference 4.2.3&webpage=tmp/en-US/html-pdf/index.html&time=10:09 > AM&date=8/8/13 (sometimes it will work just to ignore this error with > --load-error-handling ignore) > > I get one error for both header.html and footer.html. The files do exist > at the location and it would seem that the first 500 pages things work > > What does the error message mean? > > 2.) Then things just abend: > > Error: Failed loading page > file:///usr/share/publican/book_templates/footer.html?page=1726§ion=Revision > History&title=ooRexx Documentation 4.2.3 ooDialog Reference > 4.2.3&subsection=X&frompage=1&subsubsection=A.9.10. > setCursorPos&topage=1723&doctitle=ooRexx Documentation 4.2.3 ooDialog > Reference 4.2.3&webpage=tmp/en-US/html-pdf/index.html&time=10:09 > AM&date=8/8/13 (sometimes it will work just to ignore this error with > --load-error-handling ignore) > QPaintDevice: Cannot destroy paint device that is being painted > > wkhtmltopdf died, PDF generation failed. Check log for details. > at /usr/bin/publican line 921 > > What log, where? > > This book is, admittedly, a little large. Can wkhtmltopdf just not handle > a large book? > > Any ideas or help? Hi Mark, looks like you are hitting the file handle limit. If so you need to change ulimts. http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/chap-Users_Guide-Frequently_Asked_Questions.html#idp24423296 Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From bugzilla at redhat.com Fri Aug 9 04:47:35 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 09 Aug 2013 04:47:35 +0000 Subject: [publican-list] [Bug 887707] RFE: Freeze XML that on which a particular translation is based. In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=887707 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED Fixed In Version| |3.2.0 Resolution|--- |CURRENTRELEASE Flags|needinfo?(r.landmann at redhat | |.com) | Last Closed| |2013-08-09 00:47:35 --- Comment #6 from Jeff Fearn --- The fix for this bug has been shipped in publican 3.2.0 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CGRSggBXOU&a=cc_unsubscribe From bugzilla at redhat.com Fri Aug 9 04:47:44 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 09 Aug 2013 04:47:44 +0000 Subject: [publican-list] [Bug 653447] footnote in generates two entries in html In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=653447 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED Fixed In Version| |3.2.0 Resolution|--- |CURRENTRELEASE Last Closed| |2013-08-09 00:47:44 --- Comment #10 from Jeff Fearn --- The fix for this bug has been shipped in publican 3.2.0 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iRshLfjZlk&a=cc_unsubscribe From bugzilla at redhat.com Fri Aug 9 04:49:06 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 09 Aug 2013 04:49:06 +0000 Subject: [publican-list] [Bug 663399] PUG 3.7.1.1. "Source RPM packages and binary RPM packages" needs review In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=663399 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED Fixed In Version| |3.2.0 Resolution|--- |CURRENTRELEASE Last Closed|2010-12-15 16:35:37 |2013-08-09 00:49:06 --- Comment #9 from Jeff Fearn --- The fix for this bug has been shipped in publican 3.2.0 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gnQSAK0S75&a=cc_unsubscribe From miesfeld at gmail.com Fri Aug 9 14:50:54 2013 From: miesfeld at gmail.com (Mark Miesfeld) Date: Fri, 9 Aug 2013 07:50:54 -0700 Subject: [publican-list] Some help with Publican failures In-Reply-To: <52042F7F.90905@redhat.com> References: <52042F7F.90905@redhat.com> Message-ID: On Thu, Aug 8, 2013 at 4:53 PM, Jeff Fearn wrote: > On 08/09/2013 05:20 AM, Mark Miesfeld wrote: > >> > Error: Failed loading page >> file:///usr/share/publican/**book_templates/header.html?** >> page=1726§ion=Revision >> History&title=ooRexx Documentation 4.2.3 ooDialog Reference >> 4.2.3&subsection=X&frompage=1&**subsubsection=A.9.10. >> setCursorPos&topage=1723&**doctitle=ooRexx Documentation 4.2.3 ooDialog >> Reference 4.2.3&webpage=tmp/en-US/html-**pdf/index.html&time=10:09 >> AM&date=8/8/13 (sometimes it will work just to ignore this error with >> --load-error-handling ignore) >> >> Any ideas or help? >> > > Hi Mark, looks like you are hitting the file handle limit. If so you need > to change ulimts. > Thanks a lot Jeff that was indeed the problem: Loading headers and footers (5/6) Printing pages (6/6) Done Finished pdf -- Mark Miesfeld -------------- next part -------------- An HTML attachment was scrubbed... URL: From fbolton at redhat.com Fri Aug 9 14:59:06 2013 From: fbolton at redhat.com (Fintan Bolton) Date: Fri, 09 Aug 2013 16:59:06 +0200 Subject: [publican-list] Some help with Publican failures In-Reply-To: <52042F7F.90905@redhat.com> References: <52042F7F.90905@redhat.com> Message-ID: <520503BA.8060701@redhat.com> It would be nice to get this fixed upstream in the wkhtmltopdf code base. It's just wkhtmltopdf being sloppy about closing file descriptors. On 09/08/2013 01:53, Jeff Fearn wrote: > On 08/09/2013 05:20 AM, Mark Miesfeld wrote: >> Our project uses DocBook source for our documentation. Some time ago we >> switched to Publican to produce the final PDF files. >> >> I got things working with Publican 2.8.2 and have been stuck there >> because, >> although there were some problems, I could at least produce the final PDF >> file. >> >> Today I made the effort to upgrade to Publican 3.1.5 so that hopefully I >> can move on to 3.2.0 when an install rpm is available. >> >> I installed wkhtmltopdf from a link Jeff provided last month: >> >> http://jfearn.fedorapeople.**org/wkhtmltopdf/ >> >> >> where he also said: All of these changes are compatible with Publican >> 3.1.5 >> >> The two main problems I have, Jeff suggested that wkhtmltopdf would fix. >> >> Now with 3.1.5 I have 2 problems: >> >> 1.) While building I start getting these errors for every single >> page. It >> starts with page 511: >> >> file:///usr/share/publican/book_templates/header.html?page=511 >> >> Error: Failed loading page >> file:///usr/share/publican/book_templates/header.html?page=1726§ion=Revision >> >> History&title=ooRexx Documentation 4.2.3 ooDialog Reference >> 4.2.3&subsection=X&frompage=1&subsubsection=A.9.10. >> setCursorPos&topage=1723&doctitle=ooRexx Documentation 4.2.3 ooDialog >> Reference 4.2.3&webpage=tmp/en-US/html-pdf/index.html&time=10:09 >> AM&date=8/8/13 (sometimes it will work just to ignore this error with >> --load-error-handling ignore) >> >> I get one error for both header.html and footer.html. The files do exist >> at the location and it would seem that the first 500 pages things work >> >> What does the error message mean? >> >> 2.) Then things just abend: >> >> Error: Failed loading page >> file:///usr/share/publican/book_templates/footer.html?page=1726§ion=Revision >> >> History&title=ooRexx Documentation 4.2.3 ooDialog Reference >> 4.2.3&subsection=X&frompage=1&subsubsection=A.9.10. >> setCursorPos&topage=1723&doctitle=ooRexx Documentation 4.2.3 ooDialog >> Reference 4.2.3&webpage=tmp/en-US/html-pdf/index.html&time=10:09 >> AM&date=8/8/13 (sometimes it will work just to ignore this error with >> --load-error-handling ignore) >> QPaintDevice: Cannot destroy paint device that is being painted >> >> wkhtmltopdf died, PDF generation failed. Check log for details. >> at /usr/bin/publican line 921 >> >> What log, where? >> >> This book is, admittedly, a little large. Can wkhtmltopdf just not >> handle >> a large book? >> >> Any ideas or help? > > Hi Mark, looks like you are hitting the file handle limit. If so you > need to change ulimts. > > http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/chap-Users_Guide-Frequently_Asked_Questions.html#idp24423296 > > > Cheers, Jeff. > -- Fintan Bolton Content Services | Red Hat, Inc. fbolton at redhat.com home office. +49-89-14347132 blog: http://docinfusion.blogspot.com From miesfeld at gmail.com Fri Aug 9 18:31:49 2013 From: miesfeld at gmail.com (Mark Miesfeld) Date: Fri, 9 Aug 2013 11:31:49 -0700 Subject: [publican-list] Publican 3.2 is now out!!! Get it now!!!!!! In-Reply-To: <635048227.13162019.1375947199994.JavaMail.root@redhat.com> References: <1200477312.13161638.1375947172795.JavaMail.root@redhat.com> <635048227.13162019.1375947199994.JavaMail.root@redhat.com> Message-ID: On Thu, Aug 8, 2013 at 12:33 AM, Zac Dover wrote: > We are happy to announce the release of Publican 3.2! > > Will there be a rpm to install the built version of 3.2.0? And where should I watch for it? I know where to find the source for the various versions, https://fedorahosted.org/releases/p/u/publican but for an end-user that just wants to upgrade my system to use 3.2.0 to produce my document project, an install rpm is just so much easier to deal with. I tried building from source. The read me just has: RHEL/Fedora cd publican $ perl Build.PL if this complains about missing deps, on Fedora 10+, and RHEL 6, run $ yum-builddep publican $ ./Build rpm After fixing all the dependencies, I then end up with: ... Created MYMETA.yml and MYMETA.json Creating new 'Build' script for 'Publican' version 'v3.2.0' [miesfeld at Raven Publican-v3.2.0]$ ./Build rpm Cleaning up build files can't open POD file at /home/miesfeld/work/wc/publican/Publican-v3.2.0/_build/lib/My/Builder.pm line 191. [miesfeld at Raven Publican-v3.2.0]$ So, as I said, for end users an install rpm is much less of a headache. -- Mark Miesfeld -------------- next part -------------- An HTML attachment was scrubbed... URL: From Norman at dunbar-it.co.uk Tue Aug 20 12:21:06 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Tue, 20 Aug 2013 13:21:06 +0100 Subject: [publican-list] Publican 3.2 is now out!!! Get it now!!!!!! In-Reply-To: <635048227.13162019.1375947199994.JavaMail.root@redhat.com> References: <635048227.13162019.1375947199994.JavaMail.root@redhat.com> Message-ID: <52135F32.8030603@dunbar-it.co.uk> Afternoon all, On 08/08/13 08:33, Zac Dover wrote: > We are happy to announce the release of Publican 3.2! > ... I've downloaded, untar'd and built Publican 3.2.0 on a Linux Mint 13 KDE setup. (Yes, I know, one day I'll stop switching distros!) The Readme need a wee fix for the CPAN version of building from source: CPAN cd publican Currently you have to manually install File::pushd from CPAN first ... $ sudo ./Build install The install line needs a "sudo" of you just get an error about not being able to write to /etc. I'm off to try it out now! Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Tue Aug 20 14:17:07 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Tue, 20 Aug 2013 15:17:07 +0100 Subject: [publican-list] Revision numbers, Screen output and error messages in Publican 3.2.0 Message-ID: <52137A63.7010303@dunbar-it.co.uk> Afternoon all, Well, it didn't take me long to hit a snag! REVISION NUMBERS: I tried to build an existing Publican book which has existed through a number of revisions. It seems that there have been changes in the revision history department. These I have found and corrected by simply adding a revision to the existing revision number - I changed "1.0" to "1.0-0". Not a major problem, as it turns out I only needed to change the very first one in the revision history! If I don't have this new format in the very first revision, the build barfs with the following error: revnumber (1.0) does not match the required format of '^([0-9.]*)-([0-9.]*)$/' at /usr/local/bin/publican line 725. The "add_revision" command will not work, same error, if the first revision number is not in the above format. Problem. It appears that the revision history is assumed to be in descending order from most recent revision at the top, to oldest revision at the bottom. My books are the opposite way around. Is there a way to get publican to scan for the biggest revision number rather than finding the first one? When I add a revision number, and do not specify the --revnumber parameter, it finds the very first existing revision (1.0-0 in my case) and adds one to it to give 1.0-1 when the real revision was actually 3.2-0 and it should have added 3.2.1. Problem. When I use the --revnumber="3.2-1" parameter, I get it added at the very top, so my revision history is now out of sequence. Not a major problem, but again, is there a way to get Publican to add the new revision at the bottom rather than the top? Sorry, I'm not a Perl developer, I can sort of muddle though, so I'm unable to help in this problem. :-( SCREEN OUTPUT: I build the user guide for 3.2 as follows: cd Publican-v3.2.0/Users_Guide publican build --langs=en-US --formats=pdf And let it run. It built quite happily but when I read it, there are problems with screen outputs. In section 1.2. Pull-quote Conventions there is a paragraph with the text "Output sent to a terminal is set in mono-spaced roman and presented thus:" above a screen/programlisting rendering. The rendering is all over the place, rather than being the two separate lines you intended. I reported this/a similar problem a while back and provided a fix as it was something that was really getting on my nerves with another of my books. (Jeff helped me track it down!) The following is extracted form my thread "Screen and Programlisting oddities in Publican 2.8" dated 15th March 2013: [extract] Found it! If I comment out the wrap-option attribute below, as shown, it works on my test chapter. start \ So, comment out line 97 in pdf.xsl for Publican 2.8. [/extract] In Publican 3.0, the offending line is also 97 in Publican-v3.2.0/Users_Guide/blib/datadir/xsl/pdf.xsl. WARING: commenting this line out, as above, means that you have to manually "wrap" screen and programlistings to keep them within the boundaries of a pdf page. However, it does fix my screen problem - and makes the User Guide much better formatted! ERROR MESSAGES: Also, when building, I see lots of these errors/warnings: Invalid property value encountered in keep-together.within-column="": org.apache.fop.fo.expr.PropertyException: file:/home/norman/Publican/Publican-v3.2.0/Users_Guide/build/en-US/xml/Users_Guide.fo:3629:48: No conversion defined ; property:'keep-together.within-column' (See position 3629:421) Also in my thread mentioned above, I "resolved" this by editing line 405 of pdf.xsl, which is part of the attribute set for example.properties. The line needs a value adding between "><" - from this: To this: auto Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Tue Aug 20 16:33:20 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Tue, 20 Aug 2013 17:33:20 +0100 Subject: [publican-list] Another foible with Publican 3.2.0 Message-ID: <52139A50.3070608@dunbar-it.co.uk> Evening all, I've found something else in Publican 3.2 that affects one of my books. I haven't noticed this before, so it might not be related to 3.2 itself. I have a page, A4 sized, which has a on it with a number of s. If a s has an or and those particular lists are at the bottom of a page, then when rendered to pdf, using fop, the ordered list renders all over the footer details at the bottom of the page. I also see pages where the actual is rendered on the footer area as well. These steps have an rather than an ordered one. Pages where the reaches the bottom of the page, and which have simple s do not obliterate the footer, it only appears to be where lists are involved. It also seems to only occur on those pages where the entire page is one or more s from a The following should demonstrate the problem: $ publican create --type=article --name=steps --version="1.0-0" $ cd steps $ vi en-US/steps.xml, the following is what the stuff between the
tags looks like on saving:
I have added the second include line, and removed the other test cruft! Create article.xml as follows:
How Procedure Steps Will Obliterate PDF Page Footer
And finally, create onestep.xml as follows: This is a list item. This is a list item. This is a list item. This is a list item. This is a list item. This is a list item. This is a list item. $ publican build -langs=en-US --formats=pdf When rendered as pdf, using fop, the first page of the article is fine, the steps stop just above the footer area's horizontal rule. In my pdf I see step 2 on page one, has two items from the list, which then continues on page 2. One page two, however, the list items are rendered all down the page to the actual paper edge. Step 8 has 3 items below the horizontal rule and the beginning of step 9 is rendered partly off the page. I have to use fop for pdf rendering as I have indexes in my books etc and the wkhtmltopdf utility renders the page numbers as sections as if it was a normal html page. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Tue Aug 20 17:05:23 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Tue, 20 Aug 2013 18:05:23 +0100 Subject: [publican-list] Publican 2.3 - not using files in Common_Content Message-ID: <5213A1D3.1060403@dunbar-it.co.uk> Evening all, Publican 2.3 on Linux Mint 13 KDE. I build the latest version from source and followed the CPAN instructions to get the system built and the dependencies installed. My onely deviation from the README was the final stage, installing, where I had to run this command: $ sudo ./Build install I can see the default brands and stuff in /usr/share/publican but when I attempt to use a brand that I have installed there, it barfs saying it cannot find the brand. However, it is not looking in /usr/share/publican/Common_Content for the brands, it is looking in the area where I build the code - in my home directory in : /home/norman/Publican/Publican-v3.2.0/blib/datadir/Common_Content When I reinstall a brand into the above location (--path) then my builds manage to pick up the correct files. I'm now puzzled as to what exactly the install did (publican is /usr/local/bin/publican) and all the support files etc appear to have been copied to /usr/share/publican as normal (which didn't exist beforehand). I've looked in the User Guide and it does mention the common_content option in publican.cfg and also states that the default is already set to /usr/share/publican/Common_Content, but it's not seemingly picking up the default for me. Not only that, it's ignores the setting even when explicitly defined in publican.cfg: $ cat publican.cfg xml_lang: en-US type: book brand: jms tmp_dir: build_tmp debug: 1 common_content: /usr/share/publican/Common_Content $ publican build --langs=en-US formats=pdf ... Beginning work on en-US DTD Validation OK Starting pdf Using XML::LibXSLT on /home/norman/Publican/Publican-v3.2.0/blib/datadir/xsl/pdf.xsl ... It's not picking up the pdf.xsl from /usr/share/publican/xsl. If I add the common_config option to /usr/share/publican, it does pick up the global files rather than the local ones. It seems that common_config is accepted while common_content is ignored? Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From jfearn at redhat.com Wed Aug 21 03:41:30 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 21 Aug 2013 13:41:30 +1000 Subject: [publican-list] Publican 3.2 is now out!!! Get it now!!!!!! In-Reply-To: <52135F32.8030603@dunbar-it.co.uk> References: <635048227.13162019.1375947199994.JavaMail.root@redhat.com> <52135F32.8030603@dunbar-it.co.uk> Message-ID: <521436EA.6030005@redhat.com> Hi Norm, this is a bug in Build.PL, it should not be structured this way. I've opened a bug. https://bugzilla.redhat.com/show_bug.cgi?id=999259 Cheers, Jeff. On 08/20/2013 10:21 PM, Norman Dunbar wrote: > Afternoon all, > > On 08/08/13 08:33, Zac Dover wrote: >> We are happy to announce the release of Publican 3.2! > > ... > > I've downloaded, untar'd and built Publican 3.2.0 on a Linux Mint 13 KDE setup. (Yes, I know, one day I'll stop switching distros!) > > The Readme need a wee fix for the CPAN version of building from source: > > CPAN > cd publican > Currently you have to manually install File::pushd from CPAN first > ... > $ sudo ./Build install > > The install line needs a "sudo" of you just get an error about not being able to write to /etc. > > I'm off to try it out now! > > > Cheers, > Norm. > -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jfearn at redhat.com Wed Aug 21 03:49:41 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 21 Aug 2013 13:49:41 +1000 Subject: [publican-list] Revision numbers, Screen output and error messages in Publican 3.2.0 In-Reply-To: <52137A63.7010303@dunbar-it.co.uk> References: <52137A63.7010303@dunbar-it.co.uk> Message-ID: <521438D5.3090108@redhat.com> Hi Norm, On 08/21/2013 12:17 AM, Norman Dunbar wrote: > Afternoon all, > > Well, it didn't take me long to hit a snag! > > REVISION NUMBERS: > > I tried to build an existing Publican book which has existed through a number of revisions. It seems that there have been changes in the revision history department. These I have found and corrected by simply adding a revision to the existing revision number - I changed "1.0" to "1.0-0". Not a major problem, as it turns out I only needed to change the very first one in the revision history! > > If I don't have this new format in the very first revision, the build barfs with the following error: > > revnumber (1.0) does not match the required format of '^([0-9.]*)-([0-9.]*)$/' at /usr/local/bin/publican line 725. > > > The "add_revision" command will not work, same error, if the first revision number is not in the above format. > > Problem. It appears that the revision history is assumed to be in descending order from most recent revision at the top, to oldest revision at the bottom. My books are the opposite way around. Is there a way to get publican to scan for the biggest revision number rather than finding the first one? > > When I add a revision number, and do not specify the --revnumber parameter, it finds the very first existing revision (1.0-0 in my case) and adds one to it to give 1.0-1 when the real revision was actually 3.2-0 and it should have added 3.2.1. > > > Problem. When I use the --revnumber="3.2-1" parameter, I get it added at the very top, so my revision history is now out of sequence. Not a major problem, but again, is there a way to get Publican to add the new revision at the bottom rather than the top? > > Sorry, I'm not a Perl developer, I can sort of muddle though, so I'm unable to help in this problem. :-( This is "working as intended" however unless you are building RPMs for your books it's not actually relevant. Please open a bug requesting the ability to allow oldest to newest order in the revision history. > > > SCREEN OUTPUT: > > I build the user guide for 3.2 as follows: > > cd Publican-v3.2.0/Users_Guide > publican build --langs=en-US --formats=pdf > > And let it run. It built quite happily but when I read it, there are problems with screen outputs. > > In section 1.2. Pull-quote Conventions there is a paragraph with the text "Output sent to a terminal is set in mono-spaced roman and presented thus:" above a screen/programlisting rendering. The rendering is all over the place, rather than being the two separate lines you intended. > > I reported this/a similar problem a while back and provided a fix as it was something that was really getting on my nerves with another of my books. (Jeff helped me track it down!) > > The following is extracted form my thread "Screen and Programlisting oddities in Publican 2.8" dated 15th March 2013: > > [extract] > Found it! If I comment out the wrap-option attribute below, as shown, it works on my test chapter. > > > start > > \ > > > > So, comment out line 97 in pdf.xsl for Publican 2.8. > [/extract] > > In Publican 3.0, the offending line is also 97 in Publican-v3.2.0/Users_Guide/blib/datadir/xsl/pdf.xsl. > > WARING: commenting this line out, as above, means that you have to manually "wrap" screen and programlistings to keep them within the boundaries of a pdf page. However, it does fix my screen problem - and makes the User Guide much better formatted! Yeah FOP either overflows to the left of the frame or the bottom of the page, which is worse? I'm happy to change this if you want to open a bug about it. > > > ERROR MESSAGES: > > Also, when building, I see lots of these errors/warnings: > > Invalid property value encountered in keep-together.within-column="": org.apache.fop.fo.expr.PropertyException: file:/home/norman/Publican/Publican-v3.2.0/Users_Guide/build/en-US/xml/Users_Guide.fo:3629:48: No conversion defined ; property:'keep-together.within-column' (See position 3629:421) > > > Also in my thread mentioned above, I "resolved" this by editing line 405 of pdf.xsl, which is part of the attribute set for example.properties. The line needs a value adding between "><" - from this: > > > > To this: > > auto Again, happy to change this if you open a bug :) Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jfearn at redhat.com Wed Aug 21 04:03:22 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 21 Aug 2013 14:03:22 +1000 Subject: [publican-list] Another foible with Publican 3.2.0 In-Reply-To: <52139A50.3070608@dunbar-it.co.uk> References: <52139A50.3070608@dunbar-it.co.uk> Message-ID: <52143C0A.6040201@redhat.com> On 08/21/2013 02:33 AM, Norman Dunbar wrote: > Evening all, > > I've found something else in Publican 3.2 that affects one of my books. I haven't noticed this before, so it might not be related to 3.2 itself. > > I have a page, A4 sized, which has a on it with a number of s. If a s has an or and those particular lists are at the bottom of a page, then when rendered to pdf, using fop, the ordered list renders all over the footer details at the bottom of the page. > > I also see pages where the actual is rendered on the footer area as well. These steps have an rather than an ordered one. > > Pages where the reaches the bottom of the page, and which have simple s do not obliterate the footer, it only appears to be where lists are involved. > > It also seems to only occur on those pages where the entire page is one or more s from a > > The following should demonstrate the problem: > > $ publican create --type=article --name=steps --version="1.0-0" > > $ cd steps > > $ vi en-US/steps.xml, the following is what the stuff between the
tags looks like on saving: > >
> > > > >
> > > I have added the second include line, and removed the other test cruft! > > Create article.xml as follows: > > > > >
> > How Procedure Steps Will Obliterate PDF Page Footer > > > > > > > > > > >
> > > And finally, create onestep.xml as follows: > > > > > > > This is a list item. > This is a list item. > This is a list item. > This is a list item. > This is a list item. > This is a list item. > This is a list item. > > > > > $ publican build -langs=en-US --formats=pdf > > > When rendered as pdf, using fop, the first page of the article is fine, the steps stop just above the footer area's horizontal rule. In my pdf I see step 2 on page one, has two items from the list, which then continues on page 2. > > One page two, however, the list items are rendered all down the page to the actual paper edge. Step 8 has 3 items below the horizontal rule and the beginning of step 9 is rendered partly off the page. We had a lot of problems with rendering steps and sub-steps. It has something to do with the way FOP allocates rendering space to blocks and how it'd cant reallocate a parent blocks space when the child node flows over a greater space than expected. We never worked out how to fix this. If this works with the upstream XSL and is broken in Publican, then it's probably something we can fix, but if it's broken with the upstream XSL then it's unlikely we can resolve it. > I have to use fop for pdf rendering as I have indexes in my books etc and the wkhtmltopdf utility renders the page numbers as sections as if it was a normal html page. An index or a table of contents? It's standard to use the same page numbering for indexes as the rest of the book. WE could probably workout how to change the TOC to use Roman numerals. i'd just want to get our version online with upstream and that's a bit of effort. Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jfearn at redhat.com Wed Aug 21 05:07:53 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 21 Aug 2013 15:07:53 +1000 Subject: [publican-list] Publican 2.3 - not using files in Common_Content In-Reply-To: <5213A1D3.1060403@dunbar-it.co.uk> References: <5213A1D3.1060403@dunbar-it.co.uk> Message-ID: <52144B29.20001@redhat.com> Hi Norm, On 08/21/2013 03:05 AM, Norman Dunbar wrote: > Evening all, > > Publican 2.3 on Linux Mint 13 KDE. > > I build the latest version from source and followed the CPAN instructions to get the system built and the dependencies installed. My onely deviation from the README was the final stage, installing, where I had to run this command: FWIW the CPAN install is very rare, so you are a bit of a guinea pig here ... thanks :) > $ sudo ./Build install > Fixed for next commit. > I can see the default brands and stuff in /usr/share/publican but when I attempt to use a brand that I have installed there, it barfs saying it cannot find the brand. > > However, it is not looking in /usr/share/publican/Common_Content for the brands, it is looking in the area where I build the code - in my home directory in : > > /home/norman/Publican/Publican-v3.2.0/blib/datadir/Common_Content > > When I reinstall a brand into the above location (--path) then my builds manage to pick up the correct files. I'm now puzzled as to what exactly the install did (publican is /usr/local/bin/publican) and all the support files etc appear to have been copied to /usr/share/publican as normal (which didn't exist beforehand). I'd really need a full log of the entire process to have a real crack at solving this. It's possible there is something funky going on with the Config. Publican uses Module::Build::ConfigData to track where things are installed, it's possible there is some memory state hanging around between install and building a book. $ perl -e 'use Publican::ConfigData; print Publican::ConfigData->config('datadir'), "\n";' /usr/share/publican The Module::Build::ConfigData module has some magic to convert to CWD when building, so it could be a bug or feature of that module or how we are using it. > I've looked in the User Guide and it does mention the common_content option in publican.cfg and also states that the default is already set to /usr/share/publican/Common_Content, but it's not seemingly picking up the default for me. > > Not only that, it's ignores the setting even when explicitly defined in publican.cfg: Can you open a bug with a link to the section? The doc is way out of date, common_config & common_content are command line options and won't get used from the publican.cfg. > $ cat publican.cfg > > xml_lang: en-US > type: book > brand: jms > tmp_dir: build_tmp > debug: 1 > common_content: /usr/share/publican/Common_Content > > > $ publican build --langs=en-US formats=pdf > > ... > Beginning work on en-US > DTD Validation OK > Starting pdf > Using XML::LibXSLT on /home/norman/Publican/Publican-v3.2.0/blib/datadir/xsl/pdf.xsl > ... > > It's not picking up the pdf.xsl from /usr/share/publican/xsl. > > > If I add the common_config option to /usr/share/publican, it does pick up the global files rather than the local ones. > > It seems that common_config is accepted while common_content is ignored? Neither should work in the cfg file, they are both command line options. Unless you override them on the command line: common_config = Publican::ConfigData->config('datadir') common_content = Publican::ConfigData->config('datadir') . '/Common_Content' Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From Norman at dunbar-it.co.uk Wed Aug 21 10:18:15 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Wed, 21 Aug 2013 11:18:15 +0100 Subject: [publican-list] Publican 2.3 - not using files in Common_Content In-Reply-To: <52144B29.20001@redhat.com> References: <5213A1D3.1060403@dunbar-it.co.uk> <52144B29.20001@redhat.com> Message-ID: <521493E7.3090905@dunbar-it.co.uk> Morning Jeff, On 21/08/13 06:07, Jeff Fearn wrote: > FWIW the CPAN install is very rare, so you are a bit of a guinea pig > here ... thanks :) > >> $ sudo ./Build install >> > Fixed for next commit. Thanks! > I'd really need a full log of the entire process to have a real crack at > solving this. It's possible there is something funky going on with the > Config. I've created a bug for this, as requested, and there's a full log on that of the build process from creating the book to building it. I turned debug on in the config to get as much output as possible, but I doubt it will be helpful. Is there some way to get more that what is displayed on screen for a build? I looked around but couldn't find anything. > Publican uses Module::Build::ConfigData to track where things are > installed, it's possible there is some memory state hanging around > between install and building a book. > > $ perl -e 'use Publican::ConfigData; print > Publican::ConfigData->config('datadir'), "\n";' > /usr/share/publican Running that command gives: /home/norman/Publican/Publican-v3.2.0/blib/datadir > Can you open a bug with a link to the section? The doc is way out of > date, common_config & common_content are command line options and won't > get used from the publican.cfg. https://bugzilla.redhat.com/show_bug.cgi?id=999427 > Unless you override them on the command line: > > common_config = Publican::ConfigData->config('datadir') > common_content = Publican::ConfigData->config('datadir') . > '/Common_Content' That seems to be wroking but using my locally installed files rather than the ones that "sudo ./Build install" created in /usr/share/publican - none of which existed prior to the command to install Publican being run. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Wed Aug 21 10:30:48 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Wed, 21 Aug 2013 11:30:48 +0100 Subject: [publican-list] Another foible with Publican 3.2.0 In-Reply-To: <52143C0A.6040201@redhat.com> References: <52139A50.3070608@dunbar-it.co.uk> <52143C0A.6040201@redhat.com> Message-ID: <521496D8.9000505@dunbar-it.co.uk> Morning Jeff, On 21/08/13 05:03, Jeff Fearn wrote: > > We had a lot of problems with rendering steps and sub-steps. It has > something to do with the way FOP allocates rendering space to blocks and > how it'd cant reallocate a parent blocks space when the child node flows > over a greater space than expected. We never worked out how to fix this. > > If this works with the upstream XSL and is broken in Publican, then it's > probably something we can fix, but if it's broken with the upstream XSL > then it's unlikely we can resolve it. I shall get hold of the latest Docbook xsl and try it out and see what happens. I'll get back to you on this one. > >> I have to use fop for pdf rendering as I have indexes in my books etc >> and the wkhtmltopdf utility renders the page numbers as sections as if >> it was a normal html page. > > An index or a table of contents? It's standard to use the same page > numbering for indexes as the rest of the book. WE could probably workout > how to change the TOC to use Roman numerals. i'd just want to get our > version online with upstream and that's a bit of effort. I have a TOC at the start of my books, containing the part/chapter/section titles and a page number plus an index (or a number of indexes) at the back of the books with indexentry and page numbers. The TOC renders fine with fop, as does the index. With wkhtmltopdf, instead of something like the following: ... N Normalisation 15,36 Norman Dunbar 10,23-25,34 O OpenSuse 2 Oracle 31,35-37 ... Wkhtmltopdf replaces all the page numbers above with links to the section/page/chapter titles, as per the TOC. There are no actual page numbers in a wkhtmltopdf index. This is understandable, of course, if the document is being built from HTML "pages", then the concept fo an A4 page is lost plus, HTML docs use tags to create links and these don't tend to have actual page numbers, but some form of underlined text (or whatever the CSS to render an tag is of course!) so the final pdf looks remarkably like a pdf version of a web page, not as a book. :-( Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Wed Aug 21 11:08:13 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Wed, 21 Aug 2013 12:08:13 +0100 Subject: [publican-list] Another foible with Publican 3.2.0 In-Reply-To: <52143C0A.6040201@redhat.com> References: <52139A50.3070608@dunbar-it.co.uk> <52143C0A.6040201@redhat.com> Message-ID: <52149F9D.1050907@dunbar-it.co.uk> Hi Jeff, as promised, I tried with raw Docbook xsl, as follows: $ sudo -i $ vi /usr/share/publican/xsl/pdf2.xsl $ exit $ publican build --formats pdf2 This is how you advised me to do a test with the upstream xsl some time back. I assume it's fine here as well? That builds perfectly. It defaulted to US Letter sized stationery for the pages and the various steps rendered perfectly with nothing running off the bottom of the page or over the footer's horizontal rule. I added the following parameter, in case it's A4 that causes it: This time, when rendered, the page(s) that have nothing but steps on them have a line of text very very close - within half a millimetre, maybe a single pixel - to the horizontal rule for the footer. The same occurs with A5 page sizes too, the steps get extremely close to the horizontal rule, but don;t quite cross it. When on US Letter page size, there's a gap between the step's final listitem on the page, and the horizontal rule that looks to be equal to the distance between one step and the next - 2em I think. Then I got a little silly and changed the paper size to A6, which is tiny. It all went belly up and the step listitems, on pages consisting only of step content, obliterated the footers again. So, the good news? It looks like the problem is paper size based and affects upstream as well, just not quite as badly as it affects Publican. HTH Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Wed Aug 21 15:51:04 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Wed, 21 Aug 2013 16:51:04 +0100 Subject: [publican-list] Revision numbers, Screen output and error messages in Publican 3.2.0 In-Reply-To: <521438D5.3090108@redhat.com> References: <52137A63.7010303@dunbar-it.co.uk> <521438D5.3090108@redhat.com> Message-ID: <5214E1E8.2020109@dunbar-it.co.uk> Afternoon Jeff, On 21/08/13 04:49, Jeff Fearn wrote: > REVISION NUMBERS: > This is "working as intended" however unless you are building RPMs for > your books it's not actually relevant. Please open a bug requesting the > ability to allow oldest to newest order in the revision history. Bug opened, well RFC, low priority. https://bugzilla.redhat.com/show_bug.cgi?id=999578 Thanks. >> SCREEN OUTPUT: > Yeah FOP either overflows to the left of the frame or the bottom of the > page, which is worse? > > I'm happy to change this if you want to open a bug about it. https://bugzilla.redhat.com/show_bug.cgi?id=999581 raised for this matter. Thanks. >> ERROR MESSAGES: >> >> >> To this: >> >> auto > > Again, happy to change this if you open a bug :) https://bugzilla.redhat.com/show_bug.cgi?id=999586 raised for the missing parameter in example.properties. Thanks a lot Jeff, I do appreciate all the hard work you and your colleagues do for us users. Cheers, Norm. PS. Nice to see my own contribution making it to the Users' Guide! ;-) -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 From Norman at dunbar-it.co.uk Fri Aug 23 15:16:05 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Fri, 23 Aug 2013 16:16:05 +0100 Subject: [publican-list] Bugs in Users Guide for Publican 3.2 Message-ID: <52177CB5.1000905@dunbar-it.co.uk> Afternoon all, I found a few bugs and foibles in the Users Guide for publican 3.2. I've logged a bug on the matter: https://bugzilla.redhat.com/show_bug.cgi?id=1000534 However, in the spirit of being slightly helpful, I've fixed the ones I can and attached the source xml files to the bug report. Sadly, I was unable to fix all of them. HTH Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767