From bugzilla at redhat.com Tue Jun 1 03:20:13 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 31 May 2010 23:20:13 -0400 Subject: [publican-list] [Bug 598305] New: xref linked to a formalpara displays the title as the link but the link does nothing Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: xref linked to a formalpara displays the title as the link but the link does nothing https://bugzilla.redhat.com/show_bug.cgi?id=598305 Summary: xref linked to a formalpara displays the title as the link but the link does nothing Product: Red Hat Enterprise Linux 5 Version: 5.5 Platform: All OS/Version: Linux Status: NEW Severity: urgent Priority: low Component: publican AssignedTo: mhideo at redhat.com ReportedBy: irooskov at redhat.com QAContact: desktop-bugs at redhat.com CC: publican-list at redhat.com Classification: Red Hat Target Release: --- Description of problem: When using xref to link to a formalpara, the title is displayed as the link but the link does nothing. Version-Release number of selected component (if applicable): 1.6.3 How reproducible: 100% Steps to Reproduce: 1. svn co http://anonsvn.jboss.org/repos/jbosstools/trunk/documentation/guides/JBDS_Release_Notes 2. build html-single with publican 3. open in web browser, go to section 3 and click on the Web Tools Package link that is in brackets. Actual results: xref link pulls in the title to be displayed as the link but then the link doesn't go anywhere (not even to an incorrect location). Expected results: the xref link would send the user to the formalpara being referenced. Additional info: The JBDS release that these release notes are for is going live on the 8th of June so it would be fantastic to have this fixed for the release. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 1 03:26:34 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 31 May 2010 23:26:34 -0400 Subject: [publican-list] [Bug 598305] xref linked to a formalpara displays the title as the link but the link does nothing In-Reply-To: References: Message-ID: <201006010326.o513QYV0007753@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598305 Isaac Rooskov changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|mhideo at redhat.com |jfearn at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 1 03:34:20 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 31 May 2010 23:34:20 -0400 Subject: [publican-list] [Bug 595564] RFE: can xref links to formalpara go to the actual formalpara, rather than top of the page? In-Reply-To: References: Message-ID: <201006010334.o513YKp5010804@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=595564 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |irooskov at redhat.com --- Comment #3 from Jeff Fearn 2010-05-31 23:34:18 EDT --- *** Bug 598305 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 1 03:34:21 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 31 May 2010 23:34:21 -0400 Subject: [publican-list] [Bug 598305] xref linked to a formalpara displays the title as the link but the link does nothing In-Reply-To: References: Message-ID: <201006010334.o513YLro010805@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598305 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE --- Comment #1 from Jeff Fearn 2010-05-31 23:34:18 EDT --- *** This bug has been marked as a duplicate of bug 595564 *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From jfearn at redhat.com Tue Jun 1 04:09:41 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 01 Jun 2010 14:09:41 +1000 Subject: [publican-list] is publican-1.99 available to play with under ubuntu? In-Reply-To: References: <1E29B955-06EF-4681-BCA7-1B62498713BA@teambla.com> <1275265180.2533.33.camel@localhost> Message-ID: <1275365381.2473.73.camel@localhost> On Mon, 2010-05-31 at 04:59 -0400, Robert P. J. Day wrote: > On Mon, 31 May 2010, Jeff Fearn wrote: > > > On Fri, 2010-05-28 at 04:16 -0400, Robert P. J. Day wrote: > > > On Fri, 28 May 2010, Bram Vogelaar wrote: > > > > > > > i havent found any .debs yet but if you managed to install the > > > > 1.6.3 version (and xml- and html- treebuilder .debs) from the > > > > debian repository its a breeze to install from svn trunk. > > > > > > > > cd /path/to/svn/checkouts > > > > svn co http://svn.fedorahosted.org/svn/publican > > > > cd publican/trunk/publican > > > > perl Build.Pl > > > > install missing dependecies (6 -ish ) via your favorite package manager. (synaptic package manager => search for perl and then select correct ones) > > > > ./Build > > > > ./Build test > > > > sudo ./Build install > > > > > > > > and then "Hup Hup Hup, Barbatruc" your done > > > > > > > > have fun with it, the new website feature is awesome > > > > > > taking a stab at installing 1.99 on my ubuntu 10.04 box, the > > > following *seems* to have done it but i'm willing to be corrected > > > -- i'm still new at ubuntu. > > > > > > i grabbed the two noarch rpms from here: > > > > IMHO you'd be much better off following Bram's instructions, much > > less likely to have idiosyncratic behavior. > > your point is well taken, so i did the svn checkout. first point -- > i'm pretty sure one need not check out the *entire* svn repo, correct? > i mean, i need only the trunk if i'm working with the development > stream, correct? no sense checking out unnecessary content. yeah, in fact if you aren't building the brands you only need to check out http://svn.fedorahosted.org/svn/publican/trunk/publican > did the "perl Build.PL" and kept track of the perl packages that it > asked for one after another, might as well save that list for next > time. and, finally, after about a dozen installed perl packages: > ===== > > $ perl Build.PL > Deleting _build > Creating custom builder _build/lib/My/Builder.pm in _build/lib/My > Checking whether your kit is complete... > WARNING: the following files are missing in your kit: > META.yml > Please inform the author. > > Checking prerequisites... > - ERROR: Test::Perl::Critic is not installed > - ERROR: Test::Pod::Coverage is not installed > - ERROR: Test::Exception is not installed > - ERROR: DBD::SQLite is not installed > - ERROR: Devel::Cover is not installed > - ERROR: Test::Pod is not installed > - ERROR: DBD::SQLite is not installed > > ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions > of the modules indicated above before proceeding with this installation > > Deleting Build > Removed previous script 'Build' > > Creating new 'Build' script for 'Publican' version '1.99' > > ===== > > obviously, i can handle the latter dependencies but what's with that > META.yml diagnostic? my fault? in any event, if you want me to test, > let me know, the machine has lots of cycles to spare. META.yml gets created during the build process. It's unique to a distro version so I don't store it in the repo. > rday > > p.s. where's the publican-website stuff? will a successful build > create that as well? sorry if this is all massively off-topic. The publican-website is actually in the main source, it's just separated during the RPM creation. Note that this second RPM will probably disappear soon as I've come to the conclusion that a single package is fine, I just need to tweak how the default stuff is setup. It's all well on topic :) Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Tue Jun 1 04:19:22 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 01 Jun 2010 14:19:22 +1000 Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: Message-ID: <1275365962.2473.77.camel@localhost> On Mon, 2010-05-31 at 06:08 -0400, Robert P. J. Day wrote: > ok, i'm not sure what the deal is here. here's the original XML > file datadir/Common_Content/common/en-US/Conventions.xml: > > ... In PDF and paper editions, this manual uses typefaces drawn from > the Liberation > Fonts set. ... > > and here's the cause of a ./Build error in file > datadir/Common_Content/common/tmp/ar-SA/xml_tmp/Conventions.xml: > > ... In PDF and paper editions, this manual uses typefaces drawn from > the Liberation > Fonts set. ... > > is there a reason that end tag has disappeared? There are a couple of patches required to upstream modules: https://fedorahosted.org/publican/#Patchesforrequiredpackages This sounds like the HTML::TreeBuilder bug. FYI I'm currently in the, rather drawn out, process of taking over these upstream modules so I can release patched versions, when that happens I'll bump the version requirements and this should go away forever! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Tue Jun 1 04:25:10 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 01 Jun 2010 14:25:10 +1000 Subject: [publican-list] [PATCH] Correct misspellings of "deafult" to "default." In-Reply-To: References: Message-ID: <1275366310.2473.80.camel@localhost> On Mon, 2010-05-31 at 06:42 -0400, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day > > is this the proper strategy for submitting patches to the svn code > base? or do i send them elsewhere? This is fine since the trunk isn't really in bugzilla and trac is so awful I refuse to use it. Patch applied, thanks :) -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Tue Jun 1 04:25:40 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 01 Jun 2010 14:25:40 +1000 Subject: [publican-list] [PATCH] Fix a number of simple typoes in README file. In-Reply-To: References: Message-ID: <1275366340.2473.81.camel@localhost> Patch applied, thanks :) On Mon, 2010-05-31 at 07:18 -0400, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day > > --- > > Index: README > =================================================================== > --- README (revision 1287) > +++ README (working copy) > @@ -2,7 +2,7 @@ > > Assumptions: DocBook xml, *nix, en-US source language. > > -Q: What actions are their? > +Q: What actions are there? > > A: publican --help > > @@ -18,7 +18,7 @@ > > Q: How do I update all po files? > > -A: publican update_po --lANGS=ALLall > +A: publican update_po --langs=all > > Q: What Book specific options can I use? > > @@ -49,7 +49,7 @@ > ./Build rpm > > Debian > - The publican package deb files are in the debain package repo > + The publican package deb files are in the debian package repo > http://packages.debian.org/search?keywords=publican > cd publican > TODO: deps > @@ -78,7 +78,7 @@ > > TODO: detail building xml2 > > -TODO: Complete deatils on building required LibXML and LibXSLT modules > +TODO: Complete details on building required LibXML and LibXSLT modules > > vcvars32.bat > > -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Tue Jun 1 04:47:57 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 01 Jun 2010 14:47:57 +1000 Subject: [publican-list] is publican-1.99 available to play with under ubuntu? In-Reply-To: References: <1428060941.84261275263248388.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1275367677.2473.82.camel@localhost> On Mon, 2010-05-31 at 05:29 -0400, Robert P. J. Day wrote: > On Sun, 30 May 2010, Misty Stanley-Jones wrote: > > > > > ----- "Robert P. J. Day" wrote: > > > > > taking a stab at installing 1.99 on my ubuntu 10.04 box, the > > > following *seems* to have done it but i'm willing to be corrected -- > > > i'm still new at ubuntu. > > > > Hi Robert, > > > > If you can verify that this worked for you, I think it would be very > > helpful for you to write up a guide that other people can use. > > Thanks for all of the time you have put into it so far! > > FWIW, as i have a tendency to wiki everything so i know where to > find it later, i've dashed off what i've done here: > > http://www.crashcourse.ca/wiki/index.php/Building_Publican_1.99_on_Ubuntu_10.04 > > i'm sure there's a much simpler way to do this, but it's at least an > educational experience for me as i'm a long-time fedora person but > new to ubuntu so a lot of my issues involve me just getting used to > the ubuntu way of doing things. Nice, I yoinked the complete dep list and updated the README file :) Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From rpjday at crashcourse.ca Tue Jun 1 06:33:11 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 1 Jun 2010 02:33:11 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: <1275365962.2473.77.camel@localhost> References: <1275365962.2473.77.camel@localhost> Message-ID: On Tue, 1 Jun 2010, Jeff Fearn wrote: > On Mon, 2010-05-31 at 06:08 -0400, Robert P. J. Day wrote: > > ok, i'm not sure what the deal is here. here's the original XML > > file datadir/Common_Content/common/en-US/Conventions.xml: > > > > ... In PDF and paper editions, this manual uses typefaces drawn from > > the Liberation > > Fonts set. ... > > > > and here's the cause of a ./Build error in file > > datadir/Common_Content/common/tmp/ar-SA/xml_tmp/Conventions.xml: > > > > ... In PDF and paper editions, this manual uses typefaces drawn from > > the Liberation > > Fonts set. ... > > > > is there a reason that end tag has disappeared? > > There are a couple of patches required to upstream modules: > https://fedorahosted.org/publican/#Patchesforrequiredpackages > > This sounds like the HTML::TreeBuilder bug. hmmmmm ... speaking from a position of massive ignorance, i'm not quite convinced. the diagnostic specifically identifies the error with: at /usr/lib/perl5/XML/Parser.pm line 187 so wouldn't that represent XML parsing, not HTML? but there's something else i just noticed. unlike with the XML treebuilder package, there doesn't appear to be a corresponding ubuntu HTML package -- here's the entire list of "treebuilder" packages that exist: $ apt-cache search treebuilder libhtml-scrubber-perl - Perl extension for scrubbing/sanitizing html libhtml-treebuilder-xpath-perl - Perl module to add XPath support to HTML::TreeBuilder libwww-mechanize-treebuilder-perl - Perl module integrating WWW::Mechanize and HTML::TreeBuilder libxml-handler-trees-perl - Perl module for building tree structures using PerlSAX handlers libxml-treebuilder-perl - XML parser providing XML::Elements DOM similar to HTML::Element $ you can see that one for xml, i have that installed. but there is no directly corresponding one for HTML. however, if you notice that third package in the list, it clearly claims to integrate HTML::TreeBuilder functionality, and i *don't* have that installed -- nothing in the build process suggested i needed it. maybe this is all wildly irrelevant, i'm just pointing out what i'm seeing -- no actual, specific libhtml-treebuilder-perl package on ubuntu. -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From rpjday at crashcourse.ca Tue Jun 1 06:42:31 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 1 Jun 2010 02:42:31 -0400 (EDT) Subject: [publican-list] is publican-1.99 available to play with under ubuntu? In-Reply-To: <1275367677.2473.82.camel@localhost> References: <1428060941.84261275263248388.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1275367677.2473.82.camel@localhost> Message-ID: On Tue, 1 Jun 2010, Jeff Fearn wrote: ... snip ... > Nice, I yoinked the complete dep list and updated the README file :) help yourself, except a slight nitpick -- that list was collated on ubuntu, not debian. and an additional nitpick -- i can't claim that it's the *full* list of deps, only what i was forced to install as i was trying to build. more accurately, i'd describe it as a *minimal* list of requirements, that's all. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From hertzog at debian.org Tue Jun 1 07:51:36 2010 From: hertzog at debian.org (Raphael Hertzog) Date: Tue, 1 Jun 2010 09:51:36 +0200 Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> Message-ID: <20100601075136.GA12065@rivendell> On Tue, 01 Jun 2010, Robert P. J. Day wrote: > unlike with the XML treebuilder package, there doesn't appear to be > a corresponding ubuntu HTML package -- here's the entire list of > "treebuilder" packages that exist: > > $ apt-cache search treebuilder > libhtml-scrubber-perl - Perl extension for scrubbing/sanitizing html > libhtml-treebuilder-xpath-perl - Perl module to add XPath support to HTML::TreeBuilder > libwww-mechanize-treebuilder-perl - Perl module integrating WWW::Mechanize and HTML::TreeBuilder > libxml-handler-trees-perl - Perl module for building tree structures using PerlSAX handlers > libxml-treebuilder-perl - XML parser providing XML::Elements DOM similar to HTML::Element > $ > > you can see that one for xml, i have that installed. but there is > no directly corresponding one for HTML. however, if you notice that > third package in the list, it clearly claims to integrate > HTML::TreeBuilder functionality, and i *don't* have that installed -- > nothing in the build process suggested i needed it. The package name doesn't include "treebuilder" but libhtml-tree-perl contains HTML::TreeBuilder. And it appears in the "Depends" of the Debian/Ubuntu package. Cheers, -- Rapha?l Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ From rpjday at crashcourse.ca Tue Jun 1 08:16:51 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 1 Jun 2010 04:16:51 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: <20100601075136.GA12065@rivendell> References: <1275365962.2473.77.camel@localhost> <20100601075136.GA12065@rivendell> Message-ID: On Tue, 1 Jun 2010, Raphael Hertzog wrote: > On Tue, 01 Jun 2010, Robert P. J. Day wrote: > > unlike with the XML treebuilder package, there doesn't appear to be > > a corresponding ubuntu HTML package -- here's the entire list of > > "treebuilder" packages that exist: > > > > $ apt-cache search treebuilder > > libhtml-scrubber-perl - Perl extension for scrubbing/sanitizing html > > libhtml-treebuilder-xpath-perl - Perl module to add XPath support to HTML::TreeBuilder > > libwww-mechanize-treebuilder-perl - Perl module integrating WWW::Mechanize and HTML::TreeBuilder > > libxml-handler-trees-perl - Perl module for building tree structures using PerlSAX handlers > > libxml-treebuilder-perl - XML parser providing XML::Elements DOM similar to HTML::Element > > $ > > > > you can see that one for xml, i have that installed. but there is > > no directly corresponding one for HTML. however, if you notice that > > third package in the list, it clearly claims to integrate > > HTML::TreeBuilder functionality, and i *don't* have that installed -- > > nothing in the build process suggested i needed it. > > The package name doesn't include "treebuilder" but libhtml-tree-perl > contains HTML::TreeBuilder. > > And it appears in the "Depends" of the Debian/Ubuntu package. thanks, i assumed it was something fairly trivial. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From rpjday at crashcourse.ca Tue Jun 1 08:39:16 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 1 Jun 2010 04:39:16 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: <20100601075136.GA12065@rivendell> References: <1275365962.2473.77.camel@localhost> <20100601075136.GA12065@rivendell> Message-ID: On Tue, 1 Jun 2010, Raphael Hertzog wrote: > The package name doesn't include "treebuilder" but libhtml-tree-perl > contains HTML::TreeBuilder. > > And it appears in the "Depends" of the Debian/Ubuntu package. i asked about this on the ubuntu list but since you're awake :-), is there no way to have the main builder automatically install the packages corresponding to the required modules? the Build.PL script already contains the list of required modules, both for building and running: my $builder = $class->new( module_name => 'Publican', dist_name => 'Publican', license => 'perl', dist_author => 'Jeff Fearn ', dist_version_from => 'bin/publican', build_requires => { 'Devel::Cover' => 0, 'Module::Build' => 0, 'Test::Exception' => 0, ... etc etc ... requires => { ... more etc ... so why can't the builder (or something else) simply map modules to that OS's corresponding perl packages, present the user with a list of missing ones and ask whether they should be installed? obviously, that kind of operation is massively distro-dependent, but it would seem that "lsb_release" can tell you everything you need to know: $ lsb_release -ds Ubuntu 10.04 LTS $ lsb_release -ds "Fedora release 12 (Constantine)" clearly, this is not a vexing problem desperately looking for a solution, but it would make initial installation and building more pleasant, rather than going through the cycle of "build, missing perl package, damn, install package, repeat". this seems like such an obvious approach, i have to believe it's been done before. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From rpjday at crashcourse.ca Tue Jun 1 09:16:12 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 1 Jun 2010 05:16:12 -0400 (EDT) Subject: [publican-list] should i be able to build the Users Guide standalone? Message-ID: while i wait for svn fixes to allow the build to complete, i'd like to be able to at least peruse the Users Guide. if i pop into the Users_Guide directory and check the Makefile, i read: ===== STANDALONE ?= 0 PWD = $(shell pwd) # STANDALONE is a dirty hack to allow the User_Guide to be built without having publican installed # Mainly used when packaging or testing process changes before repackaging ifeq "$(STANDALONE)" "0" COMMON_CONFIG = /usr/share/publican else COMMON_CONFIG = $(PWD)/../.. ... snip ... include $(COMMON_CONFIG)/make/Makefile.common ===== so i try: $ STANDALONE=1 make Makefile:29: /home/rpjday/publican/svn/trunk/publican/Users_Guide/../../make/Makefile.common: No such file or directory make: *** No rule to make target `/home/rpjday/publican/svn/trunk/publican/Users_Guide/../../make/Makefile.common'. Stop. $ not surprising since there is no such file. and i stuck my head into bugzilla to find what looks like a related report: https://bugzilla.redhat.com/show_bug.cgi?id=533046 but i'm not sure how (or if) that resolves anything. thoughts? should i actually be able to build a readable Users Guide without building and installing everything else first? rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From jfearn at redhat.com Tue Jun 1 23:07:11 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 02 Jun 2010 09:07:11 +1000 Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> Message-ID: <1275433631.2572.28.camel@localhost> On Tue, 2010-06-01 at 02:33 -0400, Robert P. J. Day wrote: > On Tue, 1 Jun 2010, Jeff Fearn wrote: > > > On Mon, 2010-05-31 at 06:08 -0400, Robert P. J. Day wrote: > > > ok, i'm not sure what the deal is here. here's the original XML > > > file datadir/Common_Content/common/en-US/Conventions.xml: > > > > > > ... In PDF and paper editions, this manual uses typefaces drawn from > > > the Liberation > > > Fonts set. ... > > > > > > and here's the cause of a ./Build error in file > > > datadir/Common_Content/common/tmp/ar-SA/xml_tmp/Conventions.xml: > > > > > > ... In PDF and paper editions, this manual uses typefaces drawn from > > > the Liberation > > > Fonts set. ... > > > > > > is there a reason that end tag has disappeared? > > > > There are a couple of patches required to upstream modules: > > https://fedorahosted.org/publican/#Patchesforrequiredpackages > > > > This sounds like the HTML::TreeBuilder bug. > > hmmmmm ... speaking from a position of massive ignorance, i'm not > quite convinced. the diagnostic specifically identifies the error > with: > > at /usr/lib/perl5/XML/Parser.pm line 187 > > so wouldn't that represent XML parsing, not HTML? This is due to inheritance, XML::Element is a sub class of HTML::Element. The input it processed via XML::Element, which picks up as_XML from HTML::Element, which has the bug of dropping trailing tags in optionally empty tags. This output is then fed to XML::Parser which barfs due to the missing close tag. > but there's > something else i just noticed. > > unlike with the XML treebuilder package, there doesn't appear to be > a corresponding ubuntu HTML package -- here's the entire list of > "treebuilder" packages that exist: That is a typo on the wiki, it should be HTML::Tree, I fixed that. > $ apt-cache search treebuilder > libhtml-scrubber-perl - Perl extension for scrubbing/sanitizing html > libhtml-treebuilder-xpath-perl - Perl module to add XPath support to HTML::TreeBuilder > libwww-mechanize-treebuilder-perl - Perl module integrating WWW::Mechanize and HTML::TreeBuilder > libxml-handler-trees-perl - Perl module for building tree structures using PerlSAX handlers > libxml-treebuilder-perl - XML parser providing XML::Elements DOM similar to HTML::Element > $ > > you can see that one for xml, i have that installed. but there is > no directly corresponding one for HTML. however, if you notice that > third package in the list, it clearly claims to integrate > HTML::TreeBuilder functionality, and i *don't* have that installed -- > nothing in the build process suggested i needed it. > > maybe this is all wildly irrelevant, i'm just pointing out what i'm > seeing -- no actual, specific libhtml-treebuilder-perl package on > ubuntu. > Yeah, my bad :( Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Tue Jun 1 23:12:44 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 02 Jun 2010 09:12:44 +1000 Subject: [publican-list] is publican-1.99 available to play with under ubuntu? In-Reply-To: References: <1428060941.84261275263248388.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1275367677.2473.82.camel@localhost> Message-ID: <1275433964.2572.34.camel@localhost> On Tue, 2010-06-01 at 02:42 -0400, Robert P. J. Day wrote: > On Tue, 1 Jun 2010, Jeff Fearn wrote: > > ... snip ... > > > Nice, I yoinked the complete dep list and updated the README file :) > > help yourself, except a slight nitpick -- that list was collated on > ubuntu, not debian. Sure, but as far as packaging things goes Ubuntu is Debian in a fancy brown suit ... I'm sure I'll regret saying that sooner or later ;) > and an additional nitpick -- i can't claim that > it's the *full* list of deps, only what i was forced to install as i > was trying to build. more accurately, i'd describe it as a *minimal* > list of requirements, that's all. I grok, but it's much better than what we had. We don't lose anything, and at worst we will add missing deps as they get raised. Major win from my perspective, so thanks mate :) Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Tue Jun 1 23:18:02 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 02 Jun 2010 09:18:02 +1000 Subject: [publican-list] should i be able to build the Users Guide standalone? In-Reply-To: References: Message-ID: <1275434282.2572.38.camel@localhost> On Tue, 2010-06-01 at 05:16 -0400, Robert P. J. Day wrote: > while i wait for svn fixes to allow the build to complete, i'd like > to be able to at least peruse the Users Guide. if i pop into the > Users_Guide directory and check the Makefile, i read: Oh, don't use the Makefile! That's for very old versions of Publican, 0.45 and older. I keep it hanging around in the PUG so I can test that the old2new code works. Maybe there are no old books left and we can retire that feature ... Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From rpjday at crashcourse.ca Wed Jun 2 00:29:23 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 1 Jun 2010 20:29:23 -0400 (EDT) Subject: [publican-list] should i be able to build the Users Guide standalone? In-Reply-To: <1275434282.2572.38.camel@localhost> References: <1275434282.2572.38.camel@localhost> Message-ID: On Wed, 2 Jun 2010, Jeff Fearn wrote: > On Tue, 2010-06-01 at 05:16 -0400, Robert P. J. Day wrote: > > while i wait for svn fixes to allow the build to complete, i'd like > > to be able to at least peruse the Users Guide. if i pop into the > > Users_Guide directory and check the Makefile, i read: > > Oh, don't use the Makefile! That's for very old versions of Publican, > 0.45 and older. I keep it hanging around in the PUG so I can test that > the old2new code works. > > Maybe there are no old books left and we can retire that feature ... so does that mean you can or can't build the users guide without building and installing everything else? rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From dottedmag at dottedmag.net Wed Jun 2 00:32:30 2010 From: dottedmag at dottedmag.net (Mikhail Gusarov) Date: Wed, 02 Jun 2010 07:32:30 +0700 Subject: [publican-list] should i be able to build the Users Guide standalone? In-Reply-To: (Robert P. J. Day's message of "Tue, 1 Jun 2010 20:29:23 -0400 (EDT)") References: <1275434282.2572.38.camel@localhost> Message-ID: <87typm5l5t.fsf@leibnitz.dottedmag.net> Twas brillig at 20:29:23 01.06.2010 UTC-04 when rpjday at crashcourse.ca did gyre and gimble: RPJD> so does that mean you can or can't build the users guide without RPJD> building and installing everything else? cd $(GUIDEDIR) && \ perl -I $(CURDIR)/blib/lib $(CURDIR)/blib/script/publican build \ --formats=html-desktop --publish --langs=all \ --common_config="$(CURDIR)/blib/datadir" \ --common_content="$(CURDIR)/blib/datadir/Common_Content" this is how User's Guide is build during Debian package building. GUIDEDIR is the directory where User's Guide is located, CURDIR is a top directory of source code. -- http://fossarchy.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From jfearn at redhat.com Wed Jun 2 00:40:11 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 02 Jun 2010 10:40:11 +1000 Subject: [publican-list] should i be able to build the Users Guide standalone? In-Reply-To: References: <1275434282.2572.38.camel@localhost> Message-ID: <1275439211.2572.51.camel@localhost> On Tue, 2010-06-01 at 20:29 -0400, Robert P. J. Day wrote: > On Wed, 2 Jun 2010, Jeff Fearn wrote: > > > On Tue, 2010-06-01 at 05:16 -0400, Robert P. J. Day wrote: > > > while i wait for svn fixes to allow the build to complete, i'd like > > > to be able to at least peruse the Users Guide. if i pop into the > > > Users_Guide directory and check the Makefile, i read: > > > > Oh, don't use the Makefile! That's for very old versions of Publican, > > 0.45 and older. I keep it hanging around in the PUG so I can test that > > the old2new code works. > > > > Maybe there are no old books left and we can retire that feature ... > > so does that mean you can or can't build the users guide without > building and installing everything else? You need publican installed to build the PUG, but you should be able to build it with the version in Ubuntu. You can also download a PDF from http://jfearn.fedorapeople.org/en-US/Publican/1.5/pdf/Users_Guide/Publican-1.5-Users_Guide-en-US.pdf It's a little out of date because I have been busy :( Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jmorgan at redhat.com Wed Jun 2 05:44:50 2010 From: jmorgan at redhat.com (Jared Morgan) Date: Wed, 2 Jun 2010 01:44:50 -0400 (EDT) Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <9045652.91.1275457616092.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> I've seen a number of emails flying around that show some nice aliases for publican commands. I know many people have implemented their own aliases to quickly execute basic en-US book builds. When we build a book, I would imagine most people would want to publish en-US versions initially. So why don't we set this as the default language in command-line arguments, rather than having to specify it each time? So instead of executing "publican build -langs=en-US -formats html", it would simply be "publican build -formats html". For those users who need to generate language-specific versions, they could override the default by specifying the --langs option when they execute their publish command. There might be other ways we can shorten what users need to type as well. How about a "-formats online" option which generates html, and html-single (possibly even ePub). Thoughts? Cheers Jared Morgan Content Author Red Hat Asia Pacific 1/193 North Quay BRISBANE QLD 4000 P: +61 7 3514 8242 M: +61 413 005 479 -------------- next part -------------- An HTML attachment was scrubbed... URL: From djorm at redhat.com Wed Jun 2 05:53:44 2010 From: djorm at redhat.com (David Jorm) Date: Wed, 2 Jun 2010 01:53:44 -0400 (EDT) Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <1644002252.872331275458024278.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> What would the French say! I agree. Make English default. David ----- Original Message ----- From: "Jared Morgan" To: "publican-list" Sent: Wednesday, June 2, 2010 3:44:50 PM GMT +10:00 Brisbane Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args I've seen a number of emails flying around that show some nice aliases for publican commands. I know many people have implemented their own aliases to quickly execute basic en-US book builds. When we build a book, I would imagine most people would want to publish en-US versions initially. So why don't we set this as the default language in command-line arguments, rather than having to specify it each time? So instead of executing "publican build -langs=en-US -formats html", it would simply be "publican build -formats html". For those users who need to generate language-specific versions, they could override the default by specifying the --langs option when they execute their publish command. There might be other ways we can shorten what users need to type as well. How about a "-formats online" option which generates html, and html-single (possibly even ePub). Thoughts? Cheers Jared Morgan Content Author Red Hat Asia Pacific 1/193 North Quay BRISBANE QLD 4000 P: +61 7 3514 8242 M: +61 413 005 479 _______________________________________________ publican-list mailing list publican-list at redhat.com https://www.redhat.com/mailman/listinfo/publican-list Wiki: https://fedorahosted.org/publican From hertzog at debian.org Wed Jun 2 06:14:49 2010 From: hertzog at debian.org (Raphael Hertzog) Date: Wed, 2 Jun 2010 08:14:49 +0200 Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> <20100601075136.GA12065@rivendell> Message-ID: <20100602061449.GC846@rivendell> On Tue, 01 Jun 2010, Robert P. J. Day wrote: > i asked about this on the ubuntu list but since you're awake :-), > is there no way to have the main builder automatically install the > packages corresponding to the required modules? Not really, no. It would be possible to hack a script grabbing the list of modules, converting that to filenames (HTML::Tree -> */HTML/Tree.pm) and using apt-file search to find out the package name but it relies on the Contents-*.gz files indexing the content of all packages. Thus the required information are not really part of the control information exported by packages. Cheers, -- Rapha?l Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ From rpjday at crashcourse.ca Wed Jun 2 08:00:40 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 04:00:40 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: <1275433631.2572.28.camel@localhost> References: <1275365962.2473.77.camel@localhost> <1275433631.2572.28.camel@localhost> Message-ID: On Wed, 2 Jun 2010, Jeff Fearn wrote: > That is a typo on the wiki, it should be HTML::Tree, I fixed that. was that on the page https://fedorahosted.org/publican/? i see something i don't understand: There is a bug in HTML::!Tree, we carry a patch for this in Fedora. what's with the "!"? some perl module idiosyncracy i've never seen? and, yes, i've *always* been this pedantic. deal with it. :-) rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From rpjday at crashcourse.ca Wed Jun 2 12:16:10 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 08:16:10 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: <1275433631.2572.28.camel@localhost> References: <1275365962.2473.77.camel@localhost> <1275433631.2572.28.camel@localhost> Message-ID: On Wed, 2 Jun 2010, Jeff Fearn wrote: > On Tue, 2010-06-01 at 02:33 -0400, Robert P. J. Day wrote: > > On Tue, 1 Jun 2010, Jeff Fearn wrote: > > > There are a couple of patches required to upstream modules: > > > https://fedorahosted.org/publican/#Patchesforrequiredpackages > > > > > > This sounds like the HTML::TreeBuilder bug. > > > > hmmmmm ... speaking from a position of massive ignorance, i'm > > not quite convinced. the diagnostic specifically identifies the > > error with: > > > > at /usr/lib/perl5/XML/Parser.pm line 187 > > > > so wouldn't that represent XML parsing, not HTML? > > This is due to inheritance, XML::Element is a sub class of > HTML::Element. The input it processed via XML::Element, which picks > up as_XML from HTML::Element, which has the bug of dropping trailing > tags in optionally empty tags. This output is then fed to > XML::Parser which barfs due to the missing close tag. gack ... i get the feeling that this ain't gonna happen for me. i'd dearly love to be able to check out and build this on my ubuntu system but if it requires patches that are yet to be pushed upstream into other packages, that might be asking a bit much. if anyone has advice in terms of a workaround, i'm all ears. otherwise, i think i'm stuck. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From mylists at teambla.com Wed Jun 2 13:20:13 2010 From: mylists at teambla.com (Bram Vogelaar) Date: Wed, 2 Jun 2010 15:20:13 +0200 Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> <1275433631.2572.28.camel@localhost> Message-ID: i installed the following debian versions and those work well for me libhtml-tree-perl_3.23-2_all.deb libxml-treebuilder-perl_3.09-2_all.deb bram On 2 Jun 2010, at 14:16, Robert P. J. Day wrote: > On Wed, 2 Jun 2010, Jeff Fearn wrote: > >> On Tue, 2010-06-01 at 02:33 -0400, Robert P. J. Day wrote: >>> On Tue, 1 Jun 2010, Jeff Fearn wrote: > >>>> There are a couple of patches required to upstream modules: >>>> https://fedorahosted.org/publican/#Patchesforrequiredpackages >>>> >>>> This sounds like the HTML::TreeBuilder bug. >>> >>> hmmmmm ... speaking from a position of massive ignorance, i'm >>> not quite convinced. the diagnostic specifically identifies the >>> error with: >>> >>> at /usr/lib/perl5/XML/Parser.pm line 187 >>> >>> so wouldn't that represent XML parsing, not HTML? >> >> This is due to inheritance, XML::Element is a sub class of >> HTML::Element. The input it processed via XML::Element, which picks >> up as_XML from HTML::Element, which has the bug of dropping trailing >> tags in optionally empty tags. This output is then fed to >> XML::Parser which barfs due to the missing close tag. > > gack ... i get the feeling that this ain't gonna happen for me. i'd > dearly love to be able to check out and build this on my ubuntu system > but if it requires patches that are yet to be pushed upstream into > other packages, that might be asking a bit much. > > if anyone has advice in terms of a workaround, i'm all ears. > otherwise, i think i'm stuck. > > rday > > -- > > ======================================================================== > Robert P. J. Day Waterloo, Ontario, CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > ======================================================================== > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From rpjday at crashcourse.ca Wed Jun 2 13:29:13 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 09:29:13 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> <1275433631.2572.28.camel@localhost> Message-ID: On Wed, 2 Jun 2010, Bram Vogelaar wrote: > i installed the following debian versions and those work well for me > > libhtml-tree-perl_3.23-2_all.deb > libxml-treebuilder-perl_3.09-2_all.deb i'm still feeling my way around ubuntu -- i assume those are going to be from the testing or unstable repos? both of mine of the above are build "1", not "2" and i'm guessing that makes all the difference. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From mylists at teambla.com Wed Jun 2 13:58:25 2010 From: mylists at teambla.com (Bram Vogelaar) Date: Wed, 2 Jun 2010 15:58:25 +0200 Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> <1275433631.2572.28.camel@localhost> Message-ID: yeah i used the deb's from the sid repo http://packages.debian.org/sid/libhtml-tree-perl http://packages.debian.org/sid/libxml-treebuilder-perl bram On 2 Jun 2010, at 15:29, Robert P. J. Day wrote: > On Wed, 2 Jun 2010, Bram Vogelaar wrote: > >> i installed the following debian versions and those work well for me >> >> libhtml-tree-perl_3.23-2_all.deb >> libxml-treebuilder-perl_3.09-2_all.deb > > i'm still feeling my way around ubuntu -- i assume those are going > to be from the testing or unstable repos? both of mine of the above > are build "1", not "2" and i'm guessing that makes all the difference. > > rday > > -- > > ======================================================================== > Robert P. J. Day Waterloo, Ontario, CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > ======================================================================== > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From rpjday at crashcourse.ca Wed Jun 2 14:04:14 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 10:04:14 -0400 (EDT) Subject: [publican-list] 1.99: translation(?) to SA drops end tag In-Reply-To: References: <1275365962.2473.77.camel@localhost> <1275433631.2572.28.camel@localhost> Message-ID: On Wed, 2 Jun 2010, Bram Vogelaar wrote: > yeah i used the deb's from the sid repo > > http://packages.debian.org/sid/libhtml-tree-perl > http://packages.debian.org/sid/libxml-treebuilder-perl > > bram and that solved it, and now it builds. whoo hoo! thanks muchly. is it worth updating my wiki page to point this out, or is there not much value to that? ah, maybe i'll just update it then move on to actually using the software. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From bugzilla at redhat.com Wed Jun 2 14:23:00 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Jun 2010 10:23:00 -0400 Subject: [publican-list] [Bug 593887] Terse validity error messages make troubleshooting XML structure issues difficult. In-Reply-To: References: Message-ID: <201006021423.o52EN0uQ007966@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=593887 Nick Bebout changed: What |Removed |Added ---------------------------------------------------------------------------- CC|nb at fedoraproject.org | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Jun 2 14:23:00 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Jun 2010 10:23:00 -0400 Subject: [publican-list] [Bug 596257] RFE: do not split admonitions across pages In-Reply-To: References: Message-ID: <201006021423.o52EN0Js019048@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=596257 Nick Bebout changed: What |Removed |Added ---------------------------------------------------------------------------- CC|nb at fedoraproject.org | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From rpjday at crashcourse.ca Wed Jun 2 14:37:04 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 10:37:04 -0400 (EDT) Subject: [publican-list] updated ubuntu build wiki page and how does one build the UG? Message-ID: stripped down ubuntu wiki page: http://www.crashcourse.ca/wiki/index.php/Building_Publican_1.99_on_Ubuntu_10.04 and now that the build completes, what i was after all this time -- how does one build the user guide? apparently, that Makefile is obsolete. and i don't see a UG argument to the build scripts. help? i'm getting close, right? right? rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From jonathan.robie at redhat.com Wed Jun 2 14:54:33 2010 From: jonathan.robie at redhat.com (Jonathan Robie) Date: Wed, 02 Jun 2010 10:54:33 -0400 Subject: [publican-list] publican-redhat for F13? Message-ID: <1275490473.5306.0.camel@localhost> I just installed Fedora 13, and I'm looking for fedora-redhat. Where can I get it? Is it yum installable? (I found the source rpm.) From mylists at teambla.com Wed Jun 2 15:49:55 2010 From: mylists at teambla.com (Bram Vogelaar) Date: Wed, 2 Jun 2010 17:49:55 +0200 Subject: [publican-list] updated ubuntu build wiki page and how does one build the UG? In-Reply-To: References: Message-ID: now that you have publican installed, you can build the user guide using publican cd /path/to/svn/checkout/publican cd Users_Guide publican build --formats="html,html-single,pdf,epub" --langs=en-US --publish --embedtoc the build user guide will be in a folder called "publish" have a read at jeff's documentation website to get the whole spiel http://jfearn.fedorapeople.org/en-US/index.html bram On 2 Jun 2010, at 16:37, Robert P. J. Day wrote: > > stripped down ubuntu wiki page: > > http://www.crashcourse.ca/wiki/index.php/Building_Publican_1.99_on_Ubuntu_10.04 > > and now that the build completes, what i was after all this time -- > how does one build the user guide? apparently, that Makefile is > obsolete. and i don't see a UG argument to the build scripts. help? > > i'm getting close, right? right? > > rday > > -- > > ======================================================================== > Robert P. J. Day Waterloo, Ontario, CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > ======================================================================== > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From rpjday at crashcourse.ca Wed Jun 2 15:56:38 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 11:56:38 -0400 (EDT) Subject: [publican-list] updated ubuntu build wiki page and how does one build the UG? In-Reply-To: References: Message-ID: On Wed, 2 Jun 2010, Bram Vogelaar wrote: > now that you have publican installed, you can build the user guide > using publican hold on there, it's not "installed" yet. and given that there's no top-level Makefile with an install: target, it's not clear how you would do that on a non-redhat system. i can certainly see how the top-level spec file would let you build an rpm, but that's not going to work on ubuntu. once i get past that step, yup, it should be easy. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From mylists at teambla.com Wed Jun 2 16:04:14 2010 From: mylists at teambla.com (Bram Vogelaar) Date: Wed, 2 Jun 2010 18:04:14 +0200 Subject: [publican-list] updated ubuntu build wiki page and how does one build the UG? In-Reply-To: References: Message-ID: <68147E85-1062-4FBA-95E7-F601FFB40638@teambla.com> On 2 Jun 2010, at 17:56, Robert P. J. Day wrote: > On Wed, 2 Jun 2010, Bram Vogelaar wrote: > >> now that you have publican installed, you can build the user guide >> using publican > > hold on there, it's not "installed" yet. and given that there's no > top-level Makefile with an install: target, it's not clear how you > would do that on a non-redhat system. i can certainly see how the > top-level spec file would let you build an rpm, but that's not going > to work on ubuntu. > > once i get past that step, yup, it should be easy. publican in not a compiled program so a make file doesnt make much sense. the easiest way to get a working installation is to run the commands i posted before after running the commands below you should have a running publican install. cd /path/to/svn/checkouts svn co http://svn.fedorahosted.org/svn/publican cd publican/trunk/publican perl Build.Pl install missing dependecies (6 -ish ) via your favorite package manager. (synaptic package manager => search for perl and then select correct ones) ./Build ./Build test sudo ./Build install bram > > rday > > -- > > ======================================================================== > Robert P. J. Day Waterloo, Ontario, CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > ======================================================================== > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From rpjday at crashcourse.ca Wed Jun 2 16:28:58 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 12:28:58 -0400 (EDT) Subject: [publican-list] updated ubuntu build wiki page and how does one build the UG? In-Reply-To: <68147E85-1062-4FBA-95E7-F601FFB40638@teambla.com> References: <68147E85-1062-4FBA-95E7-F601FFB40638@teambla.com> Message-ID: On Wed, 2 Jun 2010, Bram Vogelaar wrote: ... snip ... > ./Build > ./Build test > sudo ./Build install ah, of course, sorry, i'm unfamiliar with the whole Builder infrastructure. i looked through the Build script for the phrase "install" and didn't see it. my fault. whoa ... the "test" step is telling me i still have some work to do. back to it ... rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From rpjday at crashcourse.ca Wed Jun 2 17:02:03 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 13:02:03 -0400 (EDT) Subject: [publican-list] updated ubuntu build wiki page and how does one build the UG? In-Reply-To: References: Message-ID: the final(?) version of the ubuntu page: http://www.crashcourse.ca/wiki/index.php/Building_Publican_1.99_on_Ubuntu_10.04 i apologize profusely, it should *not* have taken me this long. i even got the user guide to build, even though it advertises itself as version 1.6, i'm assuming its contents reflects version 1.99. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From rpjday at crashcourse.ca Wed Jun 2 18:10:42 2010 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 2 Jun 2010 14:10:42 -0400 (EDT) Subject: [publican-list] [PATCH] Add an early reference and link to the DocBook 5 standard. Message-ID: Signed-off-by: Robert P. J. Day --- Index: publican/Users_Guide/en-US/Introduction.xml =================================================================== --- publican/Users_Guide/en-US/Introduction.xml (revision 1296) +++ publican/Users_Guide/en-US/Introduction.xml (working copy) @@ -6,7 +6,7 @@ Introduction Introduction - Publican is a tool for publishing material authored in DocBook XML. This guide explains how to create and build books and articles using Publican. It is not a general DocBook XML tutorial; refer to DocBook: The Definitive Guide by Norman Walsh and Leonard Muellner, available at for more general help with DocBook XML. + Publican is a tool for publishing material authored in DocBook XML. This guide explains how to create and build books and articles using Publican. It is not a general DocBook XML tutorial; refer to DocBook: The Definitive Guide by Norman Walsh and Leonard Muellner for more general help with DocBook XML. The 4.x version of that book can be found at , while the more recently-released DocBook 5 standard can be found at . Publican began life as an internal tool used by Red Hat's Documentation Group (now known as Engineering Content Services). On occasion, this legacy is visible. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ======================================================================== From jfearn at redhat.com Wed Jun 2 22:08:04 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 03 Jun 2010 08:08:04 +1000 Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> References: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <1275516484.2468.3.camel@localhost> On Wed, 2010-06-02 at 01:44 -0400, Jared Morgan wrote: > I've seen a number of emails flying around that show some nice aliases > for publican commands. I know many people have implemented their own > aliases to quickly execute basic en-US book builds. We removed this because we got disgusted with the complete inability of writers to give any consideration or concern for translation. When writers start displaying the ability to think of other people we will add this back in. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jwulf at redhat.com Wed Jun 2 22:45:44 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Thu, 03 Jun 2010 08:45:44 +1000 Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> References: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <4C06DF18.7060906@redhat.com> On 06/02/2010 03:44 PM, Jared Morgan wrote: > I've seen a number of emails flying around that show some nice aliases > for publican commands. I know many people have implemented their own > aliases to quickly execute basic en-US book builds. > > When we build a book, I would imagine most people would want to > publish en-US versions initially. So why don't we set this as the > default language in command-line arguments, rather than having to > specify it each time? > > So instead of executing "publican build -langs=en-US -formats html", > it would simply be "publican build -formats html". > > For those users who need to generate language-specific versions, they > could override the default by specifying the --langs option when they > execute their publish command. > > There might be other ways we can shorten what users need to type as > well. How about a "-formats online" option which generates html, and > html-single (possibly even ePub). > > Thoughts? > > Cheers > > Jared Morgan > Content Author > Red Hat Asia Pacific > 1/193 North Quay > BRISBANE QLD 4000 > > P: +61 7 3514 8242 > M: +61 413 005 479 > > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican $ diff /usr/lib/perl5/vendor_perl/5.10.0/Publican/Builder.pm /usr/lib/perl5/vendor_perl/5.10.0/Publican/Builder.pm.old 99,100c99,100 < my $langs = delete( $args->{langs} ) < || 'en-US'; --- > my $langs = delete( $args->{langs} ) > || croak( maketext("langs is a mandatory argument") ); "There I fixed it" - the wonders of open source. :-) Untested and unsupported, usual disclaimers apply. Probably a better way to do it would be to have a per-user publican.defaults file with default behaviour information in it, and maybe a system-wide one in /etc, or something like that. - Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorgan at redhat.com Wed Jun 2 22:52:36 2010 From: jmorgan at redhat.com (Jared Morgan) Date: Wed, 2 Jun 2010 18:52:36 -0400 (EDT) Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <17596838.31.1275519202481.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <2444005.34.1275519349838.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> > We removed this because we got disgusted with the complete inability of >writers to give any consideration or concern for translation. When >writers start displaying the ability to think of other people we will >add this back in. So, in summary, users should continue to use aliases for common publican publishing tasks. Not a problem. Thanks Jeff. You didn't respond to my suggestion about creating a --formats=online|print option. Jared Morgan Content Author Red Hat Asia Pacific 1/193 North Quay BRISBANE QLD 4000 P: +61 7 3514 8242 M: +61 413 005 479 From: "Jeff Fearn" To: "Publican discussions" Sent: Thursday, June 3, 2010 8:08:04 AM Subject: Re: [publican-list] RFC: Make -langs=en-US the default language for command line args On Wed, 2010-06-02 at 01:44 -0400, Jared Morgan wrote: > I've seen a number of emails flying around that show some nice aliases > for publican commands. I know many people have implemented their own > aliases to quickly execute basic en-US book builds. We removed this because we got disgusted with the complete inability of writers to give any consideration or concern for translation. When writers start displaying the ability to think of other people we will add this back in. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing _______________________________________________ publican-list mailing list publican-list at redhat.com https://www.redhat.com/mailman/listinfo/publican-list Wiki: https://fedorahosted.org/publican -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfearn at redhat.com Wed Jun 2 23:22:45 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 03 Jun 2010 09:22:45 +1000 Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <2444005.34.1275519349838.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> References: <2444005.34.1275519349838.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <1275520965.2468.52.camel@localhost> On Wed, 2010-06-02 at 18:52 -0400, Jared Morgan wrote: > >We removed this because we got disgusted with the complete inability > of > >writers to give any consideration or concern for translation. When > >writers start displaying the ability to think of other people we will > >add this back in. > > So, in summary, users should continue to use aliases for common > publican publishing tasks. Not a problem. Thanks Jeff. > > You didn't respond to my suggestion about creating a --formats=online| > print option. No, I didn't. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From bugzilla at redhat.com Thu Jun 3 00:02:48 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Jun 2010 20:02:48 -0400 Subject: [publican-list] [Bug 599258] table borders on in html/html-single In-Reply-To: References: Message-ID: <201006030002.o5302mv9015484@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=599258 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |publican-list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Jun 3 00:04:07 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Jun 2010 20:04:07 -0400 Subject: [publican-list] [Bug 599258] table borders on in html/html-single In-Reply-To: References: Message-ID: <201006030004.o5304729015589@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=599258 --- Comment #3 from Jeff Fearn 2010-06-02 20:04:04 EDT --- (In reply to comment #0) > Description of problem: > Table borders are being drawn on the output of in the html & > html-single formats. PDF is fine. > > Version-Release number of selected component (if applicable): > 1.6.3 > > How reproducible: > everytime > > Steps to Reproduce: > 1.add a with a few s > 2.build html or html-single > > > Actual results: > borders are drawn - screenshot attached > > Expected results: > borders are not drawn - screenshot attached > > Additional info: > * the table itself has borders=0 > * the css for simplelist.table has border-style: none (common.css) > * but the css for th, td has border: 1px solid #000000; (common.css) Added publican list to CC. I agree they should be consistent in all outputs, does anyone disagree with removing the borders in HTML? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From r.landmann at redhat.com Thu Jun 3 00:21:49 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Thu, 03 Jun 2010 10:21:49 +1000 Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <2444005.34.1275519349838.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> References: <2444005.34.1275519349838.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> Message-ID: <4C06F59D.8090003@redhat.com> On 06/03/2010 08:52 AM, Jared Morgan wrote: >> We removed this because we got disgusted with the complete inability of >> writers to give any consideration or concern for translation. When >> writers start displaying the ability to think of other people we will >> add this back in. >> > So, in summary, users should continue to use aliases for common publican publishing tasks. Not a problem. Thanks Jeff. > The problem here is that "common publishing tasks" differ really significantly between somebody writing their XML in English, somebody writing their XML in French, and somebody translating any language to any other language. Publican has a diverse user base, and it's becoming more diverse all the time. I guess the reason why I'm uncomfortable with this suggestion is that it privileges one group of users over every other group. Furthermore, speaking only for myself, since I currently publish a large number of docs in a large number of different languages, I actually like the safety-net of when Publican tells me "you didn't say which language you wanted, dufus". If Publican silently defaulted to building (or worse, publishing!) the English version of a document every time I forgot or mistyped the option, I would have made a non-trivial number of non-trivial stuff-ups by now :) However, for anyone who is typically only ever building and publishing in one language and wants to save themselves some keystrokes, aliasing some commands is a neat solution. Cheers Rudi From jwulf at redhat.com Thu Jun 3 01:47:14 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Thu, 03 Jun 2010 11:47:14 +1000 Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <4C06F59D.8090003@redhat.com> References: <2444005.34.1275519349838.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> <4C06F59D.8090003@redhat.com> Message-ID: <4C0709A2.30009@redhat.com> On 06/03/2010 10:21 AM, Ruediger Landmann wrote: > On 06/03/2010 08:52 AM, Jared Morgan wrote: >>> We removed this because we got disgusted with the complete inability of >>> writers to give any consideration or concern for translation. When >>> writers start displaying the ability to think of other people we will >>> add this back in. >> So, in summary, users should continue to use aliases for common >> publican publishing tasks. Not a problem. Thanks Jeff. > > The problem here is that "common publishing tasks" differ really > significantly between somebody writing their XML in English, somebody > writing their XML in French, and somebody translating any language to > any other language. Publican has a diverse user base, and it's > becoming more diverse all the time. I guess the reason why I'm > uncomfortable with this suggestion is that it privileges one group of > users over every other group. > > Furthermore, speaking only for myself, since I currently publish a > large number of docs in a large number of different languages, I > actually like the safety-net of when Publican tells me "you didn't say > which language you wanted, dufus". If Publican silently defaulted to > building (or worse, publishing!) the English version of a document > every time I forgot or mistyped the option, I would have made a > non-trivial number of non-trivial stuff-ups by now :) > > However, for anyone who is typically only ever building and publishing > in one language and wants to save themselves some keystrokes, aliasing > some commands is a neat solution. > > Cheers > Rudi > > I think this is an argument in favour of user configurable publican.defaults. That way everyone can set it up the way they want. From jfearn at redhat.com Fri Jun 4 01:10:52 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 04 Jun 2010 11:10:52 +1000 Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1275490473.5306.0.camel@localhost> References: <1275490473.5306.0.camel@localhost> Message-ID: <1275613852.2464.59.camel@localhost> On Wed, 2010-06-02 at 10:54 -0400, Jonathan Robie wrote: > I just installed Fedora 13, and I'm looking for fedora-redhat. Where can > I get it? Is it yum installable? (I found the source rpm.) Hi Jonathan, sorry for the lag in replying. The Red Hat brands don't ship on Fedora. Originally they were rejected for licensing reasons; no one in ECS has picked up the ball since the licensing change, so they still aren't in fedora. https://bugzilla.redhat.com/show_bug.cgi?id=427483 and https://bugzilla.redhat.com/show_bug.cgi?id=427484 Just in case you'd like to print them out and slap a few ECS people around the head with them. Building the brands from SVN is easy: $ svn co http://svn.fedorahosted.org/svn/publican/trunk/publican-redhat $ cd publican-redhat $ publican package --binary $ sudo yum localinstall tmp/rpm/noacrh/* Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Fri Jun 4 01:14:48 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 04 Jun 2010 11:14:48 +1000 Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1275613852.2464.59.camel@localhost> References: <1275490473.5306.0.camel@localhost> <1275613852.2464.59.camel@localhost> Message-ID: <1275614088.2464.60.camel@localhost> On Fri, 2010-06-04 at 11:10 +1000, Jeff Fearn wrote: > $ sudo yum localinstall tmp/rpm/noacrh/* Probably works better without the typo in arch, YMMV! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Fri Jun 4 01:19:25 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 04 Jun 2010 11:19:25 +1000 Subject: [publican-list] [PATCH] Add an early reference and link to the DocBook 5 standard. In-Reply-To: References: Message-ID: <1275614365.2464.65.camel@localhost> Hi Robert, I'd prefer not to do this since, AIUI, there are enough changes in DocBook 5 that it's going to take a fair effort to confirm the things we override in Publican actually work on DocBook 5. It will take a full audit of the style sheets and will probably lead to a different approach to how we override stuff. This will be the next major effort after the website merge is complete. Cheers, Jeff. On Wed, 2010-06-02 at 14:10 -0400, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day > > --- > > Index: publican/Users_Guide/en-US/Introduction.xml > =================================================================== > --- publican/Users_Guide/en-US/Introduction.xml (revision 1296) > +++ publican/Users_Guide/en-US/Introduction.xml (working copy) > @@ -6,7 +6,7 @@ > > Introduction > Introduction > - Publican is a tool for publishing material authored in DocBook XML. This guide explains how to create and build books and articles using Publican. It is not a general DocBook XML tutorial; refer to DocBook: The Definitive Guide by Norman Walsh and Leonard Muellner, available at for more general help with DocBook XML. > + Publican is a tool for publishing material authored in DocBook XML. This guide explains how to create and build books and articles using Publican. It is not a general DocBook XML tutorial; refer to DocBook: The Definitive Guide by Norman Walsh and Leonard Muellner for more general help with DocBook XML. The 4.x version of that book can be found at , while the more recently-released DocBook 5 standard can be found at . > > > Publican began life as an internal tool used by Red Hat's Documentation Group (now known as Engineering Content Services). On occasion, this legacy is visible. > > > rday > -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From mhideo at redhat.com Fri Jun 4 02:48:31 2010 From: mhideo at redhat.com (Mike Hideo) Date: Fri, 04 Jun 2010 12:48:31 +1000 Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1275613852.2464.59.camel@localhost> References: <1275490473.5306.0.camel@localhost> <1275613852.2464.59.camel@localhost> Message-ID: <4C08697F.6070507@redhat.com> On 06/04/2010 11:10 AM, Jeff Fearn wrote: > > Just in case you'd like to print them out and slap a few ECS people > around the head with them. and that would be me to slap around. :-) - Mike From mhideo at redhat.com Fri Jun 4 02:49:50 2010 From: mhideo at redhat.com (Mike Hideo) Date: Fri, 04 Jun 2010 12:49:50 +1000 Subject: [publican-list] RFC: Make -langs=en-US the default language for command line args In-Reply-To: <1275516484.2468.3.camel@localhost> References: <26439920.94.1275457677251.JavaMail.jmorgan@dhcp-1-169.bne.redhat.com> <1275516484.2468.3.camel@localhost> Message-ID: <4C0869CE.304@redhat.com> On 06/03/2010 08:08 AM, Jeff Fearn wrote: > On Wed, 2010-06-02 at 01:44 -0400, Jared Morgan wrote: >> I've seen a number of emails flying around that show some nice aliases >> for publican commands. I know many people have implemented their own >> aliases to quickly execute basic en-US book builds. > > We removed this because we got disgusted with the complete inability of > writers to give any consideration or concern for translation. When > writers start displaying the ability to think of other people we will > add this back in. > Again this is my inconsideration, please contact me directly. Apologies. - Mike From anross at redhat.com Fri Jun 4 03:09:12 2010 From: anross at redhat.com (Andrew Ross) Date: Thu, 3 Jun 2010 23:09:12 -0400 (EDT) Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1275613852.2464.59.camel@localhost> Message-ID: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> ----- "Jeff Fearn" wrote: > On Wed, 2010-06-02 at 10:54 -0400, Jonathan Robie wrote: > > I just installed Fedora 13, and I'm looking for fedora-redhat. Where > can > > I get it? Is it yum installable? (I found the source rpm.) > > Hi Jonathan, sorry for the lag in replying. > > The Red Hat brands don't ship on Fedora. Originally they were > rejected > for licensing reasons; no one in ECS has picked up the ball since the > licensing change, so they still aren't in fedora. > > https://bugzilla.redhat.com/show_bug.cgi?id=427483 > > and > > https://bugzilla.redhat.com/show_bug.cgi?id=427484 > > Just in case you'd like to print them out and slap a few ECS people > around the head with them. > I guess the reason is that people other than Red Hat employees use Fedora. IANAL, but we wouldn't want anyone outside the company to be able to produce and publish documents with the Red Hat brand on them ;) From jfearn at redhat.com Fri Jun 4 03:32:31 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Fri, 04 Jun 2010 13:32:31 +1000 Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <1275622351.2464.142.camel@localhost> On Thu, 2010-06-03 at 23:09 -0400, Andrew Ross wrote: > ----- "Jeff Fearn" wrote: > > > On Wed, 2010-06-02 at 10:54 -0400, Jonathan Robie wrote: > > > I just installed Fedora 13, and I'm looking for fedora-redhat. Where > > can > > > I get it? Is it yum installable? (I found the source rpm.) > > > > Hi Jonathan, sorry for the lag in replying. > > > > The Red Hat brands don't ship on Fedora. Originally they were > > rejected > > for licensing reasons; no one in ECS has picked up the ball since the > > licensing change, so they still aren't in fedora. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427483 > > > > and > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427484 > > > > Just in case you'd like to print them out and slap a few ECS people > > around the head with them. > > > > I guess the reason is There is nothing on the BZ's or anywhere to indicate this reasoning. > that people other than Red Hat employees use Fedora. IANAL, but we wouldn't want anyone outside the company to be able to produce and publish documents with the Red Hat brand on them ;) You cut off the part where it shows that it's trivial for anyone to do this right now. You could take the fedora brand and make it in to Red Hat or IBM or Microsoft with about 5 minutes of work. And it's fine if somebody, somewhere, wants to step up and state this publicly; they can also get their act together and provide Red Hat employees with a Fedora repository with this stuff in it so they don't get stuffed around all the time. Love and mung beans, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From rlerch at redhat.com Fri Jun 4 07:52:22 2010 From: rlerch at redhat.com (Ryan Lerch) Date: Fri, 04 Jun 2010 17:52:22 +1000 Subject: [publican-list] Announcing Endoculator -- A GUI for the publican toolchain Message-ID: <1275637942.25427.29.camel@graphics> Endoculator is a graphical user interface for managing and building documentation with the Publican Documentation Toolchain. Further information to come later, or you can just visit http://fedorahosted.org/endoculator/ and check out the initial version. cheers, ryanlerch From r.landmann at redhat.com Sun Jun 6 23:25:17 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Mon, 07 Jun 2010 09:25:17 +1000 Subject: [publican-list] 1.99 testing -- Translations of footnotes not appearing Message-ID: <4C0C2E5D.2090903@redhat.com> Hey Jeff, something seems to be going wrong with strings that contain when I build translated versions of books with 1.99. During POT generation, footnotes are pulled out into their own entries in PO files, thus: This is a test paragraph and this is a footnote becomes #. Tag: para #, no-c-format msgid "This is a test paragraph " msgstr "Dies ist ein Test Absatz " #. Tag: para #, no-c-format msgid "and this is a footnote" msgstr "und dies ist eine Fu?note" Is this by design? I think this treatment might make translation easier, especially where footnotes appear in the middle of strings. However, whether by design or not, when I build a book with a translation like this with 1.99.t84, Publican leaves the footnote (and the paragraph that contained it) in English. This problem isn't in 1.6.3, which just leaves footnotes in place in the msgid: #. Tag: para #, no-c-format msgid "This is a test paragraph and this is a footnote" msgstr "" Cheers Rudi From jfearn at redhat.com Mon Jun 7 00:16:56 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 07 Jun 2010 10:16:56 +1000 Subject: [publican-list] 1.99 testing -- Translations of footnotes not appearing In-Reply-To: <4C0C2E5D.2090903@redhat.com> References: <4C0C2E5D.2090903@redhat.com> Message-ID: <1275869816.2478.9.camel@localhost> This is a not deliberate. Maybe it was affected by the indexterm mods? Can you test with a build from the 1.6 branch? It probably behaves the same way. Cheers, Jeff. On Mon, 2010-06-07 at 09:25 +1000, Ruediger Landmann wrote: > Hey Jeff, something seems to be going wrong with strings that contain > when I build translated versions of books with 1.99. > > During POT generation, footnotes are pulled out into their own entries > in PO files, thus: > > > This is a test paragraph and this is a > footnote > > > becomes > > #. Tag: para > #, no-c-format > msgid "This is a test paragraph " > msgstr "Dies ist ein Test Absatz " > > #. Tag: para > #, no-c-format > msgid "and this is a footnote" > msgstr "und dies ist eine Fu?note" > > Is this by design? I think this treatment might make translation > easier, especially where footnotes appear in the middle of strings. > > However, whether by design or not, when I build a book with a > translation like this with 1.99.t84, Publican leaves the footnote (and > the paragraph that contained it) in English. > > This problem isn't in 1.6.3, which just leaves footnotes in place in the > msgid: > > #. Tag: para > #, no-c-format > msgid "This is a test paragraph and this is a > footnote" > msgstr "" > > Cheers > Rudi > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From r.landmann at redhat.com Mon Jun 7 01:05:11 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Mon, 07 Jun 2010 11:05:11 +1000 Subject: [publican-list] 1.99 testing -- Translations of footnotes not appearing In-Reply-To: <1275869816.2478.9.camel@localhost> References: <4C0C2E5D.2090903@redhat.com> <1275869816.2478.9.camel@localhost> Message-ID: <4C0C45C7.5010706@redhat.com> On 06/07/2010 10:16 AM, Jeff Fearn wrote: > This is a not deliberate. Maybe it was affected by the indexterm mods? > Can you test with a build from the 1.6 branch? It probably behaves the > same way. > Yeah, confirmed that 1.6.3.t95 does the same thing. From jfearn at redhat.com Mon Jun 7 01:23:28 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 07 Jun 2010 11:23:28 +1000 Subject: [publican-list] 1.99 testing -- Translations of footnotes not appearing In-Reply-To: <4C0C45C7.5010706@redhat.com> References: <4C0C2E5D.2090903@redhat.com> <1275869816.2478.9.camel@localhost> <4C0C45C7.5010706@redhat.com> Message-ID: <1275873808.2478.12.camel@localhost> On Mon, 2010-06-07 at 11:05 +1000, Ruediger Landmann wrote: > On 06/07/2010 10:16 AM, Jeff Fearn wrote: > > This is a not deliberate. Maybe it was affected by the indexterm mods? > > Can you test with a build from the 1.6 branch? It probably behaves the > > same way. > > > > Yeah, confirmed that 1.6.3.t95 does the same thing. Checked in fix to branch and trunk. indextern should still be working for it's various uses. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From bugzilla at redhat.com Mon Jun 7 01:59:58 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 Jun 2010 21:59:58 -0400 Subject: [publican-list] [Bug 599258] table borders on in html/html-single In-Reply-To: References: Message-ID: <201006070159.o571xw2H016934@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=599258 Nick Bebout changed: What |Removed |Added ---------------------------------------------------------------------------- CC|nb at fedoraproject.org | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From dmison at redhat.com Mon Jun 7 02:29:48 2010 From: dmison at redhat.com (dmison at redhat.com) Date: Sun, 6 Jun 2010 22:29:48 -0400 (EDT) Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1275622351.2464.142.camel@localhost> References: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1275622351.2464.142.camel@localhost> Message-ID: Actually a repo was setup on downtown.englab.bne.redhat.com for this purpose. Apparently complications in building the rpms for multiple versions was an issue that put it on hold for a time. On 04/06/2010, at 1:33 PM, Jeff Fearn wrote: > publicly; they can also get their act together and provide Red Hat > employees with a Fedora repository with this stuff in it so they don't > get stuffed around all the time. -- Darrin Mison Sent from the Future! (with my iPad) From jfearn at redhat.com Mon Jun 7 02:45:41 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 07 Jun 2010 12:45:41 +1000 Subject: [publican-list] publican-redhat for F13? In-Reply-To: References: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1275622351.2464.142.camel@localhost> Message-ID: <1275878741.2478.29.camel@localhost> On Sun, 2010-06-06 at 22:29 -0400, dmison at redhat.com wrote: > Actually a repo was setup on downtown.englab.bne.redhat.com for this purpose. Apparently complications in building the rpms for multiple versions was an issue that put it on hold for a time. So ... act not together, people still getting stuffed around? I'm sure you had a point, but I've missed it. > On 04/06/2010, at 1:33 PM, Jeff Fearn wrote: > > publicly; they can also get their act together and provide Red Hat > > employees with a Fedora repository with this stuff in it so they don't > > get stuffed around all the time. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From r.landmann at redhat.com Mon Jun 7 02:48:38 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Mon, 07 Jun 2010 12:48:38 +1000 Subject: [publican-list] 1.99 testing -- Translations of footnotes not appearing In-Reply-To: <1275873808.2478.12.camel@localhost> References: <4C0C2E5D.2090903@redhat.com> <1275869816.2478.9.camel@localhost> <4C0C45C7.5010706@redhat.com> <1275873808.2478.12.camel@localhost> Message-ID: <4C0C5E06.7010804@redhat.com> On 06/07/2010 11:23 AM, Jeff Fearn wrote: > > Checked in fix to branch and trunk. indextern should still be working > for it's various uses. > Thanks Jeff! Translations of footnotes and their containing elements working fine again in 1.99.t90. Cheers Rudi From dmison at redhat.com Mon Jun 7 03:03:21 2010 From: dmison at redhat.com (dmison at redhat.com) Date: Sun, 6 Jun 2010 23:03:21 -0400 (EDT) Subject: [publican-list] publican-redhat for F13? In-Reply-To: <1275878741.2478.29.camel@localhost> References: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1275622351.2464.142.camel@localhost> <1275878741.2478.29.camel@localhost> Message-ID: <79499CEB-69A4-4716-B80D-E28D13B98B16@redhat.com> Possibly the point was "if someone knows the solution to that problem..." :-) On 07/06/2010, at 12:46 PM, Jeff Fearn wrote: > On Sun, 2010-06-06 at 22:29 -0400, dmison at redhat.com wrote: >> Actually a repo was setup on downtown.englab.bne.redhat.com for this purpose. Apparently complications in building the rpms for multiple versions was an issue that put it on hold for a time. > > So ... act not together, people still getting stuffed around? > > I'm sure you had a point, but I've missed it. -- Darrin Mison Sent from the Future! (with my iPad) From jfearn at redhat.com Mon Jun 7 03:25:26 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 07 Jun 2010 13:25:26 +1000 Subject: [publican-list] publican-redhat for F13? In-Reply-To: <79499CEB-69A4-4716-B80D-E28D13B98B16@redhat.com> References: <1158122575.2418701275620952306.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1275622351.2464.142.camel@localhost> <1275878741.2478.29.camel@localhost> <79499CEB-69A4-4716-B80D-E28D13B98B16@redhat.com> Message-ID: <1275881126.2478.37.camel@localhost> On Sun, 2010-06-06 at 23:03 -0400, dmison at redhat.com wrote: > Possibly the point was "if someone knows the solution to that problem..." :-) Is it "sack people who don't use the CSB and can't support themselves"? Cause that's my favorite. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From bugzilla at redhat.com Mon Jun 7 16:08:33 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Jun 2010 12:08:33 -0400 Subject: [publican-list] [Bug 592823] should not break a paragraph for translation In-Reply-To: References: Message-ID: <201006071608.o57G8X3w003364@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592823 --- Comment #11 from RHEL Product and Program Management 2010-06-07 12:08:25 EDT --- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Jun 9 01:49:09 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 Jun 2010 21:49:09 -0400 Subject: [publican-list] [Bug 599258] table borders on in html/html-single In-Reply-To: References: Message-ID: <201006090149.o591n9gm013557@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=599258 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ON_DEV --- Comment #4 from Jeff Fearn 2010-06-08 21:49:08 EDT --- No complaints, so everyone agrees! Hid borders of simplelist in HTML. Fixed in build 1.6.3-0.t97 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From lbrindle at redhat.com Wed Jun 9 06:25:40 2010 From: lbrindle at redhat.com (Lana Brindley) Date: Wed, 09 Jun 2010 16:25:40 +1000 Subject: [publican-list] Building local PDF Message-ID: <4C0F33E4.40000@redhat.com> When I try to build a pdf locally using: $ publican build --lang=en-US --format=pdf Publican appears to work correctly until reporting an error: Jun 9, 2010 4:22:38 p.m. org.apache.fop.cli.Main startFOP SEVERE: Exception java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:196) Upon checking the PDF folder, it's empty. What am I doing wrong? L -- Lana Brindley Content Author II Engineering Content Services +61 7 3514 8178 - ext (85) 88178 RHEL5 RHCT: 605008757717273 "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use hammer." -- IBM maintenance manual, 1975 -------------- next part -------------- A non-text attachment was scrubbed... Name: lbrindle.vcf Type: text/x-vcard Size: 976 bytes Desc: not available URL: From misty at redhat.com Wed Jun 9 06:28:32 2010 From: misty at redhat.com (Misty Stanley-Jones) Date: Wed, 9 Jun 2010 02:28:32 -0400 (EDT) Subject: [publican-list] Building local PDF In-Reply-To: <4C0F33E4.40000@redhat.com> Message-ID: <286488857.107731276064912412.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> I had this error when I didn't have the JDK installed. Make sure you have it installed and JAVA_HOME is set properly. :) ----- "Lana Brindley" wrote: > From: "Lana Brindley" > To: "publican" > Sent: Wednesday, June 9, 2010 4:25:40 PM GMT +10:00 Brisbane > Subject: [publican-list] Building local PDF > > When I try to build a pdf locally using: > $ publican build --lang=en-US --format=pdf > > Publican appears to work correctly until reporting an error: > Jun 9, 2010 4:22:38 p.m. org.apache.fop.cli.Main startFOP > SEVERE: Exception > java.lang.NullPointerException > at > org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217) > at > org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) > at org.apache.fop.cli.Main.startFOP(Main.java:166) > at org.apache.fop.cli.Main.main(Main.java:196) > > Upon checking the PDF folder, it's empty. > > What am I doing wrong? > > L > > -- > Lana Brindley > Content Author II > Engineering Content Services > +61 7 3514 8178 - ext (85) 88178 > RHEL5 RHCT: 605008757717273 > > "All parts should go together without forcing. You must remember that > the parts you are reassembling were disassembled by you. Therefore, > if > you can't get them together again, there must be a reason. By all > means, do not use hammer." -- IBM maintenance manual, 1975 > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican -- Misty Stanley-Jones Content Author, ECS 1/193 North Quay, Brisbane QLD 4000 Ph: +61 7 3514 8105 Mobile: +61 429 595 932 Time Zone: GMT+10 From jwulf at redhat.com Wed Jun 9 07:04:01 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 09 Jun 2010 17:04:01 +1000 Subject: [publican-list] Publican create default Message-ID: <4C0F3CE1.3080005@redhat.com> At the moment when I issue a publican create command without specifying --lang=, it creates a book using en-US as the language. Could we make it return an error if no language is specified? Alternatively, could we make the other publican commands assume en-US if no language is specified, to make this behaviour consistent? - Josh From jwulf at redhat.com Wed Jun 9 08:43:08 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Wed, 09 Jun 2010 18:43:08 +1000 Subject: [publican-list] --lang vs --langs Message-ID: <4C0F541C.6020604@redhat.com> Another thing I notice is that publican build takes --langs as an argument, while publican package takes --lang. Is this because "package" can only do one language at a time, while "build" can do multiple? From lbrindle at redhat.com Wed Jun 9 20:11:52 2010 From: lbrindle at redhat.com (Lana Brindley) Date: Thu, 10 Jun 2010 06:11:52 +1000 Subject: [publican-list] Building local PDF In-Reply-To: <286488857.107731276064912412.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <286488857.107731276064912412.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4C0FF588.3010400@redhat.com> Installed the JDK and it's all working now. Thanks! Lana On 06/09/2010 04:28 PM, Misty Stanley-Jones wrote: > I had this error when I didn't have the JDK installed. Make sure you have it installed and JAVA_HOME is set properly. :) > > ----- "Lana Brindley" wrote: > >> From: "Lana Brindley" >> To: "publican" >> Sent: Wednesday, June 9, 2010 4:25:40 PM GMT +10:00 Brisbane >> Subject: [publican-list] Building local PDF >> >> When I try to build a pdf locally using: >> $ publican build --lang=en-US --format=pdf >> >> Publican appears to work correctly until reporting an error: >> Jun 9, 2010 4:22:38 p.m. org.apache.fop.cli.Main startFOP >> SEVERE: Exception >> java.lang.NullPointerException >> at >> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217) >> at >> org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) >> at org.apache.fop.cli.Main.startFOP(Main.java:166) >> at org.apache.fop.cli.Main.main(Main.java:196) >> >> Upon checking the PDF folder, it's empty. >> >> What am I doing wrong? >> >> L >> >> -- >> Lana Brindley >> Content Author II >> Engineering Content Services >> +61 7 3514 8178 - ext (85) 88178 >> RHEL5 RHCT: 605008757717273 >> >> "All parts should go together without forcing. You must remember that >> the parts you are reassembling were disassembled by you. Therefore, >> if >> you can't get them together again, there must be a reason. By all >> means, do not use hammer." -- IBM maintenance manual, 1975 >> >> _______________________________________________ >> publican-list mailing list >> publican-list at redhat.com >> https://www.redhat.com/mailman/listinfo/publican-list >> Wiki: https://fedorahosted.org/publican > -- Lana Brindley Content Author II Engineering Content Services +61 7 3514 8178 - ext (85) 88178 RHEL5 RHCT: 605008757717273 "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use hammer." -- IBM maintenance manual, 1975 -------------- next part -------------- A non-text attachment was scrubbed... Name: lbrindle.vcf Type: text/x-vcard Size: 976 bytes Desc: not available URL: From jfearn at redhat.com Wed Jun 9 22:55:06 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Thu, 10 Jun 2010 08:55:06 +1000 Subject: [publican-list] Publican create default In-Reply-To: <4C0F3CE1.3080005@redhat.com> References: <4C0F3CE1.3080005@redhat.com> Message-ID: <4C101BCA.1090100@redhat.com> Joshua Wulf wrote: > At the moment when I issue a publican create command without specifying > --lang=, it creates a book using en-US as the language. Could we > make it return an error if no language is specified? Sure, please open a bug, please include any other fields in create book you think shouldn't be defaulted. Currently the following values have defaults: version edition product brand lang type Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Wed Jun 9 22:56:05 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Thu, 10 Jun 2010 08:56:05 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C0F541C.6020604@redhat.com> References: <4C0F541C.6020604@redhat.com> Message-ID: <4C101C05.8010205@redhat.com> Joshua Wulf wrote: > Another thing I notice is that publican build takes --langs as an > argument, while publican package takes --lang. > > Is this because "package" can only do one language at a time, while > "build" can do multiple? This is correct. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Thu Jun 10 04:03:39 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Jun 2010 00:03:39 -0400 Subject: [publican-list] [Bug 559787] duplicate Revision History headings In-Reply-To: References: Message-ID: <201006100403.o5A43dT3024715@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=559787 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ON_DEV --- Comment #3 from Jeff Fearn 2010-06-10 00:03:34 EDT --- hid table header. Fixed in build: 1.6.3-0.t101 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From jhradile at redhat.com Thu Jun 10 12:41:46 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Thu, 10 Jun 2010 14:41:46 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C101C05.8010205@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> Message-ID: <4C10DD8A.2020708@redhat.com> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: > Joshua Wulf wrote: >> Another thing I notice is that publican build takes --langs as an >> argument, while publican package takes --lang. >> >> Is this because "package" can only do one language at a time, while >> "build" can do multiple? > > This is correct. > > Cheers, Jeff. > That makes sense to me. However, did you consider allowing both --lang and --langs interchangeably? I mean, it is perfectly OK to document only one of them where appropriate, but it will definitely spare us all some otherwise easily avoidable errors. Regards, -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jwulf at redhat.com Thu Jun 10 12:46:25 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Thu, 10 Jun 2010 22:46:25 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C10DD8A.2020708@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> Message-ID: <4C10DEA1.1000604@redhat.com> On 06/10/2010 10:41 PM, Jaromir Hradilek wrote: > On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >> Joshua Wulf wrote: >>> Another thing I notice is that publican build takes --langs as an >>> argument, while publican package takes --lang. >>> >>> Is this because "package" can only do one language at a time, while >>> "build" can do multiple? >> >> This is correct. >> >> Cheers, Jeff. >> > > That makes sense to me. However, did you consider allowing both --lang > and --langs interchangeably? I mean, it is perfectly OK to document > only one of them where appropriate, but it will definitely spare us > all some otherwise easily avoidable errors. > > Regards, oooh, that's a good idea! -- Joshua J Wulf Engineering Content Services Red Hat Asia Pacific eml: jwulf at redhat.com tel: +61 (0)7 3514 8140 mob: +61 (0)431 929 675 tmz: GMT +10 (0) - omit when dialling internationally From mhideo at redhat.com Thu Jun 10 13:35:31 2010 From: mhideo at redhat.com (mhideo at redhat.com) Date: Thu, 10 Jun 2010 09:35:31 -0400 (EDT) Subject: [publican-list] --lang vs --langs In-Reply-To: <4C10DD8A.2020708@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> Message-ID: <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> On 10/06/2010, at 10:42 PM, Jaromir Hradilek wrote: > On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >> Joshua Wulf wrote: >>> Another thing I notice is that publican build takes --langs as an >>> argument, while publican package takes --lang. >>> >>> Is this because "package" can only do one language at a time, while >>> "build" can do multiple? >> >> This is correct. >> >> Cheers, Jeff. >> > > That makes sense to me. However, did you consider allowing both -- > lang and --langs interchangeably? I mean, it is perfectly OK to > document only one of them where appropriate, but it will definitely > spare us all some otherwise easily avoidable errors. > Feel free to submit a patch :-) > Regards, > -- > Jaromir Hradilek > Associate Content Author > Engineering Content Services > > Red Hat Czech s. r. o. > Purkynova 99, 612 45 Brno > Phone: +420 532 294 326 > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From jhradile at redhat.com Thu Jun 10 15:49:23 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Thu, 10 Jun 2010 17:49:23 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> Message-ID: <4C110983.2040208@redhat.com> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: > On 10/06/2010, at 10:42 PM, Jaromir Hradilek wrote: >> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>> Joshua Wulf wrote: >>>> Another thing I notice is that publican build takes --langs as an >>>> argument, while publican package takes --lang. >>>> >>>> Is this because "package" can only do one language at a time, while >>>> "build" can do multiple? >>> >>> This is correct. >>> >>> Cheers, Jeff. >>> >> >> That makes sense to me. However, did you consider allowing both --lang >> and --langs interchangeably? I mean, it is perfectly OK to document >> only one of them where appropriate, but it will definitely spare us >> all some otherwise easily avoidable errors. >> > > Feel free to submit a patch :-) See the attachment! ;-) (Created by typing `diff publican/bin/publican publican/bin/publican.orig > publican.diff' in the root directory of the publican's latest SVN snapshot.) However, I didn't have much time to really familiarize myself with the source code, so there is probably a smarter way to do this. -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: publican.diff URL: From jhradile at redhat.com Thu Jun 10 21:36:01 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Thu, 10 Jun 2010 23:36:01 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C110983.2040208@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> Message-ID: <4C115AC1.4090900@redhat.com> On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: > On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: >> On 10/06/2010, at 10:42 PM, Jaromir Hradilek wrote: >>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>>> Joshua Wulf wrote: >>>>> Another thing I notice is that publican build takes --langs as an >>>>> argument, while publican package takes --lang. >>>>> >>>>> Is this because "package" can only do one language at a time, while >>>>> "build" can do multiple? >>>> >>>> This is correct. >>>> >>>> Cheers, Jeff. >>>> >>> >>> That makes sense to me. However, did you consider allowing both --lang >>> and --langs interchangeably? I mean, it is perfectly OK to document >>> only one of them where appropriate, but it will definitely spare us >>> all some otherwise easily avoidable errors. >>> >> >> Feel free to submit a patch :-) > > See the attachment! ;-) (Created by typing `diff publican/bin/publican > publican/bin/publican.orig > publican.diff' in the root directory of the > publican's latest SVN snapshot.) > > However, I didn't have much time to really familiarize myself with the > source code, so there is probably a smarter way to do this. Well, the smarter way would be to add the alias directly to the Getopt::Long options, and then make all functions use the same form, but I did not want to disturb the semantic distinction between the singular and plural forms in the code. -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jfearn at redhat.com Thu Jun 10 22:33:14 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 11 Jun 2010 08:33:14 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C115AC1.4090900@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> Message-ID: <4C11682A.2090404@redhat.com> Jaromir Hradilek wrote: > On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: >> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: >>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek >>> wrote: >>>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>>>> Joshua Wulf wrote: >>>>>> Another thing I notice is that publican build takes --langs as an >>>>>> argument, while publican package takes --lang. >>>>>> >>>>>> Is this because "package" can only do one language at a time, while >>>>>> "build" can do multiple? >>>>> >>>>> This is correct. >>>>> >>>>> Cheers, Jeff. >>>>> >>>> >>>> That makes sense to me. However, did you consider allowing both --lang >>>> and --langs interchangeably? I mean, it is perfectly OK to document >>>> only one of them where appropriate, but it will definitely spare us >>>> all some otherwise easily avoidable errors. >>>> >>> >>> Feel free to submit a patch :-) >> >> See the attachment! ;-) (Created by typing `diff publican/bin/publican >> publican/bin/publican.orig > publican.diff' in the root directory of the >> publican's latest SVN snapshot.) >> >> However, I didn't have much time to really familiarize myself with the >> source code, so there is probably a smarter way to do this. > > Well, the smarter way would be to add the alias directly to the > Getopt::Long options, and then make all functions use the same form, but > I did not want to disturb the semantic distinction between the singular > and plural forms in the code. > Since they parameters do not actually do the same thing ATM, your patch needs to include: A: Changes to the Publican::* modules to handle the option they don't currently support, either lang or langs, they only handle one ATM. B: Test cases to prove your changes work. C: Update the documentation A involves either adding an extra parameter to the functions and making sure one of them is supplied, or modifying bin/publican to convert from between lang and langs as required. B involves adding new parameter combinations to publican/t/900.publican.t C: Update the POD and maketexts in bin/publican and the User Guide. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From mhideo at redhat.com Thu Jun 10 22:41:07 2010 From: mhideo at redhat.com (Mike Hideo) Date: Fri, 11 Jun 2010 08:41:07 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C11682A.2090404@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> Message-ID: <1276209667.2226.4.camel@localhost> On Fri, 2010-06-11 at 08:33 +1000, Jeffrey Fearn wrote: > Jaromir Hradilek wrote: > > Since they parameters do not actually do the same thing ATM, your patch > needs to include: > > A: Changes to the Publican::* modules to handle the option they don't > currently support, either lang or langs, they only handle one ATM. > > B: Test cases to prove your changes work. > > C: Update the documentation > > A involves either adding an extra parameter to the functions and making > sure one of them is supplied, or modifying bin/publican to convert from > between lang and langs as required. > > B involves adding new parameter combinations to publican/t/900.publican.t > > C: Update the POD and maketexts in bin/publican and the User Guide. > Jaromir, good start. Can you add something to the publican wiki about code submission requirements that include the info above? Might want to write it up real sweet-like. Cheers, mike From r.landmann at redhat.com Thu Jun 10 22:46:14 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Fri, 11 Jun 2010 08:46:14 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C115AC1.4090900@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> Message-ID: <4C116B36.60203@redhat.com> On 06/11/2010 07:36 AM, Jaromir Hradilek wrote: > > Well, the smarter way would be to add the alias directly to the > Getopt::Long options, and then make all functions use the same form, > but I did not want to disturb the semantic distinction between the > singular and plural forms in the code. > Actually, I find this is a valuable semantic distinction for me as a user as well. Because you can perform some actions on multiple languages at a time, and some actions on only one language at a time, having to type the correct option helps me keep these separate in my mind. If the --lang and --langs options were to be mashed together, we'd really need an error message for the actions that can only be performed on one language at a time that says something like "You can only package one language at a time." Then of course people might wonder why we have an option called "langs" that only allows you to perform an action on a single language. Maybe we should just leave it as it is. Cheers Rudi From jfearn at redhat.com Thu Jun 10 22:54:39 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 11 Jun 2010 08:54:39 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276209667.2226.4.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <1276209667.2226.4.camel@localhost> Message-ID: <4C116D2F.1060306@redhat.com> Mike Hideo wrote: > On Fri, 2010-06-11 at 08:33 +1000, Jeffrey Fearn wrote: >> Jaromir Hradilek wrote: > >> Since they parameters do not actually do the same thing ATM, your patch >> needs to include: >> >> A: Changes to the Publican::* modules to handle the option they don't >> currently support, either lang or langs, they only handle one ATM. >> >> B: Test cases to prove your changes work. >> >> C: Update the documentation >> >> A involves either adding an extra parameter to the functions and making >> sure one of them is supplied, or modifying bin/publican to convert from >> between lang and langs as required. >> >> B involves adding new parameter combinations to publican/t/900.publican.t >> >> C: Update the POD and maketexts in bin/publican and the User Guide. >> > > Jaromir, good start. Can you add something to the publican wiki about > code submission requirements that include the info above? https://fedorahosted.org/publican/wiki/WikiStart#SubmittingPatches Might want to > write it up real sweet-like. Feel free to convert my coder scribblings in to enthralling prose! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jhradile at redhat.com Thu Jun 10 23:19:31 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Fri, 11 Jun 2010 01:19:31 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C11682A.2090404@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> Message-ID: <4C117303.9090003@redhat.com> On 06/11/2010 12:33 AM, Jeffrey Fearn wrote: > Jaromir Hradilek wrote: >> On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: >>> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: >>>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek >>>> wrote: >>>>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>>>>> Joshua Wulf wrote: >>>>>>> Another thing I notice is that publican build takes --langs as an >>>>>>> argument, while publican package takes --lang. >>>>>>> >>>>>>> Is this because "package" can only do one language at a time, while >>>>>>> "build" can do multiple? >>>>>> >>>>>> This is correct. >>>>>> >>>>>> Cheers, Jeff. >>>>>> >>>>> >>>>> That makes sense to me. However, did you consider allowing both --lang >>>>> and --langs interchangeably? I mean, it is perfectly OK to document >>>>> only one of them where appropriate, but it will definitely spare us >>>>> all some otherwise easily avoidable errors. >>>>> >>>> >>>> Feel free to submit a patch :-) >>> >>> See the attachment! ;-) (Created by typing `diff publican/bin/publican >>> publican/bin/publican.orig > publican.diff' in the root directory of the >>> publican's latest SVN snapshot.) >>> >>> However, I didn't have much time to really familiarize myself with the >>> source code, so there is probably a smarter way to do this. >> >> Well, the smarter way would be to add the alias directly to the >> Getopt::Long options, and then make all functions use the same form, >> but I did not want to disturb the semantic distinction between the >> singular and plural forms in the code. >> > > Since they parameters do not actually do the same thing ATM, your patch > needs to include: > > A: Changes to the Publican::* modules to handle the option they don't > currently support, either lang or langs, they only handle one ATM. > > A involves either adding an extra parameter to the functions and making > sure one of them is supplied, or modifying bin/publican to convert from > between lang and langs as required. I believe I already did the latter as you can see near the very end of my patch. I avoided making any changes in Publican::*, because I am convinced this is purely a matter of the option parsing and should be handled by bin/publican itself. Furthermore, making these changes in Builder.pm would with no doubt worsen its readability. > B: Test cases to prove your changes work. > > B involves adding new parameter combinations to publican/t/900.publican.t I will take care of that, thanks. > C: Update the documentation > > C: Update the POD and maketexts in bin/publican and the User Guide. Well, as Rudi pointed out somewhere below, I completely agree that the distinction between plural and singular form is not only important for the user, but that it should stay the way it is as I suggested in my initial response. You see, the trouble with plural and singular forms is that they are just too much alike, especially when they have basically the same meaning, and even if you are well aware of the difference between them, as a human being that uses publican routinely every single day, you are bound to mistype now and then. What I wanted to accomplish with this was to avoid these unnecessary errors that don't really help you, but slow you down a lot. No worries, publican will still complain whenever you supply multiple languages where only one is allowed. Anyway, thanks for your fast reply, Jeff. -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jhradile at redhat.com Thu Jun 10 23:32:23 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Fri, 11 Jun 2010 01:32:23 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276209667.2226.4.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <1276209667.2226.4.camel@localhost> Message-ID: <4C117607.3050403@redhat.com> On 06/11/2010 12:41 AM, Mike Hideo wrote: > On Fri, 2010-06-11 at 08:33 +1000, Jeffrey Fearn wrote: >> Jaromir Hradilek wrote: > >> >> Since they parameters do not actually do the same thing ATM, your patch >> needs to include: >> >> A: Changes to the Publican::* modules to handle the option they don't >> currently support, either lang or langs, they only handle one ATM. >> >> B: Test cases to prove your changes work. >> >> C: Update the documentation >> >> A involves either adding an extra parameter to the functions and making >> sure one of them is supplied, or modifying bin/publican to convert from >> between lang and langs as required. >> >> B involves adding new parameter combinations to publican/t/900.publican.t >> >> C: Update the POD and maketexts in bin/publican and the User Guide. >> > > Jaromir, good start. Can you add something to the publican wiki about > code submission requirements that include the info above? Might want to > write it up real sweet-like. > > Cheers, > mike Sure Mike, I'll take a look at that tomorrow morning. Regards, -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jfearn at redhat.com Thu Jun 10 23:55:48 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 11 Jun 2010 09:55:48 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C117303.9090003@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> Message-ID: <4C117B84.4090308@redhat.com> Jaromir Hradilek wrote: > On 06/11/2010 12:33 AM, Jeffrey Fearn wrote: >> Jaromir Hradilek wrote: >>> On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: >>>> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: >>>>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek >>>>> wrote: >>>>>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>>>>>> Joshua Wulf wrote: >>>>>>>> Another thing I notice is that publican build takes --langs as an >>>>>>>> argument, while publican package takes --lang. >>>>>>>> >>>>>>>> Is this because "package" can only do one language at a time, while >>>>>>>> "build" can do multiple? >>>>>>> >>>>>>> This is correct. >>>>>>> >>>>>>> Cheers, Jeff. >>>>>>> >>>>>> >>>>>> That makes sense to me. However, did you consider allowing both >>>>>> --lang >>>>>> and --langs interchangeably? I mean, it is perfectly OK to document >>>>>> only one of them where appropriate, but it will definitely spare us >>>>>> all some otherwise easily avoidable errors. >>>>>> >>>>> >>>>> Feel free to submit a patch :-) >>>> >>>> See the attachment! ;-) (Created by typing `diff publican/bin/publican >>>> publican/bin/publican.orig > publican.diff' in the root directory of >>>> the >>>> publican's latest SVN snapshot.) >>>> >>>> However, I didn't have much time to really familiarize myself with the >>>> source code, so there is probably a smarter way to do this. >>> >>> Well, the smarter way would be to add the alias directly to the >>> Getopt::Long options, and then make all functions use the same form, >>> but I did not want to disturb the semantic distinction between the >>> singular and plural forms in the code. >>> >> >> Since they parameters do not actually do the same thing ATM, your patch >> needs to include: >> >> A: Changes to the Publican::* modules to handle the option they don't >> currently support, either lang or langs, they only handle one ATM. > > > > A involves either adding an extra parameter to the functions and making > > sure one of them is supplied, or modifying bin/publican to convert from > > between lang and langs as required. > > I believe I already did the latter as you can see near the very end of > my patch. If you are going to allow people to pass in --langs as a valid parameter then you have to support supplying multiple languages, not just cater for people providing a single language with --langs. You can't just pass in multiple languages to a function expecting a single language, you need to either flag it as an error before you get to the function, or split them up and loop around the call, or modify the function to handle multiple languages. I expect if you pass multiple languages in to some functions that expect a single language you will get odd message, maybe like: en-US,fr-FR is not a valid language or it may work, and you will have one fancy language code! Simply copying langs to lang isn't robust, at the least it will lead to people asking "if I can use --langs why can't I supply more than one language?" Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Thu Jun 10 23:57:36 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 11 Jun 2010 09:57:36 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C117607.3050403@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <1276209667.2226.4.camel@localhost> <4C117607.3050403@redhat.com> Message-ID: <4C117BF0.4090308@redhat.com> Jaromir Hradilek wrote: >> Jaromir, good start. Can you add something to the publican wiki about >> code submission requirements that include the info above? Might want to >> write it up real sweet-like. >> >> Cheers, >> mike > > Sure Mike, I'll take a look at that tomorrow morning. Do you have a FAS account? You will need to let me know what your FAS user name is so I can give you write access to the wiki. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Fri Jun 11 00:15:44 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 11 Jun 2010 10:15:44 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C117BF0.4090308@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <1276209667.2226.4.camel@localhost> <4C117607.3050403@redhat.com> <4C117BF0.4090308@redhat.com> Message-ID: <4C118030.4030708@redhat.com> Jeffrey Fearn wrote: > Jaromir Hradilek wrote: >>> Jaromir, good start. Can you add something to the publican wiki about >>> code submission requirements that include the info above? Might want to >>> write it up real sweet-like. >>> >>> Cheers, >>> mike >> >> Sure Mike, I'll take a look at that tomorrow morning. > > Do you have a FAS account? You will need to let me know what your FAS > user name is so I can give you write access to the wiki. I think the wiki is actually setup so any authenticated user can edit it, maybe someone with a a FAS account and no special permissions can give it a shot? Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From rlerch at redhat.com Fri Jun 11 01:21:42 2010 From: rlerch at redhat.com (Ryan Lerch) Date: Fri, 11 Jun 2010 11:21:42 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C116B36.60203@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C116B36.60203@redhat.com> Message-ID: <1276219302.25707.5.camel@graphics> On Fri, 2010-06-11 at 08:46 +1000, Ruediger Landmann wrote: > On 06/11/2010 07:36 AM, Jaromir Hradilek wrote: > > Actually, I find this is a valuable semantic distinction for me as a > user as well. Because you can perform some actions on multiple languages > at a time, and some actions on only one language at a time, having to > type the correct option helps me keep these separate in my mind. > > If the --lang and --langs options were to be mashed together, we'd > really need an error message for the actions that can only be performed > on one language at a time that says something like "You can only package > one language at a time." > > Then of course people might wonder why we have an option called "langs" > that only allows you to perform an action on a single language. > > Maybe we should just leave it as it is. > I agree, the first time i used "publican package" i tried to specify multiple langs with "langs=" but it failed. If the commands were mashed together, what i tried to do would still fail, as i can only specify one lang when building a package. allowing "langs=" to work will only confuse further. my 2 cents: keep the distinction between langs= and lang=. cheers, ryanlerch From mylists at teambla.com Fri Jun 11 07:38:27 2010 From: mylists at teambla.com (Bram Vogelaar) Date: Fri, 11 Jun 2010 09:38:27 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276219302.25707.5.camel@graphics> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C116B36.60203@redhat.com> <1276219302.25707.5.camel@graphics> Message-ID: my +1 for this semantic distinction between single and multiple languages options. This way the option to use is sort of a clue bat to guide you to correctly formulating the command to run. bram On 11 Jun 2010, at 03:21, Ryan Lerch wrote: > On Fri, 2010-06-11 at 08:46 +1000, Ruediger Landmann wrote: >> On 06/11/2010 07:36 AM, Jaromir Hradilek wrote: >> >> Actually, I find this is a valuable semantic distinction for me as a >> user as well. Because you can perform some actions on multiple languages >> at a time, and some actions on only one language at a time, having to >> type the correct option helps me keep these separate in my mind. >> >> If the --lang and --langs options were to be mashed together, we'd >> really need an error message for the actions that can only be performed >> on one language at a time that says something like "You can only package >> one language at a time." >> >> Then of course people might wonder why we have an option called "langs" >> that only allows you to perform an action on a single language. >> >> Maybe we should just leave it as it is. >> > > I agree, > > the first time i used "publican package" i tried to specify multiple > langs with "langs=" but it failed. If the commands were mashed together, > what i tried to do would still fail, as i can only specify one lang when > building a package. allowing "langs=" to work will only confuse further. > > my 2 cents: keep the distinction between langs= and lang=. > > cheers, > ryanlerch > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican From jhradile at redhat.com Fri Jun 11 09:21:42 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Fri, 11 Jun 2010 11:21:42 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C118030.4030708@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <1276209667.2226.4.camel@localhost> <4C117607.3050403@redhat.com> <4C117BF0.4090308@redhat.com> <4C118030.4030708@redhat.com> Message-ID: <4C120026.80109@redhat.com> On 06/11/2010 02:15 AM, Jeffrey Fearn wrote: > Jeffrey Fearn wrote: >> Jaromir Hradilek wrote: >>>> Jaromir, good start. Can you add something to the publican wiki about >>>> code submission requirements that include the info above? Might want to >>>> write it up real sweet-like. >>>> >>>> Cheers, >>>> mike >>> >>> Sure Mike, I'll take a look at that tomorrow morning. >> >> Do you have a FAS account? You will need to let me know what your FAS >> user name is so I can give you write access to the wiki. > > I think the wiki is actually setup so any authenticated user can edit > it, maybe someone with a a FAS account and no special permissions can > give it a shot? > > Cheers, Jeff. Hi Jeff, I just successfully edited the page with my ordinary Fedora account, so no special permissions seem to be required. -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jhradile at redhat.com Fri Jun 11 09:35:08 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Fri, 11 Jun 2010 11:35:08 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C117B84.4090308@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> Message-ID: <4C12034C.2010905@redhat.com> On 06/11/2010 01:55 AM, Jeffrey Fearn wrote: > Jaromir Hradilek wrote: >> On 06/11/2010 12:33 AM, Jeffrey Fearn wrote: >>> Jaromir Hradilek wrote: >>>> On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: >>>>> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: >>>>>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek >>>>>> wrote: >>>>>>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>>>>>>> Joshua Wulf wrote: >>>>>>>>> Another thing I notice is that publican build takes --langs as an >>>>>>>>> argument, while publican package takes --lang. >>>>>>>>> >>>>>>>>> Is this because "package" can only do one language at a time, >>>>>>>>> while >>>>>>>>> "build" can do multiple? >>>>>>>> >>>>>>>> This is correct. >>>>>>>> >>>>>>>> Cheers, Jeff. >>>>>>>> >>>>>>> >>>>>>> That makes sense to me. However, did you consider allowing both >>>>>>> --lang >>>>>>> and --langs interchangeably? I mean, it is perfectly OK to document >>>>>>> only one of them where appropriate, but it will definitely spare us >>>>>>> all some otherwise easily avoidable errors. >>>>>>> >>>>>> >>>>>> Feel free to submit a patch :-) >>>>> >>>>> See the attachment! ;-) (Created by typing `diff publican/bin/publican >>>>> publican/bin/publican.orig > publican.diff' in the root directory >>>>> of the >>>>> publican's latest SVN snapshot.) >>>>> >>>>> However, I didn't have much time to really familiarize myself with the >>>>> source code, so there is probably a smarter way to do this. >>>> >>>> Well, the smarter way would be to add the alias directly to the >>>> Getopt::Long options, and then make all functions use the same form, >>>> but I did not want to disturb the semantic distinction between the >>>> singular and plural forms in the code. >>>> >>> >>> Since they parameters do not actually do the same thing ATM, your patch >>> needs to include: >>> >>> A: Changes to the Publican::* modules to handle the option they don't >>> currently support, either lang or langs, they only handle one ATM. >> > >> > A involves either adding an extra parameter to the functions and making >> > sure one of them is supplied, or modifying bin/publican to convert from >> > between lang and langs as required. >> >> I believe I already did the latter as you can see near the very end of >> my patch. > > If you are going to allow people to pass in --langs as a valid parameter > then you have to support supplying multiple languages, not just cater > for people providing a single language with --langs. > > You can't just pass in multiple languages to a function expecting a > single language, you need to either flag it as an error before you get > to the function, or split them up and loop around the call, or modify > the function to handle multiple languages. > > I expect if you pass multiple languages in to some functions that expect > a single language you will get odd message, maybe like: > > en-US,fr-FR is not a valid language > > or it may work, and you will have one fancy language code! I agree on this, but this should be a subject of another patch. Even now you can pass multiple languages to the --lang option. Surely, it will not succeed, but you won't get a very helpful error message either. > Simply copying langs to lang isn't robust, at the least it will lead to > people asking "if I can use --langs why can't I supply more than one > language?" What about a warning message, something like ``A single language expected, using --lang instead''? It might even address the issue mentioned above, since this way you would know that you were not supposed to supply more than one language. Regards, -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jfearn at redhat.com Sat Jun 12 00:51:54 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Sat, 12 Jun 2010 10:51:54 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C120026.80109@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <1276209667.2226.4.camel@localhost> <4C117607.3050403@redhat.com> <4C117BF0.4090308@redhat.com> <4C118030.4030708@redhat.com> <4C120026.80109@redhat.com> Message-ID: <1276303914.3558.2.camel@localhost> On Fri, 2010-06-11 at 11:21 +0200, Jaromir Hradilek wrote: > On 06/11/2010 02:15 AM, Jeffrey Fearn wrote: > > Jeffrey Fearn wrote: > >> Jaromir Hradilek wrote: > >>>> Jaromir, good start. Can you add something to the publican wiki about > >>>> code submission requirements that include the info above? Might want to > >>>> write it up real sweet-like. > >>>> > >>>> Cheers, > >>>> mike > >>> > >>> Sure Mike, I'll take a look at that tomorrow morning. > >> > >> Do you have a FAS account? You will need to let me know what your FAS > >> user name is so I can give you write access to the wiki. > > > > I think the wiki is actually setup so any authenticated user can edit > > it, maybe someone with a a FAS account and no special permissions can > > give it a shot? > > > > Cheers, Jeff. > > Hi Jeff, I just successfully edited the page with my ordinary Fedora > account, so no special permissions seem to be required. Cool! I see well structured sentences where my scribbling once dwelt! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jfearn at redhat.com Sat Jun 12 01:17:30 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Sat, 12 Jun 2010 11:17:30 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C12034C.2010905@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> Message-ID: <1276305450.3558.28.camel@localhost> On Fri, 2010-06-11 at 11:35 +0200, Jaromir Hradilek wrote: > On 06/11/2010 01:55 AM, Jeffrey Fearn wrote: > > Jaromir Hradilek wrote: > >> On 06/11/2010 12:33 AM, Jeffrey Fearn wrote: > >>> Jaromir Hradilek wrote: > >>>> On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: > >>>>> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: > >>>>>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek > >>>>>> wrote: > >>>>>>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: > >>>>>>>> Joshua Wulf wrote: > >>>>>>>>> Another thing I notice is that publican build takes --langs as an > >>>>>>>>> argument, while publican package takes --lang. > >>>>>>>>> > >>>>>>>>> Is this because "package" can only do one language at a time, > >>>>>>>>> while > >>>>>>>>> "build" can do multiple? > >>>>>>>> > >>>>>>>> This is correct. > >>>>>>>> > >>>>>>>> Cheers, Jeff. > >>>>>>>> > >>>>>>> > >>>>>>> That makes sense to me. However, did you consider allowing both > >>>>>>> --lang > >>>>>>> and --langs interchangeably? I mean, it is perfectly OK to document > >>>>>>> only one of them where appropriate, but it will definitely spare us > >>>>>>> all some otherwise easily avoidable errors. > >>>>>>> > >>>>>> > >>>>>> Feel free to submit a patch :-) > >>>>> > >>>>> See the attachment! ;-) (Created by typing `diff publican/bin/publican > >>>>> publican/bin/publican.orig > publican.diff' in the root directory > >>>>> of the > >>>>> publican's latest SVN snapshot.) > >>>>> > >>>>> However, I didn't have much time to really familiarize myself with the > >>>>> source code, so there is probably a smarter way to do this. > >>>> > >>>> Well, the smarter way would be to add the alias directly to the > >>>> Getopt::Long options, and then make all functions use the same form, > >>>> but I did not want to disturb the semantic distinction between the > >>>> singular and plural forms in the code. > >>>> > >>> > >>> Since they parameters do not actually do the same thing ATM, your patch > >>> needs to include: > >>> > >>> A: Changes to the Publican::* modules to handle the option they don't > >>> currently support, either lang or langs, they only handle one ATM. > >> > > >> > A involves either adding an extra parameter to the functions and making > >> > sure one of them is supplied, or modifying bin/publican to convert from > >> > between lang and langs as required. > >> > >> I believe I already did the latter as you can see near the very end of > >> my patch. > > > > If you are going to allow people to pass in --langs as a valid parameter > > then you have to support supplying multiple languages, not just cater > > for people providing a single language with --langs. > > > > You can't just pass in multiple languages to a function expecting a > > single language, you need to either flag it as an error before you get > > to the function, or split them up and loop around the call, or modify > > the function to handle multiple languages. > > > > I expect if you pass multiple languages in to some functions that expect > > a single language you will get odd message, maybe like: > > > > en-US,fr-FR is not a valid language > > > > or it may work, and you will have one fancy language code! > > I agree on this, but this should be a subject of another patch. Even now > you can pass multiple languages to the --lang option. Surely, it will > not succeed, but you won't get a very helpful error message either. If you supply a comma separated list to a parameter who description states that it takes a single language, then that is a user error and you will in fact get a correct error 'en-US,fr-FR is not a valid language". However if you supply a comma separated list to a parameter that takes a comma separated list and the code doesn't treat it as a comma separated list, then the code is wrong. If you are enabling a plural parameter then you have to accept that supplying a list is valid and handle it. I'm not sure what the correct way to handle multiple languages being supplied to create or create_brand is, but any patch enabling this parameter to be used with these actions needs to include the code to handle it correctly. > > Simply copying langs to lang isn't robust, at the least it will lead to > > people asking "if I can use --langs why can't I supply more than one > > language?" > > What about a warning message, something like ``A single language > expected, using --lang instead''? I think the generic "that parameter can't be used with this action" is pretty clear. Again, to harp on, if you say --langs is a valid parameter, then you have to support people supplying a list of languages. Generating an error for a valid parameter that has a valid format is a bug. > It might even address the issue > mentioned above, since this way you would know that you were not > supposed to supply more than one language. If there is any confusion over this, and I question that, then I think you'd be better off looking at renaming the parameters to make the distinction clearer, as opposed to clouding the water by making them semi-interchangeable. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jwulf at redhat.com Sat Jun 12 02:07:09 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Sat, 12 Jun 2010 12:07:09 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276305450.3558.28.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> Message-ID: <4C12EBCD.4020808@redhat.com> >> What about a warning message, something like ``A single language >> expected, using --lang instead''? >> > I think the generic "that parameter can't be used with this action" is > pretty clear. Again, to harp on, if you say --langs is a valid > parameter, then you have to support people supplying a list of > languages. Generating an error for a valid parameter that has a valid > format is a bug. > > Can we make it prompt for the parameter if it is not supplied? That way I don't have to think about lang or langs, I just type the thing in when it asks for it. Publican create would also be great with a wizard-like interface. From jhradile at redhat.com Sat Jun 12 19:05:59 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Sat, 12 Jun 2010 21:05:59 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276305450.3558.28.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> Message-ID: <4C13DA97.4090502@redhat.com> Hi Jeff, and many thanks for your elaborate reply. On 06/12/2010 03:17 AM, Jeff Fearn wrote: > On Fri, 2010-06-11 at 11:35 +0200, Jaromir Hradilek wrote: >> On 06/11/2010 01:55 AM, Jeffrey Fearn wrote: >>> Jaromir Hradilek wrote: >>>> On 06/11/2010 12:33 AM, Jeffrey Fearn wrote: >>>>> Jaromir Hradilek wrote: >>>>>> On 06/10/2010 05:49 PM, Jaromir Hradilek wrote: >>>>>>> On 06/10/2010 03:35 PM, mhideo at redhat.com wrote: >>>>>>>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek >>>>>>>> wrote: >>>>>>>>> On 06/10/2010 12:56 AM, Jeffrey Fearn wrote: >>>>>>>>>> Joshua Wulf wrote: >>>>>>>>>>> Another thing I notice is that publican build takes --langs as an >>>>>>>>>>> argument, while publican package takes --lang. >>>>>>>>>>> >>>>>>>>>>> Is this because "package" can only do one language at a time, >>>>>>>>>>> while >>>>>>>>>>> "build" can do multiple? >>>>>>>>>> >>>>>>>>>> This is correct. >>>>>>>>>> >>>>>>>>>> Cheers, Jeff. >>>>>>>>>> >>>>>>>>> >>>>>>>>> That makes sense to me. However, did you consider allowing both >>>>>>>>> --lang >>>>>>>>> and --langs interchangeably? I mean, it is perfectly OK to document >>>>>>>>> only one of them where appropriate, but it will definitely spare us >>>>>>>>> all some otherwise easily avoidable errors. >>>>>>>>> >>>>>>>> >>>>>>>> Feel free to submit a patch :-) >>>>>>> >>>>>>> See the attachment! ;-) (Created by typing `diff publican/bin/publican >>>>>>> publican/bin/publican.orig> publican.diff' in the root directory >>>>>>> of the >>>>>>> publican's latest SVN snapshot.) >>>>>>> >>>>>>> However, I didn't have much time to really familiarize myself with the >>>>>>> source code, so there is probably a smarter way to do this. >>>>>> >>>>>> Well, the smarter way would be to add the alias directly to the >>>>>> Getopt::Long options, and then make all functions use the same form, >>>>>> but I did not want to disturb the semantic distinction between the >>>>>> singular and plural forms in the code. >>>>>> >>>>> >>>>> Since they parameters do not actually do the same thing ATM, your patch >>>>> needs to include: >>>>> >>>>> A: Changes to the Publican::* modules to handle the option they don't >>>>> currently support, either lang or langs, they only handle one ATM. >>>>> >>>>> A involves either adding an extra parameter to the functions and making >>>>> sure one of them is supplied, or modifying bin/publican to convert from >>>>> between lang and langs as required. >>>> >>>> I believe I already did the latter as you can see near the very end of >>>> my patch. >>> >>> If you are going to allow people to pass in --langs as a valid parameter >>> then you have to support supplying multiple languages, not just cater >>> for people providing a single language with --langs. >>> >>> You can't just pass in multiple languages to a function expecting a >>> single language, you need to either flag it as an error before you get >>> to the function, or split them up and loop around the call, or modify >>> the function to handle multiple languages. >>> >>> I expect if you pass multiple languages in to some functions that expect >>> a single language you will get odd message, maybe like: >>> >>> en-US,fr-FR is not a valid language >>> >>> or it may work, and you will have one fancy language code! >> >> I agree on this, but this should be a subject of another patch. Even now >> you can pass multiple languages to the --lang option. Surely, it will >> not succeed, but you won't get a very helpful error message either. > > If you supply a comma separated list to a parameter who description > states that it takes a single language, then that is a user error and > you will in fact get a correct error 'en-US,fr-FR is not a valid > language". > > However if you supply a comma separated list to a parameter that takes a > comma separated list and the code doesn't treat it as a comma separated > list, then the code is wrong. If you are enabling a plural parameter > then you have to accept that supplying a list is valid and handle it. > > I'm not sure what the correct way to handle multiple languages being > supplied to create or create_brand is, but any patch enabling this > parameter to be used with these actions needs to include the code to > handle it correctly. > >>> Simply copying langs to lang isn't robust, at the least it will lead to >>> people asking "if I can use --langs why can't I supply more than one >>> language?" >> >> What about a warning message, something like ``A single language >> expected, using --lang instead''? > > I think the generic "that parameter can't be used with this action" is > pretty clear. Again, to harp on, if you say --langs is a valid > parameter, then you have to support people supplying a list of > languages. Generating an error for a valid parameter that has a valid > format is a bug. Generating an error for a valid parameter in a valid format is a bug, that's for sure, and I don't disagree with that. However, a little tolerance towards common mistakes, possibly accompanied by a warning message, is something completely different, although this probably depends on personal point of view. >> It might even address the issue >> mentioned above, since this way you would know that you were not >> supposed to supply more than one language. > > If there is any confusion over this, and I question that, then I think > you'd be better off looking at renaming the parameters to make the > distinction clearer, as opposed to clouding the water by making them > semi-interchangeable. I understand your point of view and I respect it, I just tried to share mine. I guess the patch is there and anyone is free to use it if he wants. Anyway, have a nice weekend! Regards, -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jhradile at redhat.com Sat Jun 12 19:23:39 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Sat, 12 Jun 2010 21:23:39 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C12EBCD.4020808@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> Message-ID: <4C13DEBB.2010505@redhat.com> On 06/12/2010 04:07 AM, Joshua Wulf wrote: > >>> What about a warning message, something like ``A single language >>> expected, using --lang instead''? >> I think the generic "that parameter can't be used with this action" is >> pretty clear. Again, to harp on, if you say --langs is a valid >> parameter, then you have to support people supplying a list of >> languages. Generating an error for a valid parameter that has a valid >> format is a bug. >> > Can we make it prompt for the parameter if it is not supplied? That way > I don't have to think about lang or langs, I just type the thing in when > it asks for it. > > Publican create would also be great with a wizard-like interface. Personally, I don't think this is something Publican should ever do, as applications with interactive prompt are harder to use from scripts, not to mention counter-intuitive if they do not do so consistently. This is an ideal task for a wrapper, though. By the way, I am starting to think that implementing a full featured interactive prompt in the best spirit of git-sh [1] would be cool. Having all defaults set and current language displayed as a part of the prompt, you could just type ``test'', ``build'', ``package'', and so on, or even use configurable aliases like ``te'', ``bu'', or ``pk'' respectively. [1] http://github.com/rtomayko/git-sh Regards, -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From jwulf at redhat.com Mon Jun 14 10:17:19 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Mon, 14 Jun 2010 20:17:19 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C13DEBB.2010505@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> Message-ID: <4C1601AF.9040000@redhat.com> On 06/13/2010 05:23 AM, Jaromir Hradilek wrote: > On 06/12/2010 04:07 AM, Joshua Wulf wrote: >> >>>> What about a warning message, something like ``A single language >>>> expected, using --lang instead''? >>> I think the generic "that parameter can't be used with this action" is >>> pretty clear. Again, to harp on, if you say --langs is a valid >>> parameter, then you have to support people supplying a list of >>> languages. Generating an error for a valid parameter that has a valid >>> format is a bug. >>> >> Can we make it prompt for the parameter if it is not supplied? That way >> I don't have to think about lang or langs, I just type the thing in when >> it asks for it. >> >> Publican create would also be great with a wizard-like interface. > > Personally, I don't think this is something Publican should ever do, > as applications with interactive prompt are harder to use from > scripts, not to mention counter-intuitive if they do not do so > consistently. This is an ideal task for a wrapper, though. > > By the way, I am starting to think that implementing a full featured > interactive prompt in the best spirit of git-sh [1] would be cool. > Having all defaults set and current language displayed as a part of > the prompt, you could just type ``test'', ``build'', ``package'', and > so on, or even use configurable aliases like ``te'', ``bu'', or ``pk'' > respectively. > > [1] http://github.com/rtomayko/git-sh > > Regards, > I did think about the impact on script kiddies as I wrote that. A publican for dummies wrapper would be a good solution. From jfearn at redhat.com Tue Jun 15 00:13:12 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 15 Jun 2010 10:13:12 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C13DEBB.2010505@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> Message-ID: <1276560792.2448.93.camel@localhost> On Sat, 2010-06-12 at 21:23 +0200, Jaromir Hradilek wrote: > On 06/12/2010 04:07 AM, Joshua Wulf wrote: > > > >>> What about a warning message, something like ``A single language > >>> expected, using --lang instead''? > >> I think the generic "that parameter can't be used with this action" is > >> pretty clear. Again, to harp on, if you say --langs is a valid > >> parameter, then you have to support people supplying a list of > >> languages. Generating an error for a valid parameter that has a valid > >> format is a bug. > >> > > Can we make it prompt for the parameter if it is not supplied? That way > > I don't have to think about lang or langs, I just type the thing in when > > it asks for it. > > > > Publican create would also be great with a wizard-like interface. > > Personally, I don't think this is something Publican should ever do, as > applications with interactive prompt are harder to use from scripts, not > to mention counter-intuitive if they do not do so consistently. This is > an ideal task for a wrapper, though. > > By the way, I am starting to think that implementing a full featured > interactive prompt in the best spirit of git-sh [1] would be cool. > Having all defaults set and current language displayed as a part of the > prompt, you could just type ``test'', ``build'', ``package'', and so on, > or even use configurable aliases like ``te'', ``bu'', or ``pk'' > respectively. > > [1] http://github.com/rtomayko/git-sh > > Regards, I'd give that a very low score on "useful things I could do for Publican". I'd give it even a lower score on "listening to the users", there are other requests that have been discussed by a much wider range of users. I certainly wouldn't stop you from doing it, but there are many more useful things to do IMHO. Here are a few ideas I don't have time to implement, all of which I think are much more useful. 1: Different formatting for article based on class 2: DocBook 5 support 3: Ground work for supporting different XML DTDs, e.g. DITA 4: Ground work for supporting non-XML input, e.g. markdown 5: Ground work for supporting non-PO translations, e.g. XLIFF 6: Replace gettext fuzzy merge with Perl implementation. 7: More ports, e.g. FreeBSD, Mac 8: Replace FOP Number 1 has been discussed on the list, it's an extremely useful feature that would benefit many users. There is an experimental brand in the repo with a very basic attempt at a new article layout, very raw. This is by far the most requested feature ... well aside from the web stuff perhaps, but that only started generating feedback after I'd done most of the work ;) Number 2 is going to hit us sooner or later, we really need to rethink how we override the templates, particularly sorting what changes we can get upstream and separating them from changes that upstream don't want. This affects all users in the long run. Number 3 can probably be done by sub classing Builder.pm. Lots of work required on deciding which bits to split in to the sub classes. Could be handy, might not be used. Number 4 could probably take the same approach as number 3, but is probably somewhat more invasive. Could be handy, might not be used. Number 5 can probably be done by sub classing, again. We do have some old code to handle XLIFF, but it needs to be reworked to fit the current code structure. Could be handy, might not be used. Number 6 is the only part of gettext we actually use, merging updated POT files with existing PO files. Replacing this would allow us to drop the gettext dependency and make supporting other translation formats easier. Definitely be used, transparent to users though. Number 7 means a wider user base, FreeBSD for instance uses DocBook for their docs, but they aren't as pretty as ours. Should be easy to whip up a brand once the port is done. Number 8 PLEASE! I've looked on and off ever since we started using it and I haven't found anything that can replace it, but it's the number one source of configuration issues and weird behavior, so either supporting another FO processor, or simply replacing it, would be a God send. FYI on RHEL 6 Publican is locked to i386 and x86_64 arches because of the FOP dependency :( There are a few other things that are crying out to be done, but off the top of my head this is what came to me. They are all much more worthy of your time than catering to people who are challenged by typing --lang, IMHO. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From jwulf at redhat.com Tue Jun 15 00:40:45 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Tue, 15 Jun 2010 10:40:45 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276560792.2448.93.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> <1276560792.2448.93.camel@localhost> Message-ID: <4C16CC0D.4010907@redhat.com> On 06/15/2010 10:13 AM, Jeff Fearn wrote: > On Sat, 2010-06-12 at 21:23 +0200, Jaromir Hradilek wrote: > >> On 06/12/2010 04:07 AM, Joshua Wulf wrote: >> >>> >>>>> What about a warning message, something like ``A single language >>>>> expected, using --lang instead''? >>>>> >>>> I think the generic "that parameter can't be used with this action" is >>>> pretty clear. Again, to harp on, if you say --langs is a valid >>>> parameter, then you have to support people supplying a list of >>>> languages. Generating an error for a valid parameter that has a valid >>>> format is a bug. >>>> >>>> >>> Can we make it prompt for the parameter if it is not supplied? That way >>> I don't have to think about lang or langs, I just type the thing in when >>> it asks for it. >>> >>> Publican create would also be great with a wizard-like interface. >>> >> Personally, I don't think this is something Publican should ever do, as >> applications with interactive prompt are harder to use from scripts, not >> to mention counter-intuitive if they do not do so consistently. This is >> an ideal task for a wrapper, though. >> >> By the way, I am starting to think that implementing a full featured >> interactive prompt in the best spirit of git-sh [1] would be cool. >> Having all defaults set and current language displayed as a part of the >> prompt, you could just type ``test'', ``build'', ``package'', and so on, >> or even use configurable aliases like ``te'', ``bu'', or ``pk'' >> respectively. >> >> [1] http://github.com/rtomayko/git-sh >> >> Regards, >> > I'd give that a very low score on "useful things I could do for > Publican". I'd give it even a lower score on "listening to the users", > there are other requests that have been discussed by a much wider range > of users. I certainly wouldn't stop you from doing it, but there are > many more useful things to do IMHO. > > Here are a few ideas I don't have time to implement, all of which I > think are much more useful. > > > 3: Ground work for supporting different XML DTDs, e.g. DITA > > > Number 3 can probably be done by sub classing Builder.pm. Lots of work > required on deciding which bits to split in to the sub classes. Could be > handy, might not be used. > +1 for Number 3. From jfearn at redhat.com Tue Jun 15 02:04:12 2010 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 15 Jun 2010 12:04:12 +1000 Subject: [publican-list] Wish List Page Message-ID: <1276567452.2448.102.camel@localhost> Since feature requests are either stuck in my head or on the email list I thought I'd add a page top the wiki to track this stuff. e.g. How did I forget the RevisionFlag feature O_O https://fedorahosted.org/publican/wiki/WishList This way, when I win the lottery and become a gentleman of leisure and man about town, the new sucker will know what to do! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing From bugzilla at redhat.com Tue Jun 15 03:49:57 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 14 Jun 2010 23:49:57 -0400 Subject: [publican-list] [Bug 475684] Find solution for using Glossaries with publican In-Reply-To: References: Message-ID: <201006150349.o5F3nvea022651@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=475684 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rlandman at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 15 03:50:13 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 14 Jun 2010 23:50:13 -0400 Subject: [publican-list] [Bug 475684] Find solution for using Glossaries with publican In-Reply-To: References: Message-ID: <201006150350.o5F3oDh2022942@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=475684 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(rlandman at redhat.c | |om) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 15 05:34:54 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 Jun 2010 01:34:54 -0400 Subject: [publican-list] [Bug 475684] Find solution for using Glossaries with publican In-Reply-To: References: Message-ID: <201006150534.o5F5YsS3008239@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=475684 Joshua Wulf changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwulf at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From dhensley at redhat.com Tue Jun 15 09:10:24 2010 From: dhensley at redhat.com (Douglas Silas) Date: Tue, 15 Jun 2010 11:10:24 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276560792.2448.93.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> <1276560792.2448.93.camel@localhost> Message-ID: <4C174380.1060901@redhat.com> On 06/15/2010 02:13 AM, Jeff Fearn wrote: > 8: Replace FOP > > > Number 8 PLEASE! I've looked on and off ever since we started using it > and I haven't found anything that can replace it, but it's the number > one source of configuration issues and weird behavior, so either > supporting another FO processor, or simply replacing it, would be a God > send. FYI on RHEL 6 Publican is locked to i386 and x86_64 arches because > of the FOP dependency:( > Wouldn't the best way to replace FOP be to try to use/co-opt/extend one of the docbook2odf stylesheets, and then use OpenOffice's PDF export? One open source docbook2odf project: http://sourceforge.net/projects/docbook2odf/ uconv (universal OpenOffice format--including PDF--batch converter): http://dag.wieers.com/home-made/unoconv/ This would also enable the use of OOo Writer for drafts and review edits, among other use cases. Otherwise, I haven't found anything that could replace FOP atm. -- Silas From jhradile at redhat.com Tue Jun 15 11:54:46 2010 From: jhradile at redhat.com (Jaromir Hradilek) Date: Tue, 15 Jun 2010 13:54:46 +0200 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276560792.2448.93.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> <1276560792.2448.93.camel@localhost> Message-ID: <4C176A06.5070901@redhat.com> On 06/15/2010 02:13 AM, Jeff Fearn wrote: > On Sat, 2010-06-12 at 21:23 +0200, Jaromir Hradilek wrote: >> On 06/12/2010 04:07 AM, Joshua Wulf wrote: >>> >>>>> What about a warning message, something like ``A single language >>>>> expected, using --lang instead''? >>>> I think the generic "that parameter can't be used with this action" is >>>> pretty clear. Again, to harp on, if you say --langs is a valid >>>> parameter, then you have to support people supplying a list of >>>> languages. Generating an error for a valid parameter that has a valid >>>> format is a bug. >>>> >>> Can we make it prompt for the parameter if it is not supplied? That way >>> I don't have to think about lang or langs, I just type the thing in when >>> it asks for it. >>> >>> Publican create would also be great with a wizard-like interface. >> >> Personally, I don't think this is something Publican should ever do, as >> applications with interactive prompt are harder to use from scripts, not >> to mention counter-intuitive if they do not do so consistently. This is >> an ideal task for a wrapper, though. >> >> By the way, I am starting to think that implementing a full featured >> interactive prompt in the best spirit of git-sh [1] would be cool. >> Having all defaults set and current language displayed as a part of the >> prompt, you could just type ``test'', ``build'', ``package'', and so on, >> or even use configurable aliases like ``te'', ``bu'', or ``pk'' >> respectively. >> >> [1] http://github.com/rtomayko/git-sh >> >> Regards, > > I'd give that a very low score on "useful things I could do for > Publican". I'd give it even a lower score on "listening to the users", > there are other requests that have been discussed by a much wider range > of users. I certainly wouldn't stop you from doing it, but there are > many more useful things to do IMHO. Surprisingly enough, I would give that the same score as you. ;-) It was more an idea for a third party utility than something you (or anyone else doing the heavy lifting) should bother with. > Here are a few ideas I don't have time to implement, all of which I > think are much more useful. > > 1: Different formatting for article based on class > 2: DocBook 5 support > 3: Ground work for supporting different XML DTDs, e.g. DITA > 4: Ground work for supporting non-XML input, e.g. markdown > 5: Ground work for supporting non-PO translations, e.g. XLIFF > 6: Replace gettext fuzzy merge with Perl implementation. > 7: More ports, e.g. FreeBSD, Mac > 8: Replace FOP > > Number 1 has been discussed on the list, it's an extremely useful > feature that would benefit many users. There is an experimental brand in > the repo with a very basic attempt at a new article layout, very raw. > This is by far the most requested feature ... well aside from the web > stuff perhaps, but that only started generating feedback after I'd done > most of the work ;) > > Number 2 is going to hit us sooner or later, we really need to rethink > how we override the templates, particularly sorting what changes we can > get upstream and separating them from changes that upstream don't want. > This affects all users in the long run. > > Number 3 can probably be done by sub classing Builder.pm. Lots of work > required on deciding which bits to split in to the sub classes. Could be > handy, might not be used. > > Number 4 could probably take the same approach as number 3, but is > probably somewhat more invasive. Could be handy, might not be used. As intriguing as it sounds, I am not convinced whether it is such a good idea to hack this into Publican itself. You see, lightweight markup languages such as Markdown are much less semantic than DocBook, not to mention troublesome to parse properly and/or validate. They are great for articles and shorter texts, but I probably wouldn't dare to write technical book in one. > Number 5 can probably be done by sub classing, again. We do have some > old code to handle XLIFF, but it needs to be reworked to fit the current > code structure. Could be handy, might not be used. > > Number 6 is the only part of gettext we actually use, merging updated > POT files with existing PO files. Replacing this would allow us to drop > the gettext dependency and make supporting other translation formats > easier. Definitely be used, transparent to users though. > > Number 7 means a wider user base, FreeBSD for instance uses DocBook for > their docs, but they aren't as pretty as ours. Should be easy to whip up > a brand once the port is done. > > Number 8 PLEASE! I've looked on and off ever since we started using it > and I haven't found anything that can replace it, but it's the number > one source of configuration issues and weird behavior, so either > supporting another FO processor, or simply replacing it, would be a God > send. FYI on RHEL 6 Publican is locked to i386 and x86_64 arches because > of the FOP dependency :( Wouldn't it be possible to isolate it somehow, so that the FOP dependency could be omitted on other architectures than i386 and x86_64? Being unable to export to PDF would be a small sacrifice for having the possibility tu use Publican everywhere, I think. Another possibility might be to implement a TeX or LaTeX source as a possible target format. If properly done, the typographical quality of the produced PDF might then increase astronomically. > There are a few other things that are crying out to be done, but off the > top of my head this is what came to me. They are all much more worthy of > your time than catering to people who are challenged by typing --lang, > IMHO. This is certainly an impressive list, thanks for sharing those ideas. Regards, -- Jaromir Hradilek Associate Content Author Engineering Content Services Red Hat Czech s. r. o. Purkynova 99, 612 45 Brno Phone: +420 532 294 326 From bugzilla at redhat.com Tue Jun 15 17:58:52 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 Jun 2010 13:58:52 -0400 Subject: [publican-list] [Bug 604255] New: Problem with callouts Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Problem with callouts https://bugzilla.redhat.com/show_bug.cgi?id=604255 Summary: Problem with callouts Product: Red Hat Enterprise Linux 5 Version: 5.7 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: publican AssignedTo: mhideo at redhat.com ReportedBy: jonathan.robie at redhat.com QAContact: llim at redhat.com CC: publican-list at redhat.com Classification: Red Hat Target Release: --- Callouts aren't working properly. Here is an example that illustrates the problem - the callouts are not displayed in the output. "Hello world!" in C++ #include #include #include #include #include ]]> using namespace qpid::messaging; int main(int argc, char** argv) { std::string broker = argc > 1 ? argv[1] : "localhost:5672"; std::string address = argc > 2 ? argv[2] : "amq.topic"; Connection connection(broker); try { connection.open(); Session session = connection.createSession(); Receiver receiver = session.createReceiver(address); Sender sender = session.createSender(address); sender.send(Message("Hello world!")); Message message = receiver.fetch(Duration::SECOND * 1); session.acknowledge(); connection.close(); return 0; } catch(const std::exception& error) { connection.close(); return 1; } } Establishes the connection with the messaging broker. Creates a session object, which maintains the state of all interactions with the messaging broker, and manages senders and receivers. Creates a receiver that reads from the given address. Creates a sender that sends to the given address. Reads the next message. The duration is optional, if omitted, will wait indefinitely for the next message. Acknowledges messages that have been read. To guarantee delivery, a message remains on the messaging broker until it is acknowledged by a client. session.acknowledge() acknowledges all unacknowledged messages for the given session—this allows acknowledgements to be batched, which is more efficient than acknowledging messages individually. Closes the connection, all sessions managed by the connection, and all senders and receivers managed by each session. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 15 23:18:44 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 Jun 2010 19:18:44 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006152318.o5FNIiGO025700@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jfearn at redhat.com, | |rlandman at redhat.com AssignedTo|mhideo at redhat.com |jfearn at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 15 23:26:56 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 Jun 2010 19:26:56 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006152326.o5FNQuNH006213@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Jeff Fearn 2010-06-15 19:26:55 EDT --- Using current 1.6.x branch (which has fixes to callouts not in 1.6.3): - https://fedorahosted.org/fedora-websites/ticket/24 The problem is that this user (and at least one other user I encountered in the #fedora-docs channel a few weeks ago) didn't realise that the "Product" label in the ToC sidebar is a drop-down menu hiding versions (and documents) underneath it. The suggestion is either to somehow make it more explicit that the "Product" label is a menu, or to be able to set a particular part of the menu (in this case, Fedora 13) to default to expanded. I think that if it's possible, setting part of the menu to default to expanded would be a better user experience. What do others here think? Cheers Rudi From sparks at fedoraproject.org Wed Jun 16 00:16:53 2010 From: sparks at fedoraproject.org (Eric "Sparks" Christensen) Date: Tue, 15 Jun 2010 20:16:53 -0400 Subject: [publican-list] Organizing by Subject (guide) on Publican's web output Message-ID: <4C1817F5.8070404@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right now Publican builds the home page by language -> Guide -> Version (Release). This works for people coming to look for information (self-service) but doesn't do very well if I want to refer to a guide in documentation or in a conversation. It would be nice if there were sub-pages for each guide that allowed you to choose the version (release). That way if I tell someone they should go read the Security Guide I'm not referring the person to the main home page for them to navigate. I think it could be done fairly easily but not in the current file path structure. Thoughts? - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMGBf0AAoJEDbiLlqcYamxlBYQAJ4OQuPV2A+AcBzCxmIIp55a Yy40GAdpQWIHShlSViqaeAaXzGNSn6SnOStLiUJ8O7IbJqhoyZi9c7g5NOdz4dDM c0FDRl4tMLxVOAUBXkrvV2KeW6pOTjmE3ih/LjhaGXtowocMJAL7vHCsKGSM+1YF gd/pWEXKimGKPFPxySRfDWAk03gf/hX4W69qruJMVGAFnMyjbWIY2vFdzI1st6NZ 4fX30Or5aT0/gRZifkt8DiJNcKdQ6eJhTU9wa1gLOVhNdGHionCFMsgw2yLX0ByG 17ivjH0Zc1l6Mvfaol20x5GrllsvIwm8rhMafriur5XvubMAqv9WgP7KiUD4C+Mj 7VbVoGP8oBjwg/eszgYnRUarU7CqK/UTxHuIOKIaIp1IdGTpksk11LVHGTZ4miFO S5pr231YghJnqEpYjgDit6/s+gZQYvPTTmIoWjrPzKLyyF8PuQ/2L47FXudvZG87 FIhiCSUGDnAynWNqP9RkY/bsMeBMrFg0Ea3eV6+NNbavbT5NOrivBYhWly1041yG QXNuEQvi5Lu9jqB3FUARUG6oQJF3eCzeZYuqLNi6J9T25OWCZz6CfoOxna9paE9j ++WHdrC79yMoTAtl3cnvQG7RJyXpgLvvEoaiIIC5okJyqs6DoF/a5KVk0CGgWkK9 c+rM9oJsZv5en8C1F6EP =Msxk -----END PGP SIGNATURE----- From sparks at fedoraproject.org Wed Jun 16 00:20:34 2010 From: sparks at fedoraproject.org (Eric "Sparks" Christensen) Date: Tue, 15 Jun 2010 20:20:34 -0400 Subject: [publican-list] (Unfavourable) User feedback from Fedora docs site In-Reply-To: <4C181375.9010801@redhat.com> References: <4C181375.9010801@redhat.com> Message-ID: <4C1818D2.40600@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2010 07:57 PM, Ruediger Landmann wrote: > https://fedorahosted.org/fedora-websites/ticket/24 > > The problem is that this user (and at least one other user I encountered > in the #fedora-docs channel a few weeks ago) didn't realise that the > "Product" label in the ToC sidebar is a drop-down menu hiding versions > (and documents) underneath it. I've heard similar comments and also that you can't do anything with the sidebar once you've found your document. > > The suggestion is either to somehow make it more explicit that the > "Product" label is a menu, or to be able to set a particular part of the > menu (in this case, Fedora 13) to default to expanded. > > I think that if it's possible, setting part of the menu to default to > expanded would be a better user experience. What do others here think? Sounds like a good solution to me. > > > Cheers > Rudi - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMGBjRAAoJEDbiLlqcYamxzwsP/iIrvHns3PvFmwDaWBJRn2W0 LvfULhBcqL/WIlKBx5GMhSjJOYBGYmh/XY9jJqoG3qMUM3gWgT/7OkL54CitiifZ bsfXsYnLstHpoqObKrMOnaAtVUJvXI1WdTwnIp4zagcJphvjY6+Id+zIWBK4Glmu oz1pGSb2+1twkj71emw2abvUxFrppHg0PuFFlw2IAUDyR76+np5rVQfK3u8oLLvd yKesXcE6rGGBmUtiGIhI9anus0hZ1PGC2Wou0KMB5+ee4LL3zcZO86uOTbwPfrIW mSHZYGCBq0H8siD9mGmvVTCTQInNYsTUK5NqylOHpaoDsTTKqM39JLxzZo2flDHl bpTz5Gw8yCBXAr7GfgHyKyULNaVl4ShNkCaLhI6PW5DG6HuV2fKegZ1QVZwJMtpN mIdbBDTDJprpMz925yhbHci2j6SKivbj5z+7sN1zA3p3kKUGVHGKTE61JhYiWdvl EgmbXwl09QJG6+Xxnd8BKnfWjqz1z/rmyfsfDsZYl34105kKv0O3aqZR0EDyk0Wd 2L/oj5fKveBypqsGQaJ3wKISTU9saFFo502H1NfmbXhZKn8kUZxT+aTsmIyKpzeu BUW/dTwP5pPzkUz/tzXpLlPIHFw7uADbBLxTtuo4snG53avxv3wJP+kc83fQuVU2 /fOTMeW93UG8R69Im5Tc =Bnpa -----END PGP SIGNATURE----- From misty at redhat.com Wed Jun 16 00:30:08 2010 From: misty at redhat.com (Misty Stanley-Jones) Date: Tue, 15 Jun 2010 20:30:08 -0400 (EDT) Subject: [publican-list] (Unfavourable) User feedback from Fedora docs site In-Reply-To: <4C181375.9010801@redhat.com> Message-ID: <137984513.354251276648208026.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Looking over the site, here are my thoughts on how to make it more obvious what is going on with the menus. These are different approaches and could probably be combined or used individually. 1. At least if you have a 'Collapse All', it seems to me that you also need an 'Expand All', for consistency. 2. If I expand Fedora, each item underneath it has an arrow to the left, indicating that it's a menu. Why don't the top-level items have the same sort of arrow? 3. In this kind of tree view, it is customary to have a + inside a box, to indicate that something can be expanded. When the item is expanded, the + changes to a -. This is normal, expected behavior with web user interfaces by now. 4. Add some color. Why don't the top-level menu items have a different background or a more bold font? They don't stand out at all. 5. At least something should be expanded by default. There is too much white space in the left-hand column when the page first loads. Thanks, Misty ----- "Ruediger Landmann" wrote: > From: "Ruediger Landmann" > To: "Publican discussions" > Sent: Wednesday, June 16, 2010 9:57:41 AM GMT +10:00 Brisbane > Subject: [publican-list] (Unfavourable) User feedback from Fedora docs site > > https://fedorahosted.org/fedora-websites/ticket/24 > > The problem is that this user (and at least one other user I > encountered > in the #fedora-docs channel a few weeks ago) didn't realise that the > "Product" label in the ToC sidebar is a drop-down menu hiding versions > > (and documents) underneath it. > > The suggestion is either to somehow make it more explicit that the > "Product" label is a menu, or to be able to set a particular part of > the > menu (in this case, Fedora 13) to default to expanded. > > I think that if it's possible, setting part of the menu to default to > > expanded would be a better user experience. What do others here > think? > > > Cheers > Rudi > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican -- Misty Stanley-Jones Content Author, ECS 1/193 North Quay, Brisbane QLD 4000 Ph: +61 7 3514 8105 Mobile: +61 429 595 932 Time Zone: GMT+10 From bugzilla at redhat.com Wed Jun 16 00:34:32 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 Jun 2010 20:34:32 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006160034.o5G0YWvl022630@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 --- Comment #2 from Jeff Fearn 2010-06-15 20:34:29 EDT --- Due to the way the XSL gets processed the tags inside the program listing are processed before the highlighting callback gets called; the COs have already been converted to the output format, be it HTML or XML:FO. This means we'd have to try and exclude some part of the input being from highlighted, and the mask of that content would change based on what the output format is. Of course if you were trying to highlight HTML or XML source then there probably isn't a reliable way to differentiate call-out markup Vs any other markup. If it's possible, it's definitely going to take some time to be able to support the combination of highlighting and inline COs. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From r.landmann at redhat.com Wed Jun 16 00:40:12 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Wed, 16 Jun 2010 10:40:12 +1000 Subject: [publican-list] Organizing by Subject (guide) on Publican's web output In-Reply-To: <4C1817F5.8070404@fedoraproject.org> References: <4C1817F5.8070404@fedoraproject.org> Message-ID: <4C181D6C.1040104@redhat.com> On 06/16/2010 10:16 AM, Eric "Sparks" Christensen wrote: > It would be nice if there were sub-pages for each guide that allowed you > to choose the version (release). That way if I tell someone they should > go read the Security Guide I'm not referring the person to the main home > page for them to navigate. > If I'm reading this right (and in light of our previous IRC discussion), this would be a page for each title in the documentation suite, for example: http://docs.fedoraproject.org/Security_Guide that would link just the versions of the Security_Guide (in all languages? or one page for each language?) probably along the lines of the existing "Map" page that Publican generates http://docs.fedoraproject.org/toc.html > I think it could be done fairly easily but not in the current file path > structure. > > I can see the usefulness of this when pointing people to a title and then allowing them to choose the relevant version and language for themselves. The directory structure is no obstacle here, as far as I can see; this isn't a problem for the Map page. The "per-title Map" would also be sitting in a directory above the docs themselves (whether in the web root, or in each language subdirectory). The current Map page gets regenerated every time a document is added to the site; a per-title map could do the same. Cheers Rudi From mhideo at redhat.com Wed Jun 16 01:46:18 2010 From: mhideo at redhat.com (Mike Hideo) Date: Wed, 16 Jun 2010 11:46:18 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <1276560792.2448.93.camel@localhost> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> <1276560792.2448.93.camel@localhost> Message-ID: <4C182CEA.1020900@redhat.com> On 06/15/2010 10:13 AM, Jeff Fearn wrote: > I'd give that a very low score on "useful things I could do for > Publican". I'd give it even a lower score on "listening to the users", > there are other requests that have been discussed by a much wider range > of users. I certainly wouldn't stop you from doing it, but there are > many more useful things to do IMHO. > > Here are a few ideas I don't have time to implement, all of which I > think are much more useful. > > 1: Different formatting for article based on class > 2: DocBook 5 support > 3: Ground work for supporting different XML DTDs, e.g. DITA > 4: Ground work for supporting non-XML input, e.g. markdown > 5: Ground work for supporting non-PO translations, e.g. XLIFF > 6: Replace gettext fuzzy merge with Perl implementation. > 7: More ports, e.g. FreeBSD, Mac > 8: Replace FOP > > Number 1 has been discussed on the list, it's an extremely useful > feature that would benefit many users. There is an experimental brand in > the repo with a very basic attempt at a new article layout, very raw. > This is by far the most requested feature ... well aside from the web > stuff perhaps, but that only started generating feedback after I'd done > most of the work ;) > > Number 2 is going to hit us sooner or later, we really need to rethink > how we override the templates, particularly sorting what changes we can > get upstream and separating them from changes that upstream don't want. > This affects all users in the long run. > > Number 3 can probably be done by sub classing Builder.pm. Lots of work > required on deciding which bits to split in to the sub classes. Could be > handy, might not be used. > > Number 4 could probably take the same approach as number 3, but is > probably somewhat more invasive. Could be handy, might not be used. > > Number 5 can probably be done by sub classing, again. We do have some > old code to handle XLIFF, but it needs to be reworked to fit the current > code structure. Could be handy, might not be used. > > Number 6 is the only part of gettext we actually use, merging updated > POT files with existing PO files. Replacing this would allow us to drop > the gettext dependency and make supporting other translation formats > easier. Definitely be used, transparent to users though. > > Number 7 means a wider user base, FreeBSD for instance uses DocBook for > their docs, but they aren't as pretty as ours. Should be easy to whip up > a brand once the port is done. > > Number 8 PLEASE! I've looked on and off ever since we started using it > and I haven't found anything that can replace it, but it's the number > one source of configuration issues and weird behavior, so either > supporting another FO processor, or simply replacing it, would be a God > send. FYI on RHEL 6 Publican is locked to i386 and x86_64 arches because > of the FOP dependency :( > > There are a few other things that are crying out to be done, but off the > top of my head this is what came to me. They are all much more worthy of > your time than catering to people who are challenged by typing --lang, > IMHO. Thanks, Jeff, Good list. I guess we should start on #1 and work our way down the list. - Mike From jfearn at redhat.com Wed Jun 16 01:49:48 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 16 Jun 2010 11:49:48 +1000 Subject: [publican-list] --lang vs --langs In-Reply-To: <4C182CEA.1020900@redhat.com> References: <4C0F541C.6020604@redhat.com> <4C101C05.8010205@redhat.com> <4C10DD8A.2020708@redhat.com> <01665D9F-EA2A-4B05-82FC-389A7F51FE69@redhat.com> <4C110983.2040208@redhat.com> <4C115AC1.4090900@redhat.com> <4C11682A.2090404@redhat.com> <4C117303.9090003@redhat.com> <4C117B84.4090308@redhat.com> <4C12034C.2010905@redhat.com> <1276305450.3558.28.camel@localhost> <4C12EBCD.4020808@redhat.com> <4C13DEBB.2010505@redhat.com> <1276560792.2448.93.camel@localhost> <4C182CEA.1020900@redhat.com> Message-ID: <4C182DBC.1070306@redhat.com> Mike Hideo wrote: > Good list. > > I guess we should start on #1 and work our way down the list. The order is just how they came out of my head, it's no indication of importance, usefulness, or difficulty. I've also added more to the wish list page, I've just been appending them, again order isn't indicative of anything other than the allegedly self organized chaos of my brain. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Wed Jun 16 13:31:27 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 16 Jun 2010 09:31:27 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006161331.o5GDVRhj011360@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 --- Comment #3 from Jonathan Robie 2010-06-16 09:31:24 EDT --- I don't know exactly how syntax highlighting is implemented. Does syntax highlighting ignore characters like these? DINGBAT NEGATIVE CIRCLED DIGIT ONE U+2776, character ??, decimal 10102, hex 0x2776 DINGBAT NEGATIVE CIRCLED DIGIT TWO U+2777, character ??, decimal 10103, hex 0x2777 DINGBAT NEGATIVE CIRCLED DIGIT THREE U+2778, character ??, decimal 10104, hex 0x2778 Downside: there are only ten of them. Upside: they might pass through. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Jun 16 23:40:47 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 16 Jun 2010 19:40:47 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006162340.o5GNelbw027930@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 --- Comment #4 from Jeff Fearn 2010-06-16 19:40:46 EDT --- We use a CPAN module for the highlighting, I don't think it ignores anything, I haven't found anything to allow specifying things to ignore, so it probably comes down to how the particular language is being parsed. I think it's safer ATM to say "If you want call-outs and code highlighting, then you have to use an areaspec". Here is an example of how I'd structure this. First, I'd move the code out of the XML, having all that XML related stuff buried in your code increases the opportunity of adding typos. It's also annoying to have to take chunks of code and XMLify them. e.g. mkdir en-US/extras gvim en-US/extras/hello.cpp -- make hello.cpp pure C++ -- Then I'd use an areaspec and xi:include the new cpp file, leaving you with: "Hello world!" in C++ ** SNIP There are no changes to the callout list ** I've gone for the simple coords usage here, just specifying the line number, the callout code will default to lining all the numbers up. You can uses coords='16 34' if you want to override this behavior and specify the line and the column. Note how programlisting and the xi:include are on the same line, this means the line numbers you use in coords start from line zero. If you had a newline between them, then you'd have to start the line number count from 1. YMMV, I find keeping the code in a file and only ever treating it as code greatly simplifies the process and allows me to validate the code as code ... not that I make manly typos! -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Jun 17 00:16:20 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 16 Jun 2010 20:16:20 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006170016.o5H0GKPl003810@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 --- Comment #5 from Jeff Fearn 2010-06-16 20:16:16 EDT --- Created an attachment (id=424618) --> (https://bugzilla.redhat.com/attachment.cgi?id=424618) Example of HTML layout Hi, I just thought I'd provide a screen shot of the default output as per my example, built from the latest 1.6 branch. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Thu Jun 17 12:36:00 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 17 Jun 2010 08:36:00 -0400 Subject: [publican-list] [Bug 604255] Problem with callouts In-Reply-To: References: Message-ID: <201006171236.o5HCa0gA012028@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=604255 --- Comment #6 from Jonathan Robie 2010-06-17 08:35:58 EDT --- Nice! That satisfies my needs. The main disadvantage is that if you add a blank line or something, the callouts can be in the wrong place, but this is plenty good enough for my needs. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 22 03:13:39 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 21 Jun 2010 23:13:39 -0400 Subject: [publican-list] [Bug 588999] when built to html, Articles present s in default fashion in contrast to Books, which use custom (and prettier and easier to read) presentation In-Reply-To: References: Message-ID: <201006220313.o5M3Ddwm014139@bzweb02.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=588999 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED Resolution| |ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Tue Jun 22 04:48:46 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 22 Jun 2010 00:48:46 -0400 Subject: [publican-list] [Bug 592823] should not break a paragraph for translation In-Reply-To: References: Message-ID: <201006220448.o5M4mklV013456@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592823 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |llim at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From jwulf at redhat.com Fri Jun 25 20:47:27 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Fri, 25 Jun 2010 16:47:27 -0400 Subject: [publican-list] Chunking by chapter with toc per page Message-ID: <4C2515DF.30009@redhat.com> Using publican, is it possible to chunk a book by chapter, with a "table of contents" of sections at the top, like this: http://docs.jboss.org/seam/2.2.1.CR1/reference/en-US/html/gettingstarted.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.landmann at redhat.com Sat Jun 26 03:17:40 2010 From: r.landmann at redhat.com (Ruediger Landmann) Date: Sat, 26 Jun 2010 13:17:40 +1000 Subject: [publican-list] Chunking by chapter with toc per page In-Reply-To: <4C2515DF.30009@redhat.com> References: <4C2515DF.30009@redhat.com> Message-ID: <4C257154.2040002@redhat.com> On 06/26/2010 06:47 AM, Joshua Wulf wrote: > Using publican, is it possible to chunk a book by chapter, with a > "table of contents" of sections at the top, like this: > > http://docs.jboss.org/seam/2.2.1.CR1/reference/en-US/html/gettingstarted.html > Sure -- just set: chunk_section_depth: 0 in the publican.cfg file. cheers Rudi From ccurran at redhat.com Mon Jun 28 00:58:07 2010 From: ccurran at redhat.com (Chris Curran) Date: Mon, 28 Jun 2010 10:58:07 +1000 Subject: [publican-list] Chunking by chapter with toc per page In-Reply-To: <4C2515DF.30009@redhat.com> References: <4C2515DF.30009@redhat.com> Message-ID: <4C27F39F.80205@redhat.com> On 06/26/2010 06:47 AM, Joshua Wulf wrote: > Using publican, is it possible to chunk a book by chapter, with a > "table of contents" of sections at the top, like this: > > http://docs.jboss.org/seam/2.2.1.CR1/reference/en-US/html/gettingstarted.html > > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > Wiki: https://fedorahosted.org/publican Also, fills this role. Try it, it can deliver the functionality you are looking for. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at redhat.com Mon Jun 28 02:24:57 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 27 Jun 2010 22:24:57 -0400 Subject: [publican-list] [Bug 595564] RFE: can xref links to formalpara go to the actual formalpara, rather than top of the page? In-Reply-To: References: Message-ID: <201006280224.o5S2OvHD009698@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=595564 --- Comment #4 from Murray McAllister 2010-06-27 22:24:56 EDT --- Is there any time frame for a release that will contain a fix for this issue? Thanks. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Mon Jun 28 02:34:07 2010 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 27 Jun 2010 22:34:07 -0400 Subject: [publican-list] [Bug 595564] RFE: can xref links to formalpara go to the actual formalpara, rather than top of the page? In-Reply-To: References: Message-ID: <201006280234.o5S2Y72u011929@bzweb01.app.bz.hst.phx2.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=595564 --- Comment #5 from Jeff Fearn 2010-06-27 22:34:07 EDT --- We don't have a formal schedule, so ... soon ... ish -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From misty at redhat.com Tue Jun 29 06:23:04 2010 From: misty at redhat.com (Misty Stanley-Jones) Date: Tue, 29 Jun 2010 02:23:04 -0400 (EDT) Subject: [publican-list] Packaging Files with Books Message-ID: <1641570471.180291277792584467.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> I've just discovered that things added to the files/ directory under en-US/ are added to packages (RPMs, tarballs) created with the 'publican package' command. It seems that these files can be linked to via as well. This works swimmingly, except for PDFs. In a PDF, contents of the url parameter are shown in blue italics, as though they were a link. Of course they are not linkable. I have not been able to come up with a brilliant solution for how this would ideally work in PDFs, but I thought I'd put it out there for discussion. -- Misty Stanley-Jones Content Author, ECS 1/193 North Quay, Brisbane QLD 4000 From misty at redhat.com Wed Jun 30 03:39:20 2010 From: misty at redhat.com (misty at redhat.com) Date: Tue, 29 Jun 2010 23:39:20 -0400 (EDT) Subject: [publican-list] Including arbitary files in Publican documents In-Reply-To: <1807311659.312661277869001987.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1176649711.312711277869160836.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> I've filed https://bugzilla.redhat.com/show_bug.cgi?id=609345 after trying to link to "files/examples.zip" in a document, I followed the instructions in the FAQ. Here are the results I found. The locally-built book behaves properly, adding a files/ directory to the tmp/en-US/html and tmp/en-US/html-single directories. As I noted on-list yesterday, the PDF version does not work properly. The problem is when I try to package the book using the "publican package" command. The built book, when installed elsewhere, does not contain the files/ subdirectory. Thus, any links referencing it generate a 404 File Not Found error. -- Misty Stanley-Jones Content Author, ECS 1/193 North Quay, Brisbane QLD 4000 From jwulf at redhat.com Wed Jun 30 03:43:21 2010 From: jwulf at redhat.com (Joshua Wulf) Date: Tue, 29 Jun 2010 23:43:21 -0400 Subject: [publican-list] Including arbitary files in Publican documents In-Reply-To: <1176649711.312711277869160836.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1176649711.312711277869160836.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4C2ABD59.2000309@redhat.com> On 06/29/2010 11:39 PM, misty at redhat.com wrote: > I've filed https://bugzilla.redhat.com/show_bug.cgi?id=609345 after trying to link to "files/examples.zip" in a document, I followed the instructions in the FAQ. Here are the results I found. > > The locally-built book behaves properly, adding a files/ directory to the tmp/en-US/html and tmp/en-US/html-single directories. As I noted on-list yesterday, the PDF version does not work properly. > > The problem is when I try to package the book using the "publican package" command. The built book, when installed elsewhere, does not contain the files/ subdirectory. Thus, any links referencing it generate a 404 File Not Found error. > > Yep, I had that problem too. I hacked my way around it by putting the files into the /images directory. From jfearn at redhat.com Wed Jun 30 05:43:22 2010 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 30 Jun 2010 15:43:22 +1000 Subject: [publican-list] Including arbitary files in Publican documents In-Reply-To: <1176649711.312711277869160836.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1176649711.312711277869160836.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4C2AD97A.50801@redhat.com> misty at redhat.com wrote: > I've filed https://bugzilla.redhat.com/show_bug.cgi?id=609345 after trying to link to "files/examples.zip" in a document, I followed the instructions in the FAQ. Here are the results I found. > > The locally-built book behaves properly, adding a files/ directory to the tmp/en-US/html and tmp/en-US/html-single directories. As I noted on-list yesterday, the PDF version does not work properly. > > The problem is when I try to package the book using the "publican package" command. The built book, when installed elsewhere, does not contain the files/ subdirectory. Thus, any links referencing it generate a 404 File Not Found error. > Fixed in the 1.6 branch and trunk. Hope to have Publican 2 out the door within the week. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY