From pelican at simsassociates.co.uk Sun Mar 3 22:44:22 2013 From: pelican at simsassociates.co.uk (pelican at simsassociates.co.uk) Date: Sun, 3 Mar 2013 22:44:22 -0000 Subject: [publican-list] How do I force a page break? Message-ID: <2A518C7EE10344D1BA8D10F06647FF64@SA07> I have a sample code listing in my DOCBOOK document. When built, the code listing starts near the end of a page, and continues on the next page. I'd really like the listing to appear "unbroken", all on one page, not split across two pages. Is it possible to force a page-break just before the code listing so that it appears all together, unbroken, at the top of the next page? Thanks, Oliver Sims -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at christensenplace.us Sun Mar 3 23:08:03 2013 From: eric at christensenplace.us (Eric H. Christensen) Date: Sun, 3 Mar 2013 18:08:03 -0500 Subject: [publican-list] How do I force a page break? In-Reply-To: <2A518C7EE10344D1BA8D10F06647FF64@SA07> References: <2A518C7EE10344D1BA8D10F06647FF64@SA07> Message-ID: <20130303230803.GA5560@localhost.localdomain> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, Mar 03, 2013 at 10:44:22PM -0000, pelican at simsassociates.co.uk wrote: > Is it possible to force a page-break just before the code listing so that it > appears all together, unbroken, at the top of the next page? This may be helpful: http://www.sagehill.net/docbookxsl/PageBreaking.html - -Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQGcBAEBCgAGBQJRM9fQAAoJEB/kgVGp2CYvbb4L/1h46sJvPC42M6MOJkTXpxtK hCXskJyEv9yteWBBG76Uo9q05hVJSQFWyZNSlHtxnBjhy5kiKLxrcl/1xzIpyK/Q 3P4XXT6yxehwG+nP7tB5+hZJe22wmbW4AXVRZ0pWxJwUNdZSTODBrIimgvFj60SQ tOU4WJauqtRdm9SbnIxJ/YEkbEO9/MkMAOTbi9agr5NaFFd09YfzPCikP2HXCbDu uAEo8yZAPIwQJ4/Qb2OiZg7+pEcur+45fCj7diUCudF1VVgKPHJRrPAoiHO1+WT5 0/cwRKM4HwpkHwxuoiSoTojaJCwtfV0elBqkVvlw8Qh0Ih8jDnagL4XgsvU2eTd3 bVU+DcMqenDDM/dWb0k45Qno+h3lh3r9b2T9vbYVpfmvO7h837ilABRq/V1JtNBi ZomIK7gyz8RyLCpOLalbYruXk1OGS7h/2KQyNJ74zu0mOPIF6qWqkX0jJT0nlcK8 dPjatSoG3pE4AwnBa27VadgdAFkxr6d5UZtTXKMF3Q== =EE+I -----END PGP SIGNATURE----- From jfearn at redhat.com Tue Mar 5 02:28:15 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 05 Mar 2013 12:28:15 +1000 Subject: [publican-list] How do I force a page break? In-Reply-To: <2A518C7EE10344D1BA8D10F06647FF64@SA07> References: <2A518C7EE10344D1BA8D10F06647FF64@SA07> Message-ID: <5135583F.90102@redhat.com> On 03/04/2013 08:44 AM, pelican at simsassociates.co.uk wrote: > I have a sample code listing in my DOCBOOK document. When built, the code > listing starts near the end of a page, and continues on the next page. I'd > really like the listing to appear "unbroken", all on one page, not split > across two pages. > > Is it possible to force a page-break just before the code listing so that it > appears all together, unbroken, at the top of the next page? If you are using wkhtmltopdf, you can set the role attribute in almost any tag to 'pdf-break' and it will force a page break before that object in the PDF. e.g. ... It's not tested a lot so you might have to get creative. Also, someone should document all the stuff in my head! 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 Mar 8 04:26:39 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 08 Mar 2013 04:26:39 +0000 Subject: [publican-list] [Bug 708278] RFE: support translation memory In-Reply-To: References: Message-ID: Product: Publican https://bugzilla.redhat.com/show_bug.cgi?id=708278 Ruediger Landmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Flags|needinfo?(r.landmann at redhat | |.com) | Last Closed| |2013-03-07 23:26:39 --- Comment #7 from Ruediger Landmann --- (In reply to comment #6) > Are you are asking for Publican to act as a translation memory system? Only in an extremely limited sense. However, I take the point that it would be more advantageous to look to an external TMS to connect to. Closing for further research. -- 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=jpwTvmKq0M&a=cc_unsubscribe From bugzilla at redhat.com Fri Mar 8 05:31:15 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 08 Mar 2013 05:31:15 +0000 Subject: [publican-list] [Bug 902500] Publican-based books in GNOME Shell In-Reply-To: References: Message-ID: Product: Publican https://bugzilla.redhat.com/show_bug.cgi?id=902500 --- Comment #3 from Jeff Fearn --- Hi, it's highly unlikely this will get addressed by the Publican team. We'd be happy to take patches though. Note that you can use publican to build the HTML etc without using its packaging mechanism, so there is nothing stopping anyone with a minimal understanding of spec files from doing whatever they like with the output. e.g. pop something like this in to a specfile %build publican build --langs all --formats html --publish %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/share/help/ for lang in 'en-US' 'de-DE'; do olang=`sed -e 's/-/_/g'; install publish/$lang/Publican/3.1/html/Users_Guide $RPM_BUILD_ROOT/usr/share/help/$olang/Publican; done Untested, but you get the idea, if you aren't happy with the way it packages things just use publican like any other command line tool and forget it does some automated packaging. -- 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=LF3KL6iFnx&a=cc_unsubscribe From bugzilla at redhat.com Fri Mar 8 06:29:34 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 08 Mar 2013 06:29:34 +0000 Subject: [publican-list] [Bug 902500] Publican-based books in GNOME Shell In-Reply-To: References: Message-ID: Product: Publican https://bugzilla.redhat.com/show_bug.cgi?id=902500 --- Comment #4 from Pete Travis --- I have a spec file that does almost exactly that, and the Release Notes have been using a javascript snippet for a while that redirect the user the the appropriate documents. I'm writing something up on the process of using such a spec file to package our docs now, and can post a link in this ticket for the curious. A few highlights: - Localized files are in subdirectories - Desktop file is localized at build time. The actual action line cannot be localized, ie Exec or URI, but we can localize name and comment. I'm intrigued by the idea of documentation as a search provider. -- 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=oyr9hMCg2B&a=cc_unsubscribe From bugzilla at redhat.com Mon Mar 11 15:38:16 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 11 Mar 2013 15:38:16 +0000 Subject: [publican-list] [Bug 642127] [l10n] %changelog doesn't follow packaging Version Release format with publican 'package' action In-Reply-To: References: Message-ID: Product: Publican https://bugzilla.redhat.com/show_bug.cgi?id=642127 Frank Ch. Eigler changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fche at redhat.com --- Comment #19 from Frank Ch. Eigler --- Please note that this regresses publican's ability to render pre-existing documents, for example where the 'publish' facility and its putative naming requirements were never required. -- 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=0M55mTLsmU&a=cc_unsubscribe From hertzog at debian.org Tue Mar 12 15:29:42 2013 From: hertzog at debian.org (Raphael Hertzog) Date: Tue, 12 Mar 2013 16:29:42 +0100 Subject: [publican-list] Publican 3.1.2 and Publican 3.1.3, where are they? Message-ID: <20130312152942.GA6834@x230-buxy.home.ouaza.com> Hello, some of my bugs have been closed saying that they were fixed in Publican 3.1.2 and/or Publican 3.1.3 but none of those versions do appear on https://fedorahosted.org/releases/p/u/publican/ What's up? Cheers, -- Rapha?l Hertzog ? Debian Developer Get the Debian Administrator's Handbook: ? http://debian-handbook.info/get/ From jfearn at redhat.com Wed Mar 13 00:02:03 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 13 Mar 2013 10:02:03 +1000 Subject: [publican-list] Publican 3.1.2 and Publican 3.1.3, where are they? In-Reply-To: <20130312152942.GA6834@x230-buxy.home.ouaza.com> References: <20130312152942.GA6834@x230-buxy.home.ouaza.com> Message-ID: <513FC1FB.5070805@redhat.com> On 03/13/2013 01:29 AM, Raphael Hertzog wrote: > Hello, > > some of my bugs have been closed saying that they were fixed in Publican > 3.1.2 and/or Publican 3.1.3 but none of those versions do appear on > https://fedorahosted.org/releases/p/u/publican/ > > What's up? The flames are burning :( Hope to have 3.1.4 up on the public site today. Sorry for the lack of communication but it's been hectic and my attention has been tightly focused :( FWIW the sources are in the git master branch and each release has it's own commit to bump the versions, but you are better off waiting for 3.1.4 IMO. Full horror story to follow. 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 Mar 13 05:46:54 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 13 Mar 2013 15:46:54 +1000 Subject: [publican-list] Publican 3.1.2 and Publican 3.1.3, where are they? In-Reply-To: <513FC1FB.5070805@redhat.com> References: <20130312152942.GA6834@x230-buxy.home.ouaza.com> <513FC1FB.5070805@redhat.com> Message-ID: <514012CE.7010200@redhat.com> On 03/13/2013 10:02 AM, Jeff Fearn wrote: > On 03/13/2013 01:29 AM, Raphael Hertzog wrote: >> Hello, >> >> some of my bugs have been closed saying that they were fixed in Publican >> 3.1.2 and/or Publican 3.1.3 but none of those versions do appear on >> https://fedorahosted.org/releases/p/u/publican/ >> >> What's up? > > The flames are burning :( > > Hope to have 3.1.4 up on the public site today. > > Sorry for the lack of communication but it's been hectic and my > attention has been tightly focused :( > > FWIW the sources are in the git master branch and each release has it's > own commit to bump the versions, but you are better off waiting for > 3.1.4 IMO. > > Full horror story to follow. > > Cheers, Jeff. > 3.1.5 will come put tomorrow. Code in devel branch ... that job picking up cans on the beech may have been a good career choice :/ 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 Mar 13 17:11:30 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Wed, 13 Mar 2013 17:11:30 +0000 Subject: [publican-list] Screen and Programlisting oddities in Publican 2.8 In-Reply-To: <5099378D.70608@dunbar-it.co.uk> References: <5099378D.70608@dunbar-it.co.uk> Message-ID: <5140B342.8080104@dunbar-it.co.uk> Evening all, re this problem. I've been delayed by my real job for a while, but I've had a few hours yesterday and today to take a better look. I can reproduce the fault with the pdf.xsl from Publican 2.3 and 2.8, so I suspect that problem is buried deep in the DocBook xsl and might not be a Publican fault after all. To recap, formatting this: MOVE.L $1000,D1 gets the long word at address $1000 MOVE.L $9000,D1 gets the long word at address $FFFF9000 Results in this: Line 1 is all of the following, unwrapped: MOVE.L $1000,D1 gets the long word at address $1000MOVE.L $9000,D1 gets the long Line 2 is all of the following: word at address $FFFF9000 Then, there is line 3, all of the rest: $1000MOVE.L $9000,D1 gets the long word at address I've done it that way in case Thunderbird wraps things strangely. There are two lines of program listing, but three lines of output. If I remove the comments from the source: MOVE.L $1000,D1 MOVE.L $9000,D1 Then it renders correctly. I have tried many lines of similar code and shortening the comments, but they all render correctly, Sigh! Not all program listings are affected, and there are also some elements that show the same corruption. This only affects PDF generation. HTML, epub and text etc, are all ok. I did try DBLatex, as advised elsewhere in this thread, and that is ok, but loses my muliti-layer indexes. :-( I can't upgrade to 3.x because it's not yet available on my distro (Linux Mint 13 based on Ubuntu) and I need to keep using fop to get my indexes correctly created and with multi-levels too. Irritating, I know. I tried building 3.0 a while back, but there are some dependency problems. :-( I'll keep looking for more clues as to what is going on, but I think some changes between the Docbook XSL in 2.3 and in 2.8 might have introduced the problem. If I render the document in 2.3 everything it's ok (but has other problems with brands) whereas in 2.8 it seems to have random problems. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 From gchamoul at redhat.com Wed Mar 13 19:51:40 2013 From: gchamoul at redhat.com (=?iso-8859-1?Q?Ga=EBl?= Chamoulaud) Date: Wed, 13 Mar 2013 20:51:40 +0100 Subject: [publican-list] Building Publican from source Message-ID: <20130313195140.GC3916@strider.cdg.redhat.com> Hi list, I am trying to build Publican from the source on my F18 laptop and I got this problem. When I type: $ perl ./Build.PL I get this: Checking Prerequisites... requires: ! XML::TreeBuilder (0) is installed, but we need version >= 4 build_requires: ! XML::TreeBuilder (0) is installed, but we need version >= 4 Therefore, I've already installed the perl-XML-TreeBuilder package from yum! => perl-XML-TreeBuilder-4.0-8.fc18.noarch Any Help would be appreciated ! :-) Best Regards, ~GC -- Ga?l Chamoulaud (strider) - RHCE EMEA Infrastructure Consultant - Red Hat Mobile: +33 6 70 41 49 90 GnuPG Key ID: 7F4B301 C75F 15C2 A7FD EBC3 7B2D CE41 0077 6A4B A7F4 B301 Freedom...Courage...Commitment...Accountability -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jfearn at redhat.com Wed Mar 13 23:18:58 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 14 Mar 2013 09:18:58 +1000 Subject: [publican-list] Building Publican from source In-Reply-To: <20130313195140.GC3916@strider.cdg.redhat.com> References: <20130313195140.GC3916@strider.cdg.redhat.com> Message-ID: <51410962.7090802@redhat.com> On 03/14/2013 05:51 AM, Ga?l Chamoulaud wrote: > Hi list, > > I am trying to build Publican from the source on my F18 laptop and I got > this problem. > > When I type: > $ perl ./Build.PL > > I get this: > Checking Prerequisites... > requires: > ! XML::TreeBuilder (0) is installed, but we need version >= 4 > build_requires: > ! XML::TreeBuilder (0) is installed, but we need version >= 4 > > Therefore, I've already installed the perl-XML-TreeBuilder package from yum! > > => perl-XML-TreeBuilder-4.0-8.fc18.noarch > > Any Help would be appreciated ! :-) > > Best Regards, ~GC > This is a recent thing, I'm not sure where it comes from, but if you ignore it and carry on everything works. Hopefully one day I'll have time to delve in deep and figure it out, but ATM I'm buried in more critical work :( 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 Mar 13 23:44:36 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 14 Mar 2013 09:44:36 +1000 Subject: [publican-list] Screen and Programlisting oddities in Publican 2.8 In-Reply-To: <5140B342.8080104@dunbar-it.co.uk> References: <5099378D.70608@dunbar-it.co.uk> <5140B342.8080104@dunbar-it.co.uk> Message-ID: <51410F64.9010603@redhat.com> On 03/14/2013 03:11 AM, Norman Dunbar wrote: > Evening all, > > re this problem. I've been delayed by my real job for a while, but I've > had a few hours yesterday and today to take a better look. > > I can reproduce the fault with the pdf.xsl from Publican 2.3 and 2.8, so > I suspect that problem is buried deep in the DocBook xsl and might not > be a Publican fault after all. > > To recap, formatting this: > > > MOVE.L $1000,D1 gets the long word at address $1000 > MOVE.L $9000,D1 gets the long word at address $FFFF9000 > > Results in this: > > Line 1 is all of the following, unwrapped: > > MOVE.L $1000,D1 gets the long word at address $1000MOVE.L $9000,D1 > gets the long > > Line 2 is all of the following: > > word at address $FFFF9000 > > Then, there is line 3, all of the rest: > > $1000MOVE.L $9000,D1 gets the long word at address > > I've done it that way in case Thunderbird wraps things strangely. > > > There are two lines of program listing, but three lines of output. If I > remove the comments from the source: > > > MOVE.L $1000,D1 > MOVE.L $9000,D1 > > > Then it renders correctly. > > I have tried many lines of similar code and shortening the comments, but > they all render correctly, Sigh! > > > Not all program listings are affected, and there are also some > elements that show the same corruption. This only affects PDF > generation. HTML, epub and text etc, are all ok. > > I did try DBLatex, as advised elsewhere in this thread, and that is ok, > but loses my muliti-layer indexes. :-( > > > I can't upgrade to 3.x because it's not yet available on my distro > (Linux Mint 13 based on Ubuntu) and I need to keep using fop to get my > indexes correctly created and with multi-levels too. Irritating, I know. > > I tried building 3.0 a while back, but there are some dependency > problems. :-( > > I'll keep looking for more clues as to what is going on, but I think > some changes between the Docbook XSL in 2.3 and in 2.8 might have > introduced the problem. > > If I render the document in 2.3 everything it's ok (but has other > problems with brands) whereas in 2.8 it seems to have random problems. Hi Norman, plugged your programlisting in to the Publican Users Guide, built on P3 with FOP, renders as expected. Set: Also renders as expected. What version of the docbook xsl are you using? Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From gchamoul at redhat.com Thu Mar 14 11:09:55 2013 From: gchamoul at redhat.com (=?iso-8859-1?Q?Ga=EBl?= Chamoulaud) Date: Thu, 14 Mar 2013 12:09:55 +0100 Subject: [publican-list] Building Publican from source In-Reply-To: <51410962.7090802@redhat.com> References: <20130313195140.GC3916@strider.cdg.redhat.com> <51410962.7090802@redhat.com> Message-ID: <20130314110955.GA25446@strider.cdg.redhat.com> On 14/Mar - 09:18, Jeff Fearn wrote: > On 03/14/2013 05:51 AM, Ga?l Chamoulaud wrote: > >Hi list, > > > > I am trying to build Publican from the source on my F18 laptop and I got > > this problem. > > > > When I type: > > $ perl ./Build.PL > > > > I get this: > > Checking Prerequisites... > > requires: > > ! XML::TreeBuilder (0) is installed, but we need version >= 4 > > build_requires: > > ! XML::TreeBuilder (0) is installed, but we need version >= 4 > > > > Therefore, I've already installed the perl-XML-TreeBuilder package from yum! > > > > => perl-XML-TreeBuilder-4.0-8.fc18.noarch > > > > Any Help would be appreciated ! :-) > > > >Best Regards, ~GC > > > > This is a recent thing, I'm not sure where it comes from, but if you > ignore it and carry on everything works. > > Hopefully one day I'll have time to delve in deep and figure it out, > but ATM I'm buried in more critical work :( > Thanks Jeff for your response ! Best Regards, ~GC -- Ga?l Chamoulaud (strider) - RHCE EMEA Infrastructure Consultant - Red Hat Mobile: +33 6 70 41 49 90 GnuPG Key ID: 7F4B301 C75F 15C2 A7FD EBC3 7B2D CE41 0077 6A4B A7F4 B301 Freedom...Courage...Commitment...Accountability -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From Norman at dunbar-it.co.uk Thu Mar 14 11:40:40 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Thu, 14 Mar 2013 11:40:40 +0000 Subject: [publican-list] Screen and Programlisting oddities in Publican 2.8 In-Reply-To: <51410F64.9010603@redhat.com> References: <5099378D.70608@dunbar-it.co.uk> <5140B342.8080104@dunbar-it.co.uk> <51410F64.9010603@redhat.com> Message-ID: <5141B738.8080901@dunbar-it.co.uk> Hi Jeff, On 13/03/13 23:44, Jeff Fearn wrote: > Hi Norman, plugged your programlisting in to the Publican Users Guide, > built on P3 with FOP, renders as expected. That's good news. > > Set: > > Hmm, it's Motorola MC680xx language, but not to worry. I don't use the "language" attribute. > Also renders as expected. > > What version of the docbook xsl are you using? In both cases, I'm using the version that came with my distro (unless Publican installs it's own?) So on Publican 2.1 running on Scientific Linux 6 (RHEL 6) I have 1.75.2 according to "yum". (It appears that where I said "2.3" previoulsy, I meant "2.1" - sorry.) For 2.8 running in Linux Mint 13 KDE, I have 1.76.1. (According to apt-cache showpkg) I'm trawling through the release notes on the Docbook web site. It seems I'm a few versions behind. What version did you use to correctly render in P3 please? Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 From Norman at dunbar-it.co.uk Thu Mar 14 12:18:45 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Thu, 14 Mar 2013 12:18:45 +0000 Subject: [publican-list] Screen and Programlisting oddities in Publican 2.8 In-Reply-To: <5141B738.8080901@dunbar-it.co.uk> References: <5099378D.70608@dunbar-it.co.uk> <5140B342.8080104@dunbar-it.co.uk> <51410F64.9010603@redhat.com> <5141B738.8080901@dunbar-it.co.uk> Message-ID: <5141C025.1020400@dunbar-it.co.uk> On 14/03/13 11:40, Norman Dunbar wrote: > I'm trawling through the release notes on the Docbook web site. It seems > I'm a few versions behind. > > What version did you use to correctly render in P3 please? Ok, saved my existing version and installed the very latest from Docbook itself. 1.78.0. No change here I'm afraid. This is weird! Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 From jfearn at redhat.com Thu Mar 14 23:47:35 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 15 Mar 2013 09:47:35 +1000 Subject: [publican-list] Screen and Programlisting oddities in Publican 2.8 In-Reply-To: <5141C025.1020400@dunbar-it.co.uk> References: <5099378D.70608@dunbar-it.co.uk> <5140B342.8080104@dunbar-it.co.uk> <51410F64.9010603@redhat.com> <5141B738.8080901@dunbar-it.co.uk> <5141C025.1020400@dunbar-it.co.uk> Message-ID: <51426197.3050404@redhat.com> On 03/14/2013 10:18 PM, Norman Dunbar wrote: > On 14/03/13 11:40, Norman Dunbar wrote: > >> I'm trawling through the release notes on the Docbook web site. It seems >> I'm a few versions behind. >> >> What version did you use to correctly render in P3 please? > > Ok, saved my existing version and installed the very latest from Docbook > itself. 1.78.0. No change here I'm afraid. I'm using docbook-style-xsl-1.77.1-3, I think anything > 1.77.1 should be fine. It's particularly odd since: $ diff -s publican/trunk/publican/datadir/xsl/pdf.xsl publican-git/publican/datadir/xsl/pdf.xsl Files publican/trunk/publican/datadir/xsl/pdf.xsl and publican-git/publican/datadir/xsl/pdf.xsl are identical That's comparing the old SVN repo to devel branch in the git repo. Can you compare the content between ./tmp/$lang/xml_tmp/$file and ./tmp/$lang/xml/$file The main difference between the two is that XmlClean is used to move files between xml_tmp and xml ... although I'd expect anything broken in that step to affect all outputs. You could try making a basic PDF XSL file and copying over content from pdf.xsl to see if anything changes. $ sudo gvim /usr/share/publican/xsl/pdf2.xsl $ publican build --formats pdf2 If the first run doesn't change anything then I'd suspect the XML getting munged or the behaviour is not publican specific. It would be extra odd if the XML is getting munged but only the PDF is being affected. 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 Fri Mar 15 14:25:38 2013 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Fri, 15 Mar 2013 14:25:38 +0000 Subject: [publican-list] Screen and Programlisting oddities in Publican 2.8 In-Reply-To: <51426197.3050404@redhat.com> References: <5099378D.70608@dunbar-it.co.uk> <5140B342.8080104@dunbar-it.co.uk> <51410F64.9010603@redhat.com> <5141B738.8080901@dunbar-it.co.uk> <5141C025.1020400@dunbar-it.co.uk> <51426197.3050404@redhat.com> Message-ID: <51432F62.2080303@dunbar-it.co.uk> Hi Jeff, On 14/03/13 23:47, Jeff Fearn wrote: > Can you compare the content between ./tmp/$lang/xml_tmp/$file and > ./tmp/$lang/xml/$file > > The main difference between the two is that XmlClean is used to move > files between xml_tmp and xml ... although I'd expect anything broken in > that step to affect all outputs. > You could try making a basic PDF XSL file and copying over content from > pdf.xsl to see if anything changes. > > $ sudo gvim /usr/share/publican/xsl/pdf2.xsl > > > > version='1.0' > xmlns="http://www.w3.org/TR/xhtml1/transitional" > > > href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl"/> > > > > > $ publican build --formats pdf2 Aha! The above has fixed it. pdf now renders correctly. I shall investigate what makes it stop working by adding bits from pdf.xsl to pdf2.xsl. 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. Also, I noticed a number of errors about an illegal value for "keep-together.within-column" in pdf.xsl as well. Near line 405, it looks like this: ... ... I changed mine to auto instead of leaving it blank. That stopped the errors and the build appears ok. Thanks for your help. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 From jfearn at redhat.com Mon Mar 18 06:39:03 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 18 Mar 2013 16:39:03 +1000 Subject: [publican-list] Publican 3.1.5 release Message-ID: <5146B687.8000300@redhat.com> Hi, Publican 3.1.5 is now released, since we got distracted between 3.1.0 and now I'm going to include the intermediate releases in this list. NOTE 1. Some of these are recent bugs and some are long standing bugs that have not been brought to our attention before. One includes a patch for an upstream module that system packagers will need to carry upstream [1]. NOTE 2. I had to rework the spec file for wkhtmltoipdf-qt and wkhtmltopdf to stop them interfering with the system Qt libraries. Rudi or I will post updated packages soon for people suffering from Qt packages (like Kate) blowing up. 3.1.1 Thu Feb 07 2013 - Fix web site CSS for admonitions breaking layout for books built on P3.0. BZ #908539 3.1.2 Tue Feb 19 2013 - Fix tests failing when publican not installed. BZ #908956 - Fix broken mr-IN/Conventions.po. BZ #908956 - Fix footnote link unclickable. BZ #909006 - Fix missing translations for common files. BZ #908976 - Fix using edition for version on cover pages. BZ #912180 - Fix nested entities causing XML::TreeBuilder to fail. BZ #912187 - Fix for cover pages causing page number overrun. BZ #912967 3.1.3 Fri Feb 22 2013 - Fix add_revision breaking XML parser. BZ #912985 - Stronger fix for cover pages causing page number overrun. BZ #912967 - Fix CSS for article front page subtitle. BZ #913016 3.1.4 Tue Mar 12 2013 - Fix entities in Book_Info braking build. BZ #917898 - add translations of "Revision History". BZ #918365 - Fix TOC title not translated in PDF. BZ #918365 - Fix translated strings with parameters. BZ #891166 - update translations - add it-IT translation of PUG via BZ #797515 3.1.5 Mon Mar 18 2013 - Fix translated PDF encode issue when build from packaged books. BZ #922618 https://fedorahosted.org/releases/p/u/publican/Publican-v3.1.5.tar.gz https://fedorahosted.org/releases/p/u/publican/publican.spec https://fedorahosted.org/releases/p/u/publican/publican-3.1.5-0.el6.src.rpm I promised a report on the 2013 tour of Hell, I[ve shortened it somewhat and hope it's sufficient. Up until 3.1.1 was released we had no problems building PDFs with wkhtmnltopdf. I'd built hundreds of PDFs with it, never a single issue with its stability. After releasing 3.1.1 we started to get massive failure rates in building PDFs, in excess of 80%. An assert was getting triggered that the page numbers exceeded the expected number of pages. The effect of this on RHEL was an order of magnitude greater than the effect on Fedora; on Fedora 17 we where getting 1-2% failure when building a book in batches of 100. i.e. building the same PDF calling wkhtmltopdf directly in the CLI in a for loop. After a great deal of poking around it became apparent that the event driven mechanism being used was creating sub-events that where completing after the main event and that the book was starting to print before the cover pages had finished loading. 3.1.2 contained a fix where we reduced the number of cover pages from 2 to 1. This seemed to have a significant affect on the ASSERT triggering. However the effect in production was still too high for production use. 3.1.3 contained a fix where we significantly reduced the size and complexity of the CSS being loaded in the cover page, and this combined with a single cover page has led to us not seeing an ASSERTS since making this change. Once 3.1.3 went live more people started building books and several issues that may have been detected much earlier where raised. Some of them were very serious and required immediate attention. Some other have probably been around for a long time but were also considered urgent. 3.1.4 contained those fixes. 3.1.5 has a fix for a UTF8 issue. All up it's been quite a difficult journey and I apologise to all those affected by this bumpy ride. I'm not sure how we can mitigate the PDF ASSET failure. It came completely out of the blue and we still have no idea what changed to start it triggering. We have collected a broad selection of documents to test. We will test all of these books every release, and will ensure the full test suite is run on every build. In the end, as much as we automate testing, a lot of these issues can only be picked up by people who know what things should look like actually looking at them, before we ship. Our automation will be based on this. We will build your books, we will host the output, but we will always need you to look at it and tell us if anything is wrong. This is particularly true for translated content, we just can't tell if it's right or wrong. I'd like to give a shout out to Rapha?l Hertzog who packages Publican for Debian and who gives me a lot of good feedback on how to make the packaging experience better. I really appreciate your time and efforts mate, I'll buy you a beer one day if we ever get to meet. Cheers, Jeff. 1: Bug 891166 appears to be a long standing bug where strings with parameters would not get translated. I had to patch Locale::Maketext::Gettext to convert between gettext and maketext formats. The patch probably isn't robust. I'll be opening an upstream bug to get it carried. Packagers need to determine if it's worth the risk carrying it in their distributions. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: gettexttomakettext.patch Type: text/x-patch Size: 648 bytes Desc: not available URL: From hertzog at debian.org Wed Mar 20 09:12:31 2013 From: hertzog at debian.org (Raphael Hertzog) Date: Wed, 20 Mar 2013 10:12:31 +0100 Subject: [publican-list] Publican 3.1.5 release In-Reply-To: <5146B687.8000300@redhat.com> References: <5146B687.8000300@redhat.com> Message-ID: <20130320091231.GA11539@x230-buxy.home.ouaza.com> Hi, On Mon, 18 Mar 2013, Jeff Fearn wrote: > Hi, Publican 3.1.5 is now released, since we got distracted between > 3.1.0 and now I'm going to include the intermediate releases in this > list. Unfortunately one of the changes in those release broke publican for me :-( runtime error: file /home/rhertzog/deb/pkg/build-area/publican-3.1.5/blib/datadir/xsl/xhtml-common.xsl line 2500 element call-template The called template 'id.attribute' was not found. This call-template appears in the "footnote" template in datadir/xsl/xhtml-common.xsl. The offending commit is: commit 9fd2533ede7db02ef69264645125b51fc32ed7d3 Author: Jeff Fearn Date: Fri Feb 8 15:53:42 2013 +1000 Fix footnote link unclicakable. BZ #909006. PDF back link still broken. I have docbook-xsl 1.76.1. Did the minimal version required change? Cheers, -- Rapha?l Hertzog ? Debian Developer Get the Debian Administrator's Handbook: ? http://debian-handbook.info/get/ From sgordon at redhat.com Wed Mar 20 11:46:14 2013 From: sgordon at redhat.com (Steve Gordon) Date: Wed, 20 Mar 2013 07:46:14 -0400 (EDT) Subject: [publican-list] Publican 3.1.5 release In-Reply-To: <20130320091231.GA11539@x230-buxy.home.ouaza.com> Message-ID: <1099172255.11514817.1363779974289.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Raphael Hertzog" > To: "Publican discussions" > Sent: Wednesday, March 20, 2013 5:12:31 AM > Subject: Re: [publican-list] Publican 3.1.5 release > > Hi, > > On Mon, 18 Mar 2013, Jeff Fearn wrote: > > Hi, Publican 3.1.5 is now released, since we got distracted between > > 3.1.0 and now I'm going to include the intermediate releases in > > this > > list. > > Unfortunately one of the changes in those release broke publican > for me :-( > > runtime error: file > /home/rhertzog/deb/pkg/build-area/publican-3.1.5/blib/datadir/xsl/xhtml-common.xsl > line 2500 element call-template > The called template 'id.attribute' was not found. > > This call-template appears in the "footnote" template in > datadir/xsl/xhtml-common.xsl. > > The offending commit is: > > commit 9fd2533ede7db02ef69264645125b51fc32ed7d3 > Author: Jeff Fearn > Date: Fri Feb 8 15:53:42 2013 +1000 > > Fix footnote link unclicakable. BZ #909006. PDF back link still > broken. > > I have docbook-xsl 1.76.1. Did the minimal version required change? In the RPM builds it now requires 1.77 or later. I ran into this as well because this version isn't actually available for F17 (it is for F18) so I had to build it. Steve From jfearn at redhat.com Wed Mar 20 22:59:53 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 21 Mar 2013 08:59:53 +1000 Subject: [publican-list] Publican 3.1.5 release In-Reply-To: <1099172255.11514817.1363779974289.JavaMail.root@redhat.com> References: <1099172255.11514817.1363779974289.JavaMail.root@redhat.com> Message-ID: <514A3F69.8070606@redhat.com> On 03/20/2013 09:46 PM, Steve Gordon wrote: > ----- Original Message ----- >> From: "Raphael Hertzog" >> To: "Publican discussions" >> Sent: Wednesday, March 20, 2013 5:12:31 AM >> Subject: Re: [publican-list] Publican 3.1.5 release >> >> Hi, >> >> On Mon, 18 Mar 2013, Jeff Fearn wrote: >>> Hi, Publican 3.1.5 is now released, since we got distracted between >>> 3.1.0 and now I'm going to include the intermediate releases in >>> this >>> list. >> >> Unfortunately one of the changes in those release broke publican >> for me :-( >> >> runtime error: file >> /home/rhertzog/deb/pkg/build-area/publican-3.1.5/blib/datadir/xsl/xhtml-common.xsl >> line 2500 element call-template >> The called template 'id.attribute' was not found. >> >> This call-template appears in the "footnote" template in >> datadir/xsl/xhtml-common.xsl. >> >> The offending commit is: >> >> commit 9fd2533ede7db02ef69264645125b51fc32ed7d3 >> Author: Jeff Fearn >> Date: Fri Feb 8 15:53:42 2013 +1000 >> >> Fix footnote link unclicakable. BZ #909006. PDF back link still >> broken. >> >> I have docbook-xsl 1.76.1. Did the minimal version required change? > > In the RPM builds it now requires 1.77 or later. I ran into this as well because this version isn't actually available for F17 (it is for F18) so I had to build it. This is correct ... maybe we need to start using Module::Install::External or something to track these things. Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jfearn at redhat.com Thu Mar 21 23:07:41 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 22 Mar 2013 09:07:41 +1000 Subject: [publican-list] QPaintDevice: Cannot destroy paint device that is being painted Message-ID: <514B92BD.5050405@redhat.com> Hi, this warning just started appearing for some larger books. It's due to the number of file handles open hitting the default limit. The number of files goes something like: coverpage file + toc file + main file + ((footer file + header file) * pages main file is paginated too)) On Linux you can run `ulimit -n` to get the current limit. So 1024 - 3 / 2 = 510.5 So assuming you have some file handles open for other things, at around 500 pages this will start happening with the default file handle limit. On some Linuxes you can run `ulimit -n 8192` to change the limit for the current shell. Handy for testing. To make this permanent: sudo vim /etc/security/limits.conf Then add these two lines: * soft nofile 8192 * hard nofile 8192 Save, and re-login for it to take effect. FYI for packagers, the Brew/Koji limits are set to 8192 so this will not affect packages building. Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jfearn at redhat.com Thu Mar 21 23:18:48 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 22 Mar 2013 09:18:48 +1000 Subject: [publican-list] QPaintDevice: Cannot destroy paint device that is being painted In-Reply-To: <514B92BD.5050405@redhat.com> References: <514B92BD.5050405@redhat.com> Message-ID: <514B9558.3010804@redhat.com> On 03/22/2013 09:07 AM, Jeff Fearn wrote: > Hi, this warning just started appearing for some larger books. It's due > to the number of file handles open hitting the default limit. > > The number of files goes something like: > > coverpage file + toc file + main file + ((footer file + header file) * > pages main file is paginated too)) > > On Linux you can run `ulimit -n` to get the current limit. > > So 1024 - 3 / 2 = 510.5 > > So assuming you have some file handles open for other things, at around > 500 pages this will start happening with the default file handle limit. > > On some Linuxes you can run `ulimit -n 8192` to change the limit for the > current shell. Handy for testing. > > To make this permanent: > > sudo vim /etc/security/limits.conf > > Then add these two lines: > > * soft nofile 8192 > * hard nofile 8192 > > Save, and re-login for it to take effect. > > FYI for packagers, the Brew/Koji limits are set to 8192 so this will not > affect packages building. Corrections, PDFs of less than ~4000 pages will build fine in brew/koji O_O Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0