From jpooton at videonextfederal.com Thu May 16 01:40:09 2013 From: jpooton at videonextfederal.com (James Pooton) Date: Wed, 15 May 2013 19:40:09 -0600 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 Message-ID: We're kicking the tires here with Publican 3.1.5, hoping to move our documentation set to Docbook. A couple head scratchers have come up -- any advice is welcome. :) In just starting with a plain book ala: # publican create --name New_Book and then building html and pdf via: # cd New_Book # publican build --formats=html,pdf --langs=en-US --publish When viewing the output, we see title page content (from Book_Info.xml) in the HTML output, however it's completely missing from PDF output. PDF's appear to be processed via html-pdf.xsl and then rendered to pdf via wkhtmltopdf. Is html-pdf.xsl incomplete currently, or are we overlooking something? The manual mentions title page output for PDF documents, so we're puzzled. Our other question is regarding entities. They are working fine when used within normal paragraph content, however when trying to use one within Book_Info.xml like: &PRODUCTVER; The build will fail with: Invalid format for version. Value (EMPTY) does not conform to constraint (^[0-9]) at /usr/bin/publican line 713. So apparently validation happens before substitution. Our intent would just be to abstract some of these items into a central entities file used by a collection of docs. Perhaps there is a better route to achieve this? Again, we're new to this, so any input is appreciated. Thanks, -- *James Pooton* videoNEXT Federal Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Thu May 16 02:16:03 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 16 May 2013 12:16:03 +1000 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: References: Message-ID: <51944163.3020200@redhat.com> On 05/16/2013 11:40 AM, James Pooton wrote: > We're kicking the tires here with Publican 3.1.5, hoping to move our > documentation set to Docbook. A couple head scratchers have come up -- any > advice is welcome. :) > > In just starting with a plain book ala: > > # publican create --name New_Book > > and then building html and pdf via: > > # cd New_Book > # publican build --formats=html,pdf --langs=en-US --publish > > When viewing the output, we see title page content (from Book_Info.xml) in > the HTML output, however it's completely missing from PDF output. PDF's > appear to be processed via html-pdf.xsl and then rendered to pdf via > wkhtmltopdf. Is html-pdf.xsl incomplete currently, or are we overlooking > something? The manual mentions title page output for PDF documents, so > we're puzzled Where did you get wkhtmltopdf? The version that ships in Fedora for example is linked against an unpatched QT and doesn't have the cover page functionality. I will harass Rudi to get some FC18 packages built with the useful versions. > Our other question is regarding entities. They are working fine when used > within normal paragraph content, however when trying to use one within > Book_Info.xml like: > > &PRODUCTVER; > > The build will fail with: > > Invalid format for version. Value (EMPTY) does not conform to constraint > (^[0-9]) at /usr/bin/publican line 713. > > So apparently validation happens before substitution. Our intent would > just be to abstract some of these items into a central entities file used > by a collection of docs. Perhaps there is a better route to achieve this? Are you specifying to the ent file in the Book_Info.xml file? If not you could give that a try. Not sure we ever tested with You can set 'version' in publican.cfg and it won't use the Info file for this. > Again, we're new to this, so any input is appreciated. Welcome to the mad house :) 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 May 16 02:21:12 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 16 May 2013 12:21:12 +1000 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: <51944163.3020200@redhat.com> References: <51944163.3020200@redhat.com> Message-ID: <51944298.5050009@redhat.com> On 05/16/2013 12:16 PM, Jeff Fearn wrote: > On 05/16/2013 11:40 AM, James Pooton wrote: >> We're kicking the tires here with Publican 3.1.5, hoping to move our >> documentation set to Docbook. A couple head scratchers have come up -- any >> advice is welcome. :) >> >> In just starting with a plain book ala: >> >> # publican create --name New_Book >> >> and then building html and pdf via: >> >> # cd New_Book >> # publican build --formats=html,pdf --langs=en-US --publish >> >> When viewing the output, we see title page content (from Book_Info.xml) in >> the HTML output, however it's completely missing from PDF output. PDF's >> appear to be processed via html-pdf.xsl and then rendered to pdf via >> wkhtmltopdf. Is html-pdf.xsl incomplete currently, or are we overlooking >> something? The manual mentions title page output for PDF documents, so >> we're puzzled > > Where did you get wkhtmltopdf? The version that ships in Fedora for example is linked against an unpatched QT and doesn't have the cover page functionality. > > I will harass Rudi to get some FC18 packages built with the useful versions. > >> Our other question is regarding entities. They are working fine when used >> within normal paragraph content, however when trying to use one within >> Book_Info.xml like: >> >> &PRODUCTVER; >> >> The build will fail with: >> >> Invalid format for version. Value (EMPTY) does not conform to constraint >> (^[0-9]) at /usr/bin/publican line 713. >> >> So apparently validation happens before substitution. Our intent would >> just be to abstract some of these items into a central entities file used >> by a collection of docs. Perhaps there is a better route to achieve this? > > Are you specifying to the ent file in the Book_Info.xml file? If not you could give that a try. Not sure we ever tested with ... with entities in these tags. > You can set 'version' in publican.cfg and it won't use the Info file for this. > >> Again, we're new to this, so any input is appreciated. > > Welcome to the mad house :) > > Cheers, Jeff. > > -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jpooton at videonextfederal.com Thu May 16 17:43:02 2013 From: jpooton at videonextfederal.com (James Pooton) Date: Thu, 16 May 2013 11:43:02 -0600 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 Message-ID: Sorry, looks like I was on digest mode here... > Where did you get wkhtmltopdf? The version that ships in Fedora for example is linked against an unpatched QT and doesn't have the cover page functionality. > > I will harass Rudi to get some FC18 packages built with the useful versions. We just started with a fresh FC18 virtual machine and yum installed Publican from the testing repo, so it looks like that's the issue. (It pulled in wkhtmltopdf-0.11.0-0.2.rc1.fc18.x86_64 from updates) I saw you had some patched FC15 packages posted on the wiki. After getting libtiff.so.3 in place, I was able to install your packages and PDF output is different. However, now there is a blank "title page" on the PDF followed by the Preface and content. So I assume there is some hiccup in using the FC15 packages. If there is a forthcoming patched FC18 version coming, we'll just hold tight. Otherwise feel free to point me in the direction of any information on the patch, and we can try building. > Are you specifying to the ent file in the Book_Info.xml file? If not you could give that a try. Not sure we ever tested with entities in these tags. For testing purposes we were just adding the entity to the default entity file Publican created for the book. (videoNEXT_Template.ent in our case) which appears to get called in via: %BOOK_ENTITIES; ]> In videoNEXT_Template.ent we just added: and tried using it in Book_Info.xml via: &PRODUCTVER; We also tried directly setting the entity in Book_Info.xml (not that that would help us in the end), but the result was the same. > You can set 'version' in publican.cfg and it won't use the Info file for this. We actually tried that route as well. For some reason it picked up 'version' from publican.cfg and used it in creating the publish path, however the value in Book_Info.xml was still used on the HTML title page. Thanks for your help! -- James Pooton videoNEXT Federal Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpooton at videonextfederal.com Thu May 16 21:53:48 2013 From: jpooton at videonextfederal.com (James Pooton) Date: Thu, 16 May 2013 15:53:48 -0600 Subject: [publican-list] Branding not applied when using --embedtoc with Publican 3.1.5 Message-ID: Hello again... Odd one here. For some reason adding --embedtoc to a Publican build command seems to remove all brand styling from the output. For example: $ publican create --name Test_Book $ cd Test_Book $ publican build --publish --formats=html --langs=en-US --embedtoc Results in HTML output that is unstyled. ("common" brand css and images missing) Then... $ publican clean $ publican build --publish --formats=html --langs=en-US Results in HTML output that is properly styled with "common" css and images. I'm assuming this isn't normal behavior, as --embedtoc appears to be required for building out a Publican Web site, but results in a broken layout due to 404s. Any thoughts? Thanks! -- James Pooton videoNEXT Federal Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredsmith at jaredsmith.net Thu May 16 22:12:55 2013 From: jaredsmith at jaredsmith.net (Jared Smith) Date: Thu, 16 May 2013 18:12:55 -0400 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: <51944163.3020200@redhat.com> References: <51944163.3020200@redhat.com> Message-ID: On Wed, May 15, 2013 at 10:16 PM, Jeff Fearn wrote: > Where did you get wkhtmltopdf? The version that ships in Fedora for > example is linked against an unpatched QT and doesn't have the cover page > functionality. > > I will harass Rudi to get some FC18 packages built with the useful > versions. > That's good to know -- I've had several other people in the Fedora community ask about the missing title pages (and page breaks) when using wkhtmltopdf. This brings up another question -- for those of us who still prefer to use FOP instead of wkhtmltopdf, how do we get Publican to use fop instead? -- Jared Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Thu May 16 22:55:17 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 17 May 2013 08:55:17 +1000 Subject: [publican-list] Branding not applied when using --embedtoc with Publican 3.1.5 In-Reply-To: References: Message-ID: <519563D5.3070908@redhat.com> On 05/17/2013 07:53 AM, James Pooton wrote: > Hello again... > > Odd one here. For some reason adding --embedtoc to a Publican build > command seems to remove all brand styling from the output. For example: > > $ publican create --name Test_Book > $ cd Test_Book > $ publican build --publish --formats=html --langs=en-US --embedtoc > > Results in HTML output that is unstyled. ("common" brand css and images > missing) > Then... > > $ publican clean > $ publican build --publish --formats=html --langs=en-US > > Results in HTML output that is properly styled with "common" css and images. > > I'm assuming this isn't normal behavior, as --embedtoc appears to be > required for building out a Publican Web site, but results in a broken > layout due to 404s. Any thoughts? --embedtoc basically means "build this to use in a publican web site". The website contains the missing content. It's done this way so that you can change the style on a web site without having to rebuild every book or replace a mass of files. http://jfearn.fedorapeople.org/en-US/Publican/3.0/html/Users_Guide/sect-Users_Guide-Website.html hmm looks like someone hasn't updated the PUG on my site to 3.1 ... not sure I can blame Rudi for this one :} 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 May 16 23:16:47 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 17 May 2013 09:16:47 +1000 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: References: Message-ID: <519568DF.7020902@redhat.com> On 05/17/2013 03:43 AM, James Pooton wrote: > Sorry, looks like I was on digest mode here... > >> Where did you get wkhtmltopdf? The version that ships in Fedora for > example is linked against an unpatched QT and doesn't have the cover page > functionality. >> >> I will harass Rudi to get some FC18 packages built with the useful > versions. > > We just started with a fresh FC18 virtual machine and yum installed > Publican from the testing repo, so it looks like that's the issue. (It > pulled in wkhtmltopdf-0.11.0-0.2.rc1.fc18.x86_64 from updates) I saw you > had some patched FC15 packages posted on the wiki. After getting > libtiff.so.3 in place, I was able to install your packages and PDF output > is different. However, now there is a blank "title page" on the PDF > followed by the Preface and content. So I assume there is some hiccup in > using the FC15 packages. > > If there is a forthcoming patched FC18 version coming, we'll just hold > tight. Otherwise feel free to point me in the direction of any information > on the patch, and we can try building. I had to rework a lot of the packaging between the originals and the ones we are using now. It was breaking KDE and not at all a good citizen :) >> Are you specifying to the ent file in the Book_Info.xml file? If not you > could give that a try. Not sure we ever tested with entities in these tags. > > For testing purposes we were just adding the entity to the default entity > file Publican created for the book. (videoNEXT_Template.ent in our case) > which appears to get called in via: > > > %BOOK_ENTITIES; > ]> > > In videoNEXT_Template.ent we just added: > > > > and tried using it in Book_Info.xml via: > > &PRODUCTVER; > > We also tried directly setting the entity in Book_Info.xml (not that that > would help us in the end), but the result was the same. It looks like the module we use to fetch that from the XML isn't expanding entities. Can you open a bug about this? >> You can set 'version' in publican.cfg and it won't use the Info file for > this. > > We actually tried that route as well. For some reason it picked up > 'version' from publican.cfg and used it in creating the publish path, > however the value in Book_Info.xml was still used on the HTML title page. If you use ' &PRODUCTVER;' in the XML and set it in publican.cfg, then it should work. Limiting the number of places you need to change it to 2 ... which is not as good as 1, but better than 472. 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 May 16 23:27:54 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 17 May 2013 09:27:54 +1000 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: References: <51944163.3020200@redhat.com> Message-ID: <51956B7A.5020505@redhat.com> On 05/17/2013 08:12 AM, Jared Smith wrote: > On Wed, May 15, 2013 at 10:16 PM, Jeff Fearn wrote: > >> Where did you get wkhtmltopdf? The version that ships in Fedora for >> example is linked against an unpatched QT and doesn't have the cover page >> functionality. >> >> I will harass Rudi to get some FC18 packages built with the useful >> versions. >> > > That's good to know -- I've had several other people in the Fedora > community ask about the missing title pages (and page breaks) when using > wkhtmltopdf. > > This brings up another question -- for those of us who still prefer to use > FOP instead of wkhtmltopdf, how do we get Publican to use fop instead? Not in a nice way :( You could try: $ sudo rpm -e --nodeps wkhtmltopdf Yum will be annoying and complain about a missing dep all the time though :( Bug for nice way https://bugzilla.redhat.com/show_bug.cgi?id=953728 Cheers, Jeff. -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From jpooton at videonextfederal.com Fri May 17 01:08:07 2013 From: jpooton at videonextfederal.com (James Pooton) Date: Thu, 16 May 2013 19:08:07 -0600 Subject: [publican-list] Branding not applied when using --embedtoc with Publican 3.1.5 In-Reply-To: <519563D5.3070908@redhat.com> References: <519563D5.3070908@redhat.com> Message-ID: On Thu, May 16, 2013 at 4:55 PM, Jeff Fearn wrote: > > > --embedtoc basically means "build this to use in a publican web site". The > website contains the missing content. It's done this way so that you can > change the style on a web site without having to rebuild every book or > replace a mass of files. > > http://jfearn.fedorapeople.**org/en-US/Publican/3.0/html/** > Users_Guide/sect-Users_Guide-**Website.html > > That's actually the page I was working through. :) I guess my question is this. That doc states: "The Publican-generated home page is the localizable page to which visitors are directed by the site JavaScript and which **provides the style** for the website structure." So I created a home page article per the directions, adding "web_type: home" and "brand: videoNEXT" to its publican.cfg. However, when building it for install, instructions ask for the following: publican build --publish --formats html-single --embedtoc --langs all Which results in HTML without any brand/style content applied, apparently because of the --embedtoc.(?) So installing this into the website doesn't seem to bring with our brand/style information. I'm sure I'm missing something simple here, but what part of the process supplies the brand/style css and (common_content) images to the web doc root? I was assuming it came with the home page article, or is it supposed to be manually gathered? To be clear, after going through the process of create_site, adding a home page article, and one other book. (both added to the web site). I can see the "content" from the home page and book doc when browsing, but there are lots of 404s as you'll see below: /common/en-US/css/menu.css /videoNEXT/en-US/css/menu.css /en-US/labels.js /footer.html /videoNEXT/en-US/images/image_left.png /videoNEXT/en-US/images/image_right.png /en-US/images/web_logo.png /common.css /overrides.css /lang.css Thanks again! -- James Pooton videoNEXT Federal Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpooton at videonextfederal.com Fri May 17 01:22:26 2013 From: jpooton at videonextfederal.com (James Pooton) Date: Thu, 16 May 2013 19:22:26 -0600 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: <519568DF.7020902@redhat.com> References: <519568DF.7020902@redhat.com> Message-ID: On Thu, May 16, 2013 at 5:16 PM, Jeff Fearn wrote: > >> ..... >> >> We also tried directly setting the entity in Book_Info.xml (not that that >> would help us in the end), but the result was the same. >> > > It looks like the module we use to fetch that from the XML isn't expanding > entities. > > Can you open a bug about this? > Bug added, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Fri May 17 01:27:55 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 17 May 2013 11:27:55 +1000 Subject: [publican-list] Branding not applied when using --embedtoc with Publican 3.1.5 In-Reply-To: References: <519563D5.3070908@redhat.com> Message-ID: <5195879B.2010502@redhat.com> On 05/17/2013 11:08 AM, James Pooton wrote: > On Thu, May 16, 2013 at 4:55 PM, Jeff Fearn wrote: >> >> >> --embedtoc basically means "build this to use in a publican web site". The >> website contains the missing content. It's done this way so that you can >> change the style on a web site without having to rebuild every book or >> replace a mass of files. >> >> http://jfearn.fedorapeople.**org/en-US/Publican/3.0/html/** >> Users_Guide/sect-Users_Guide-**Website.html >> >> > > > That's actually the page I was working through. :) I guess my question is > this. That doc states: > > "The Publican-generated home page is the localizable page to which visitors > are directed by the site JavaScript and which **provides the style** for > the website structure." > > So I created a home page article per the directions, adding "web_type: > home" and "brand: videoNEXT" to its publican.cfg. However, when building > it for install, instructions ask for the following: > > publican build --publish --formats html-single --embedtoc --langs all > > Which results in HTML without any brand/style content applied, apparently > because of the --embedtoc.(?) So installing this into the website doesn't > seem to bring with our brand/style information. I'm sure I'm missing > something simple here, but what part of the process supplies the > brand/style css and (common_content) images to the web doc root? I was > assuming it came with the home page article, or is it supposed to be > manually gathered? > > To be clear, after going through the process of create_site, adding a home > page article, and one other book. (both added to the web site). I can see > the "content" from the home page and book doc when browsing, but there are > lots of 404s as you'll see below: > > /common/en-US/css/menu.css > /videoNEXT/en-US/css/menu.css > /en-US/labels.js > /footer.html > /videoNEXT/en-US/images/image_left.png > /videoNEXT/en-US/images/image_right.png > /en-US/images/web_logo.png > /common.css > /overrides.css > /lang.css Gah! Looks like some steps are missing for changes introduced in 3.1. RPM sites: $ yum install publican-web publican-$brand-web $ publican update_site For manual sites: $ cd $brandsrc_dir (yes including the common brand in the publican source >_<) $ publican build --formats=xml --langs=all --publish # brands don't use embedtoc $ publican install_brand --web --path=$path_to_site_root_dir # repeat for all brands $ publican update_site --site_config $path_to_site_cfg You might want to try setting web_style in your site cfg to 2 and run update_site for a different look. This is also not in the PUG but is documented in 'publican help_config'. $ publican help_config | grep -A3 web_style web_style: Splash pages should be generated to be compatible with this web style. Valid values are 1 and 2. Default: 1 Constraint: [1-2] Which is actually a pretty sad description given '2' is an entirely different web layout :-( Cheers, Jeff . -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From rlandmann at redhat.com Fri May 17 02:56:56 2013 From: rlandmann at redhat.com (Ruediger Landmann) Date: Fri, 17 May 2013 12:56:56 +1000 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: <51944163.3020200@redhat.com> References: <51944163.3020200@redhat.com> Message-ID: <51959C78.8050007@redhat.com> On 05/16/2013 12:16 PM, Jeff Fearn wrote: > I will harass Rudi to get some FC18 packages built with the useful > versions. Hey all -- I've got wkhtmltopdf-qt for 64-bit Fedora 18, plus wkhtmltopdf built against it, plus Publican 3.1.5-0 up here: http://rlandmann.fedorapeople.org/publican-3.1/ (also SRPMs if you want to build your own or if you need a different Fedora version, or architecture) I'm also about to push Publican 3.1.5-3 into the Fedora testing repos; this version depends on FOP, not wkhtmltopdf as its PDF engine, but will default to wkhtmltopdf (and not work) if it's available. So, once those builds have gone out, on Fedora 18 you can: * use wkhtmltopdf: - uninstall the wkhtmltopdf shipped in Fedora and block this package in your fedora.repo file - install wkhtmltopdf-qt, wkhtmltopdf, and publican from the link above * use fop: - uninstall wkhtmltopdf - install publican 3.1.5-3 from the test repo (use "--enablerepo updates-testing" in your yum command) Finally, if you're a Fedora package maintainer and would like to help unravel this mess, I have a review request open for wkhtmltopdf-qt: https://bugzilla.redhat.com/show_bug.cgi?id=955996 -- please help me out here! Cheers Rudi From rlandmann at redhat.com Fri May 17 04:32:44 2013 From: rlandmann at redhat.com (Ruediger Landmann) Date: Fri, 17 May 2013 14:32:44 +1000 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: <51959C78.8050007@redhat.com> References: <51944163.3020200@redhat.com> <51959C78.8050007@redhat.com> Message-ID: <5195B2EC.2050508@redhat.com> On 05/17/2013 12:56 PM, Ruediger Landmann wrote: > So, once those builds have gone out, on Fedora 18 you can: > > * use wkhtmltopdf: > - uninstall the wkhtmltopdf shipped in Fedora and block this package > in your fedora.repo file Actually, I just uploaded a new build of wkthmltopdf with the epoch bumped, so it should just replace the one from the Fedora repo automatically. (thanks for the suggestion Jeff!) Cheers Rudi From jaredsmith at jaredsmith.net Sat May 18 00:09:32 2013 From: jaredsmith at jaredsmith.net (Jared Smith) Date: Fri, 17 May 2013 20:09:32 -0400 Subject: [publican-list] PDF title page output and entity use in Publican 3.1.5 In-Reply-To: <51959C78.8050007@redhat.com> References: <51944163.3020200@redhat.com> <51959C78.8050007@redhat.com> Message-ID: On Thu, May 16, 2013 at 10:56 PM, Ruediger Landmann wrote: > > Finally, if you're a Fedora package maintainer and would like to help > unravel this mess, I have a review request open for wkhtmltopdf-qt: > https://bugzilla.redhat.com/show_bug.cgi?id=955996 -- please help me out > here! > Thanks Rudi. I know that Eric Christensen (Sparks on IRC) was looking into this, but threw his hands in the air after finding that the changes didn't meet the Fedora Packaging Guidelines for a number of reasons -- unfortunately, I don't remember the details off the top of my head. I'll try to track down Eric over the next few days and ask him to share his knowledge on that bugzilla ticket. In the meantime, I'll try out the new package in updates-testing and go back to being happy with FOP. -- Jared Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpooton at videonextfederal.com Mon May 20 21:25:10 2013 From: jpooton at videonextfederal.com (James Pooton) Date: Mon, 20 May 2013 15:25:10 -0600 Subject: [publican-list] Branding not applied when using --embedtoc with Publican 3.1.5 In-Reply-To: <5195879B.2010502@redhat.com> References: <519563D5.3070908@redhat.com> <5195879B.2010502@redhat.com> Message-ID: Thanks! Getting closer, but still missing some resources after these new steps. I decided to start fresh: - Updated to publican-3.1.5-3.fc18.noarch - Updated to patched FC18 builds of wkhtmltopdf packages - Created a new "web site" via: $ mkdir /videonext/webdocs $ cd /videonext/webdocs $ publican create_site --site_config webdocs.cfg --db_file webdocs.db --toc_path html/docs - Added the following to webdocs.cfg: title: "SKM Documentation" host: http://publican.vnf.lan def_lang: en-US web_style: 2 - Tried to build Publican's "common" brand via: $ cd /usr/share/publican/Common_Content/common (is this where it lives?) $ sudo publican build --formats=xml --langs=all --publish This error'd with: "Invalid build request: no PO files exist for language ar-SA at /usr/bin/publican line 921." So I limited it to english which worked: $ sudo publican build --formats=xml --langs=en-US --publish $ publican install_brand --web --path=/videonext/webdocs/html/docs - Repeated the same with our brand: $ cd /videonext/doc-3.7.0/brands/publican-videoNEXT $ publican build --formats=xml --langs=en-US --publish $ publican install_brand --web --path=/videonext/webdocs/html/docs - Updated the web site: $ publican update_site --site_config /videonext/webdocs/webdocs.cfg - Built and added our "home page" article and a sample book template (that uses videoNEXT brand): $ cd /videonext/doc-3.7.0/documents/Home_Page $ publican clean $ publican build --publish --formats=html-single --embedtoc --langs=en-US $ publican install_book --site_config /videonext/webdocs/webdocs.cfg --lang en-US $ publican update_site --site_config /videonext/webdocs/webdocs.cfg $ cd /videonext/doc-3.7.0/templates/videoNEXT_Template $ publican clean $ publican build --publish --formats html,pdf,epub --embedtoc --langs=all $ publican install_book --site_config /videonext/webdocs/webdocs.cfg --lang en-US $ publican update_site --site_config /videonext/webdocs/webdocs.cfg At this point the web site home page is "visible" (and style 2 is nicer ;) ), although there are still a variety of 404's keeping it from being usable: /videoNEXT/en-US/images/title_logo.svg /videoNEXT/en-US/images/image_left.png /videoNEXT/en-US/images/image_right.png /videoNEXT/en-US/css/menu.css /common/en-US/css/menu.css /en-US/carousel.html /en-US/toc.html /common.css /overrides.css /lang.css ... I'm assuming the "install_brand --web" steps aren't working for me and should be responsible for bringing in the /common/* and /videoNEXT/* brand items. However, when I run those commands, brand-named subdirectories are never created under my web doc root. Sorry this is got so long, but I'm hoping there is some error in what I'm doing. Any hints or pointers as to where the process is failing me would be greatly appreciated. Thanks... On Thu, May 16, 2013 at 7:27 PM, Jeff Fearn wrote: > On 05/17/2013 11:08 AM, James Pooton wrote: > >> On Thu, May 16, 2013 at 4:55 PM, Jeff Fearn wrote: >> >>> >>> >>> --embedtoc basically means "build this to use in a publican web site". >>> The >>> website contains the missing content. It's done this way so that you can >>> change the style on a web site without having to rebuild every book or >>> replace a mass of files. >>> >>> http://jfearn.fedorapeople.****org/en-US/Publican/3.0/html/** >>> Users_Guide/sect-Users_Guide-****Website.html >>> >>> >> Users_Guide/sect-Users_Guide-**Website.html >>> > >>> >> >> >> That's actually the page I was working through. :) I guess my question is >> this. That doc states: >> >> "The Publican-generated home page is the localizable page to which >> visitors >> are directed by the site JavaScript and which **provides the style** for >> the website structure." >> >> So I created a home page article per the directions, adding "web_type: >> home" and "brand: videoNEXT" to its publican.cfg. However, when building >> it for install, instructions ask for the following: >> >> publican build --publish --formats html-single --embedtoc --langs all >> >> Which results in HTML without any brand/style content applied, apparently >> because of the --embedtoc.(?) So installing this into the website doesn't >> seem to bring with our brand/style information. I'm sure I'm missing >> something simple here, but what part of the process supplies the >> brand/style css and (common_content) images to the web doc root? I was >> assuming it came with the home page article, or is it supposed to be >> manually gathered? >> >> To be clear, after going through the process of create_site, adding a home >> page article, and one other book. (both added to the web site). I can see >> the "content" from the home page and book doc when browsing, but there are >> lots of 404s as you'll see below: >> >> /common/en-US/css/menu.css >> /videoNEXT/en-US/css/menu.css >> /en-US/labels.js >> /footer.html >> /videoNEXT/en-US/images/image_**left.png >> /videoNEXT/en-US/images/image_**right.png >> /en-US/images/web_logo.png >> /common.css >> /overrides.css >> /lang.css >> > > Gah! Looks like some steps are missing for changes introduced in 3.1. > > RPM sites: > > $ yum install publican-web publican-$brand-web > $ publican update_site > > > For manual sites: > > $ cd $brandsrc_dir (yes including the common brand in the publican source > >_<) > $ publican build --formats=xml --langs=all --publish # brands don't use > embedtoc > $ publican install_brand --web --path=$path_to_site_root_dir > # repeat for all brands > $ publican update_site --site_config $path_to_site_cfg > > You might want to try setting web_style in your site cfg to 2 and run > update_site for a different look. This is also not in the PUG but is > documented in 'publican help_config'. > > $ publican help_config | grep -A3 web_style > web_style: > Splash pages should be generated to be compatible with > this web style. Valid values are 1 and 2. > Default: 1 > Constraint: [1-2] > > Which is actually a pretty sad description given '2' is an entirely > different web layout :-( > > Cheers, Jeff > > . > -- > Jeff Fearn > Senior Software Engineer > Infrastructure Engineering & Development (AEU) > Red Hat Asia Pacific Pty Ltd > GPG: 0x0357E8F0 > > ______________________________**_________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/**mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/**publican > -- *James Pooton* Director, Software Development videoNEXT Federal Systems, Inc. 571.485.2930 / cell: 571.314.3183 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Mon May 27 22:55:55 2013 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 28 May 2013 08:55:55 +1000 Subject: [publican-list] Branding not applied when using --embedtoc with Publican 3.1.5 In-Reply-To: References: <519563D5.3070908@redhat.com> <5195879B.2010502@redhat.com> Message-ID: <51A3E47B.2030501@redhat.com> Hi, sorry for the delay in responding, I was on holidays. On 05/21/2013 07:25 AM, James Pooton wrote: > Thanks! Getting closer, but still missing some resources after these new > steps. I decided to start fresh: > > - Updated to publican-3.1.5-3.fc18.noarch > - Updated to patched FC18 builds of wkhtmltopdf packages > - Created a new "web site" via: > > $ mkdir /videonext/webdocs > $ cd /videonext/webdocs > $ publican create_site --site_config webdocs.cfg --db_file webdocs.db > --toc_path html/docs > > - Added the following to webdocs.cfg: > > title: "SKM Documentation" > host: http://publican.vnf.lan > def_lang: en-US > web_style: 2 > > - Tried to build Publican's "common" brand via: > > $ cd /usr/share/publican/Common_Content/common (is this where it lives?) No, you need to get the source :( git clone git://git.fedorahosted.org/publican.git publican.git cd publican.git/publican/datadir/Common_Content/common I've opened a bug to address this pretty gross oversight. https://bugzilla.redhat.com/show_bug.cgi?id=967664 > $ sudo publican build --formats=xml --langs=all --publish > > This error'd with: > > "Invalid build request: no PO files exist for language ar-SA at > /usr/bin/publican line 921." > > So I limited it to english which worked: > > $ sudo publican build --formats=xml --langs=en-US --publish > $ publican install_brand --web --path=/videonext/webdocs/html/docs You need to put it in a brand dir, not in the doc root. $ mkdir /videonext/webdocs/html/docs/common $ publican install_brand --web --path=/videonext/webdocs/html/docs/common > - Repeated the same with our brand: > > $ cd /videonext/doc-3.7.0/brands/publican-videoNEXT > $ publican build --formats=xml --langs=en-US --publish > $ publican install_brand --web --path=/videonext/webdocs/html/docs $ mkdir /videonext/webdocs/html/docs/videoNEXT $ publican install_brand --web --path=/videonext/webdocs/html/docs/videoNEXT > - Updated the web site: > > $ publican update_site --site_config /videonext/webdocs/webdocs.cfg > > - Built and added our "home page" article and a sample book template (that > uses videoNEXT brand): > > $ cd /videonext/doc-3.7.0/documents/Home_Page > $ publican clean > $ publican build --publish --formats=html-single --embedtoc --langs=en-US > $ publican install_book --site_config /videonext/webdocs/webdocs.cfg --lang > en-US > $ publican update_site --site_config /videonext/webdocs/webdocs.cfg > > $ cd /videonext/doc-3.7.0/templates/videoNEXT_Template > $ publican clean > $ publican build --publish --formats html,pdf,epub --embedtoc --langs=all > $ publican install_book --site_config /videonext/webdocs/webdocs.cfg --lang > en-US > $ publican update_site --site_config /videonext/webdocs/webdocs.cfg > > > At this point the web site home page is "visible" (and style 2 is nicer ;) > ), although there are still a variety of 404's keeping it from being usable: > > /videoNEXT/en-US/images/title_logo.svg > /videoNEXT/en-US/images/image_left.png > /videoNEXT/en-US/images/image_right.png > /videoNEXT/en-US/css/menu.css > /common/en-US/css/menu.css > /en-US/carousel.html > /en-US/toc.html > /common.css > /overrides.css > /lang.css > ... > > I'm assuming the "install_brand --web" steps aren't working for me and > should be responsible for bringing in the /common/* and /videoNEXT/* brand > items. However, when I run those commands, brand-named subdirectories are > never created under my web doc root. > > Sorry this is got so long, but I'm hoping there is some error in what I'm > doing. Any hints or pointers as to where the process is failing me would be > greatly appreciated. > > Thanks... > > > On Thu, May 16, 2013 at 7:27 PM, Jeff Fearn wrote: > >> On 05/17/2013 11:08 AM, James Pooton wrote: >> >>> On Thu, May 16, 2013 at 4:55 PM, Jeff Fearn wrote: >>> >>>> >>>> >>>> --embedtoc basically means "build this to use in a publican web site". >>>> The >>>> website contains the missing content. It's done this way so that you can >>>> change the style on a web site without having to rebuild every book or >>>> replace a mass of files. >>>> >>>> http://jfearn.fedorapeople.****org/en-US/Publican/3.0/html/** >>>> Users_Guide/sect-Users_Guide-****Website.html >>>> >>>> >>> Users_Guide/sect-Users_Guide-**Website.html >>>>> >>>> >>> >>> >>> That's actually the page I was working through. :) I guess my question is >>> this. That doc states: >>> >>> "The Publican-generated home page is the localizable page to which >>> visitors >>> are directed by the site JavaScript and which **provides the style** for >>> the website structure." >>> >>> So I created a home page article per the directions, adding "web_type: >>> home" and "brand: videoNEXT" to its publican.cfg. However, when building >>> it for install, instructions ask for the following: >>> >>> publican build --publish --formats html-single --embedtoc --langs all >>> >>> Which results in HTML without any brand/style content applied, apparently >>> because of the --embedtoc.(?) So installing this into the website doesn't >>> seem to bring with our brand/style information. I'm sure I'm missing >>> something simple here, but what part of the process supplies the >>> brand/style css and (common_content) images to the web doc root? I was >>> assuming it came with the home page article, or is it supposed to be >>> manually gathered? >>> >>> To be clear, after going through the process of create_site, adding a home >>> page article, and one other book. (both added to the web site). I can see >>> the "content" from the home page and book doc when browsing, but there are >>> lots of 404s as you'll see below: >>> >>> /common/en-US/css/menu.css >>> /videoNEXT/en-US/css/menu.css >>> /en-US/labels.js >>> /footer.html >>> /videoNEXT/en-US/images/image_**left.png >>> /videoNEXT/en-US/images/image_**right.png >>> /en-US/images/web_logo.png >>> /common.css >>> /overrides.css >>> /lang.css >>> >> >> Gah! Looks like some steps are missing for changes introduced in 3.1. >> >> RPM sites: >> >> $ yum install publican-web publican-$brand-web >> $ publican update_site >> >> >> For manual sites: >> >> $ cd $brandsrc_dir (yes including the common brand in the publican source >>> _<) >> $ publican build --formats=xml --langs=all --publish # brands don't use >> embedtoc >> $ publican install_brand --web --path=$path_to_site_root_dir >> # repeat for all brands >> $ publican update_site --site_config $path_to_site_cfg >> >> You might want to try setting web_style in your site cfg to 2 and run >> update_site for a different look. This is also not in the PUG but is >> documented in 'publican help_config'. >> >> $ publican help_config | grep -A3 web_style >> web_style: >> Splash pages should be generated to be compatible with >> this web style. Valid values are 1 and 2. >> Default: 1 >> Constraint: [1-2] >> >> Which is actually a pretty sad description given '2' is an entirely >> different web layout :-( >> >> Cheers, Jeff >> >> . >> -- >> Jeff Fearn >> Senior Software Engineer >> Infrastructure Engineering & Development (AEU) >> Red Hat Asia Pacific Pty Ltd >> GPG: 0x0357E8F0 >> >> ______________________________**_________________ >> publican-list mailing list >> publican-list at redhat.com >> https://www.redhat.com/**mailman/listinfo/publican-list >> Wiki: https://fedorahosted.org/**publican >> > > > > > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican > -- Jeff Fearn Senior Software Engineer Infrastructure Engineering & Development (AEU) Red Hat Asia Pacific Pty Ltd GPG: 0x0357E8F0 From bugzilla at redhat.com Thu May 30 04:49:04 2013 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 30 May 2013 04:49:04 +0000 Subject: [publican-list] [Bug 719832] RFE: support git for distributed sets In-Reply-To: References: Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=719832 --- Comment #2 from Jeff Fearn --- http://search.cpan.org/dist/VCI/ -- 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=zyBn6phe1k&a=cc_unsubscribe