From Norman at dunbar-it.co.uk Wed Feb 1 12:09:15 2012 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Wed, 01 Feb 2012 12:09:15 +0000 Subject: [publican-list] Publican 2.9 slight foible In-Reply-To: <4F286BE1.4080107@redhat.com> References: <4F27A4EE.4020108@dunbar-it.co.uk> <4F286BE1.4080107@redhat.com> Message-ID: <4F292B6B.2050308@dunbar-it.co.uk> Hi Jeff, On 31/01/12 22:32, Jeff Fearn wrote: > Hi Norman, the changes we are doing for PDFs requires changing the > brands. Rudi has scheduled writing up a short how-to on exactly what has > to change in brands, but it hasn't been started yet :( Ok, thanks. That's what I get for being on the bleeding edge I suppose. I'll wait for the official release then. Thanks. Cheers, Norm. PS. Did you know that 2.9 builds on OpenSuse 12.1? I did a test build yesterday and it works. If I was to write up a set of instructions on building publican from source on OpenSuse, would you want it for the User's Guide? If so, I assume I do not have write access to the subversion repository, so would I sent it somewhere? -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 From jfearn at redhat.com Wed Feb 1 22:46:27 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 02 Feb 2012 08:46:27 +1000 Subject: [publican-list] Publican 2.9 slight foible In-Reply-To: <4F292B6B.2050308@dunbar-it.co.uk> References: <4F27A4EE.4020108@dunbar-it.co.uk> <4F286BE1.4080107@redhat.com> <4F292B6B.2050308@dunbar-it.co.uk> Message-ID: <4F29C0C3.1040908@redhat.com> On 02/01/2012 10:09 PM, Norman Dunbar wrote: > Hi Jeff, > > On 31/01/12 22:32, Jeff Fearn wrote: >> Hi Norman, the changes we are doing for PDFs requires changing the >> brands. Rudi has scheduled writing up a short how-to on exactly what has >> to change in brands, but it hasn't been started yet :( > Ok, thanks. That's what I get for being on the bleeding edge I suppose. > I'll wait for the official release then. Thanks. > > > Cheers, > Norm. > > PS. Did you know that 2.9 builds on OpenSuse 12.1? I did a test build > yesterday and it works. If I was to write up a set of instructions on > building publican from source on OpenSuse, would you want it for the > User's Guide? Hell yeah :) > If so, I assume I do not have write access to the subversion repository, > so would I sent it somewhere? You can either apply for membership of the FAS group to get commit access, or you can open a bug and attach the XML and we'll get it included in 2.9. Awesome work, thanks :) Jeff. -- "Reply All" why you shouldn't use it: http://www.emailreplies.com/#12replytoall From jfearn at redhat.com Thu Feb 2 02:07:08 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Thu, 02 Feb 2012 12:07:08 +1000 Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: <20120131074512.GA14761@bowman.infotech.monash.edu.au> References: <4F2638AA.80803@redhat.com> <4F263A93.6070001@redhat.com> <4F263FA5.1070804@redhat.com> <20120131074512.GA14761@bowman.infotech.monash.edu.au> Message-ID: <4F29EFCC.80707@redhat.com> Hi, I just remembered we had some code in place to test the perl module Unicode::Collate [1]. You need to edit XmlClean.pm (either in the source and rebuild or you can just do it where it's installed) and change: -my $test_collate = undef; +my $test_collate = 1; Unicode::Collate is part of core perl on most platforms. That will enable Glossary sorting, which is run during the build, so the output will be sorted but the source won't be touched. If you run clean_ids the Glossary source will be sorted. It's only set-up to sort glosslist, but very similar code could be used to do other types of lists or with some extra work more complex glossary structures. Unicode::Collate has built in functionality to allow overriding the default sorting algorithms, but I've not had time to play with them :( Cheers, Jeff. 1: http://search.cpan.org/~sadahiro/Unicode-Collate-0.87/ -- "Reply All" why you shouldn't use it: http://www.emailreplies.com/#12replytoall From fdalrymple at redhat.com Thu Feb 2 13:52:33 2012 From: fdalrymple at redhat.com (Fred Dalrymple) Date: Thu, 02 Feb 2012 08:52:33 -0500 (EST) Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: <4F29EFCC.80707@redhat.com> Message-ID: <7d84e163-3a2d-471b-b953-ab9cc1499532@zmail11.collab.prod.int.phx2.redhat.com> Cool, I'll take a look as I proceed. thanks -- Fred ----- Original Message ----- > Hi, I just remembered we had some code in place to test the perl > module > Unicode::Collate [1]. You need to edit XmlClean.pm (either in the > source > and rebuild or you can just do it where it's installed) and change: > -my $test_collate = undef; > +my $test_collate = 1; > Unicode::Collate is part of core perl on most platforms. > That will enable Glossary sorting, which is run during the build, so > the > output will be sorted but the source won't be touched. > If you run clean_ids the Glossary source will be sorted. > It's only set-up to sort glosslist, but very similar code could be > used > to do other types of lists or with some extra work more complex > glossary > structures. > Unicode::Collate has built in functionality to allow overriding the > default sorting algorithms, but I've not had time to play with them > :( > Cheers, Jeff. > 1: http://search.cpan.org/~sadahiro/Unicode-Collate-0.87/ > -- > "Reply All" why you shouldn't use it: > http://www.emailreplies.com/#12replytoall > _______________________________________________ > 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 jwulf at redhat.com Fri Feb 3 02:37:47 2012 From: jwulf at redhat.com (Joshua J Wulf) Date: Fri, 03 Feb 2012 12:37:47 +1000 Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: References: Message-ID: <4F2B487B.8040201@redhat.com> Thanks Fred, I've heard of Topic Maps, but haven't used them or looked into them in depth. Both Topic Maps and RDF are of interest to me, because we're doing a lot of work on topic-based authoring using publican. Take a look at this: http://vimeo.com/35732986 At the moment we use a normalized RDMS to hold metadata, including relationships. That works ok as long as there is a single instance of the CMS. Once there are more than one, to maintain compatibility and portability of information between them we need a(n) (extensible) canonical metadata schema. Presently, I'm leaning towards RDF as the best fit, but I'm not sure. I'll look into the Topic Maps, and I'm interested in any thoughts you might have on it. - Josh On 02/01/2012 01:03 AM, Fred Dalrymple wrote: > Hi Josh -- > > Are you familiar with Topic Maps? > > http://www.ontopia.net/topicmaps/materials/tao.html > http://en.wikipedia.org/wiki/Topic_Maps > http://www.topicmaps.org/xtm/ > > The original requirements for Topic Maps were specifically about > dealing with indexes and glossaries -- mainly regarding issues across > sets / families of documentation, such as those we had at the Open > Software Foundation two decades ago (gulp). The standard became much > broader by becoming more general, but the core capabilities include > what is required by this project. > > RDF and Topic Maps don't have exactly the same internal model, but > they are probably close enough (at least for this project) for Topic > Map documents to be translated into RDF form. I'm fairly agnostic on > syntax, but I understand how to express things much better in Topic > Maps than in RDF, so that's my crutch. > > Fred > > > ------------------------------------------------------------------------ > > On 01/31/2012 12:16 AM, Fred Dalrymple wrote: > > Thanks for the pointer (I didn't look far enough back in the > archives). > > In general, if there is no automated programmatic solution, > then I'd probably introduce an external file that would point > at entries that didn't follow the programmatic default and > provide either a clue or explicit sorting key -- think RDF > resources (though I'm partial to Topic Maps). Perhaps > verbose, but if a machine can't figure it out automatically, > what can you do? > > Actually, I'd assumed this in the solution because I'm > thinking about non-alphabetic sorting needs, like the order of > introduction of terms, perhaps on a per-topic basis (and yes, > enabling solutions in forms other than print). > > Fred, you've really piqued my interest now. What approaches might > you take to order the introduction of terms using RDF? > > - Josh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.moulder at monash.edu Fri Feb 3 09:08:55 2012 From: peter.moulder at monash.edu (Peter Moulder) Date: Fri, 03 Feb 2012 20:08:55 +1100 Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: <20120131074512.GA14761@bowman.infotech.monash.edu.au> References: <4F2638AA.80803@redhat.com> <4F263A93.6070001@redhat.com> <4F263FA5.1070804@redhat.com> <20120131074512.GA14761@bowman.infotech.monash.edu.au> Message-ID: <20120203090855.GA5909@bowman.infotech.monash.edu.au> On Tue, Jan 31, 2012 at 06:45:12PM +1100, I wrote: > Apparently, the mapping from a string of Kanji to its pronunciation > (ordering) isn't even a deterministic operation, at least for proper > names. (Of course I meant "proper nouns". Actual non-determinism might even be limited to proper nouns, though I'm not sure that that changes anything from a coding point of view.) > Thus, the solution would have to involve supplying pronunciations somehow > for at least some glossary entries. More precisely, it follows that sorting Kanji entries by pronunciation would in general require supplying pronunciations for some entries. However, I don't want my unclear wording to contribute to wrong conclusions about what Publican actually requires: I'm not in a position to say whether Publican requires index or glossary entries involving Kanji to be sorted by contextually-correct pronunciation. All I've learnt over the past couple of days is that *outside of* a book index or glossary, Kanji are sorted sometimes by contextually-correct pronunciation and sometimes by some other order (and I think there's more than one alternative, even). If anyone wants a concrete sample for an "is this output acceptable" question (and if not using software just for japanese sorting, like Lingua::JA::Sort::JIS), then I suggest making sure that the collation function is tailored for a Japanese locale (e.g. using Unicode::Collate::Locale->new(locale => 'ja-JP')): without that, collation software is unlikely to try to use a specifically-japanese ordering of Kanji characters or intersperse Katakana with Hiragana. In particular, the documentation for plain Unicode::Collate is explicit that it doesn't intersperse Katakana with Hiragana, and that its Kanji ordering is simply by unicode block & code point rather than by a JIS ordering. So I think the easiest thing to do that has a good chance of getting a "yes, this is acceptable" answer would be to switch from Unicode::Collate to Unicode::Collate::Locale and pass locale => $LANG to the constructor (where $LANG is the Publican language like en-US or ja-JP). Effect on other languages: Switching to a locale-sensitive collator might also make for a better collation of Indic languages (handling of virama, and some related reordering rules). Whereas if applied to Spanish for indexes, note that it might move entries like chkconfig from near the beginning of the C entries to just before D; it's not clear to me whether that's a good or bad thing for a word like chkconfig that isn't even spanish and thus arguably isn't using the Spanish ch digraph. (In both cases, I haven't actually tested the behaviour, nor have I asked a native speaker for their preferences for index/glossary sorting in technical documentation.) pjrm. From Norman at dunbar-it.co.uk Fri Feb 3 17:01:15 2012 From: Norman at dunbar-it.co.uk (Norman Dunbar) Date: Fri, 03 Feb 2012 17:01:15 +0000 Subject: [publican-list] Publican 2.9 slight foible In-Reply-To: <4F29C0C3.1040908@redhat.com> References: <4F27A4EE.4020108@dunbar-it.co.uk> <4F286BE1.4080107@redhat.com> <4F292B6B.2050308@dunbar-it.co.uk> <4F29C0C3.1040908@redhat.com> Message-ID: <4F2C12DB.4080402@dunbar-it.co.uk> Hi Jeff, On 01/02/12 22:46, Jeff Fearn wrote: >> PS. Did you know that 2.9 builds on OpenSuse 12.1? I did a test build >> yesterday and it works. If I was to write up a set of instructions on >> building publican from source on OpenSuse, would you want it for the >> User's Guide? > > Hell yeah :) Ok. Consider it done! > You can either apply for membership of the FAS group to get commit > access, or you can open a bug and attach the XML and we'll get it > included in 2.9. https://bugzilla.redhat.com/show_bug.cgi?id=787243 > Awesome work, thanks :) No problem. Just giving a little back. Anyway, if you are interested, I built a new 12.1 install in a VirtualBox VM and followed the instructions in the new chapter. All went well, except: Build test: Cannot build the PDF with FOP. Java Null Pointer Exception. This doesn't happen with a large (200 plus pages) pdf of my own, or a quick test with publican create --type book - just, so far, the user guide. publican build cannot build epubs on OpenSuse. It works fine on Fedora 16. (I've put a note to this effect in the manual.) OpenSuse cannot install wkhtmltopdf as the ghostscript-fonts are called ghostscript-fonts-std on OpenSuse. I tried to force it in with a nodeps check which was fine, but it doesn't create PDfs at all. I also managed to get Publican 2.9 installed on OpenSuse 11.4 - by adding a few more modules using cpan, but it's a wee bit flaky. Had a lot of fun sorting it out though! ;-) And as for current trunk, let's not go there! :-( Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 From roblamora at hotmail.com Sat Feb 4 13:29:04 2012 From: roblamora at hotmail.com (Rob LaMora) Date: Sat, 4 Feb 2012 08:29:04 -0500 Subject: [publican-list] Sudden LibXSLT Error Message-ID: Hi, I was building documents with Publican 2.8 with no problem on my Fedora 15 box (back last fall) and now I cannot successfully build/publish at all. I consistently get the following LibXSLT error (see below). Anyone have any ideas. The main document content has been updated a bit but that's been the only change to this system: [rob at fedora RTI_User_Guide]$ publican build --formats=html --langs=en-US Setting up en-US Processing file tmp/en-US/xml/Common_Content/Conventions.xml -> tmp/en-US/xml/Common_Content/Conventions.xml Processing file tmp/en-US/xml/Common_Content/Feedback.xml -> tmp/en-US/xml/Common_Content/Feedback.xml Processing file tmp/en-US/xml/Common_Content/Legal_Notice.xml -> tmp/en-US/xml/Common_Content/Legal_Notice.xml Processing file tmp/en-US/xml_tmp/Author_Group.xml -> tmp/en-US/xml/Author_Group.xml Processing file tmp/en-US/xml_tmp/Book_Info.xml -> tmp/en-US/xml/Book_Info.xml Processing file tmp/en-US/xml_tmp/Chapter.xml -> tmp/en-US/xml/Chapter.xml Processing file tmp/en-US/xml_tmp/Legal_Notice.xml -> tmp/en-US/xml/Legal_Notice.xml Processing file tmp/en-US/xml_tmp/Preface.xml -> tmp/en-US/xml/Preface.xml Processing file tmp/en-US/xml_tmp/RTI_User_Guide.xml -> tmp/en-US/xml/RTI_User_Guide.xml Beginning work on en-US Starting html Using XML::LibXSLT on /usr/share/publican/xsl/html.xsl undefined language: bash at /usr/share/perl5/vendor_perl/Syntax/Highlight/Engine/Kate.pm line 621. LibXSLT: error coming back from perl-dispatcher in pm file. 'bash' is not a valid language for highlighting. Language names are case sensitive. at /usr/lib/perl5/vendor_perl/XML/LibXSLT.pm line 80 at /usr/share/perl5/vendor_perl/Publican/Builder.pm line 969 [rob at fedora RTI_User_Guide]$ Thanks for any help you can offer. Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From roblamora at hotmail.com Sun Feb 5 13:47:17 2012 From: roblamora at hotmail.com (Rob LaMora) Date: Sun, 5 Feb 2012 08:47:17 -0500 Subject: [publican-list] Sudden LibXSLT Error In-Reply-To: References: Message-ID: All I had to do was look over the FAQs concerning an improper language attribute ("bash" not "Bash") in a programlisting element to figure this one out. Sorry for not checking that first. Rob > From: publican-list-request at redhat.com > Subject: publican-list Digest, Vol 47, Issue 4 > To: publican-list at redhat.com > Date: Sat, 4 Feb 2012 12:00:02 -0500 > > Send publican-list mailing list submissions to > publican-list at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/publican-list > or, via email, send a message with subject or body 'help' to > publican-list-request at redhat.com > > You can reach the person managing the list at > publican-list-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of publican-list digest..." > > > Today's Topics: > > 1. Re: Publican 2.9 slight foible (Norman Dunbar) > 2. Sudden LibXSLT Error (Rob LaMora) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 03 Feb 2012 17:01:15 +0000 > From: Norman Dunbar > To: publican-list at redhat.com > Subject: Re: [publican-list] Publican 2.9 slight foible > Message-ID: <4F2C12DB.4080402 at dunbar-it.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Jeff, > > > On 01/02/12 22:46, Jeff Fearn wrote: > >> PS. Did you know that 2.9 builds on OpenSuse 12.1? I did a test build > >> yesterday and it works. If I was to write up a set of instructions on > >> building publican from source on OpenSuse, would you want it for the > >> User's Guide? > > > > Hell yeah :) > Ok. Consider it done! > > > You can either apply for membership of the FAS group to get commit > > access, or you can open a bug and attach the XML and we'll get it > > included in 2.9. > https://bugzilla.redhat.com/show_bug.cgi?id=787243 > > > Awesome work, thanks :) > No problem. Just giving a little back. > > Anyway, if you are interested, I built a new 12.1 install in a > VirtualBox VM and followed the instructions in the new chapter. All went > well, except: > > Build test: Cannot build the PDF with FOP. Java Null Pointer Exception. > This doesn't happen with a large (200 plus pages) pdf of my own, or a > quick test with publican create --type book - just, so far, the user guide. > > publican build cannot build epubs on OpenSuse. It works fine on Fedora > 16. (I've put a note to this effect in the manual.) > > OpenSuse cannot install wkhtmltopdf as the ghostscript-fonts are called > ghostscript-fonts-std on OpenSuse. I tried to force it in with a nodeps > check which was fine, but it doesn't create PDfs at all. > > > I also managed to get Publican 2.9 installed on OpenSuse 11.4 - by > adding a few more modules using cpan, but it's a wee bit flaky. > > Had a lot of fun sorting it out though! ;-) > > And as for current trunk, let's not go there! :-( > > > Cheers, > Norm. > > -- > Norman Dunbar > Dunbar IT Consultants Ltd > > Registered address: > Thorpe House > 61 Richardshaw Lane > Pudsey > West Yorkshire > United Kingdom > LS28 7EL > > Company Number: 05132767 > > > > ------------------------------ > > Message: 2 > Date: Sat, 4 Feb 2012 08:29:04 -0500 > From: Rob LaMora > To: Publican Mailing List > Subject: [publican-list] Sudden LibXSLT Error > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > Hi, > > I was building documents with Publican 2.8 > with no problem on my Fedora 15 box (back last fall) and now I cannot > successfully build/publish at all. I consistently get the following > LibXSLT error (see below). Anyone have any ideas. The main document > content has been updated a bit but that's been the only change to this > system: > > > [rob at fedora RTI_User_Guide]$ publican build --formats=html --langs=en-US > Setting up en-US > Processing file tmp/en-US/xml/Common_Content/Conventions.xml -> tmp/en-US/xml/Common_Content/Conventions.xml > Processing file tmp/en-US/xml/Common_Content/Feedback.xml -> tmp/en-US/xml/Common_Content/Feedback.xml > Processing file tmp/en-US/xml/Common_Content/Legal_Notice.xml -> tmp/en-US/xml/Common_Content/Legal_Notice.xml > Processing file tmp/en-US/xml_tmp/Author_Group.xml -> tmp/en-US/xml/Author_Group.xml > Processing file tmp/en-US/xml_tmp/Book_Info.xml -> tmp/en-US/xml/Book_Info.xml > Processing file tmp/en-US/xml_tmp/Chapter.xml -> tmp/en-US/xml/Chapter.xml > Processing file tmp/en-US/xml_tmp/Legal_Notice.xml -> tmp/en-US/xml/Legal_Notice.xml > Processing file tmp/en-US/xml_tmp/Preface.xml -> tmp/en-US/xml/Preface.xml > Processing file tmp/en-US/xml_tmp/RTI_User_Guide.xml -> tmp/en-US/xml/RTI_User_Guide.xml > Beginning work on en-US > Starting html > Using XML::LibXSLT on /usr/share/publican/xsl/html.xsl > undefined language: bash at /usr/share/perl5/vendor_perl/Syntax/Highlight/Engine/Kate.pm line 621. > LibXSLT: error coming back from perl-dispatcher in pm file. > 'bash' is not a valid language for highlighting. Language names are case sensitive. > at /usr/lib/perl5/vendor_perl/XML/LibXSLT.pm line 80 > > at /usr/share/perl5/vendor_perl/Publican/Builder.pm line 969 > [rob at fedora RTI_User_Guide]$ > > > Thanks for any help you can offer. > > Rob > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > > End of publican-list Digest, Vol 47, Issue 4 > ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at redhat.com Mon Feb 6 14:27:54 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 6 Feb 2012 09:27:54 -0500 Subject: [publican-list] [Bug 708278] RFE: support translation memory In-Reply-To: References: Message-ID: <201202061427.q16ERs2Z020391@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=708278 Ismael Olea changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ismael at olea.org --- Comment #3 from Ismael Olea 2012-02-06 09:27:52 EST --- Have you considered using OmegaT as a CAT tool instead of the tricky way of PO files? It's being used by proffesionals translators everywhere, manages Docbook, supports TMs and is in Fedora: https://admin.fedoraproject.org/pkgdb/acls/name/OmegaT -- 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 roblamora at hotmail.com Tue Feb 7 02:12:57 2012 From: roblamora at hotmail.com (Rob LaMora) Date: Mon, 6 Feb 2012 21:12:57 -0500 Subject: [publican-list] Website ToC Structure Message-ID: Hi, I am unable to emulate the RedHat product documentation website table of contents that does not include a version number expand/collapse section. Regardless of what I try I still get a version number component. Does anyone know how to accomplish this? Thanks, Rob Sent from my Kindle Fire -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlackey at redhat.com Tue Feb 7 02:46:02 2012 From: dlackey at redhat.com (E Deon Lackey) Date: Mon, 06 Feb 2012 20:46:02 -0600 Subject: [publican-list] Website ToC Structure In-Reply-To: References: Message-ID: <4F30906A.4080901@redhat.com> On 2/6/2012 8:12 PM, Rob LaMora wrote: > > Hi, > > I am unable to emulate the RedHat product documentation website table > of contents that does not include a version number expand/collapse > section. Regardless of what I try I still get a version number > component. Does anyone know how to accomplish this? > In your publican.cfg file, add this line: web_version_label: UNUSED That should do it! Deon From roblamora at hotmail.com Thu Feb 9 02:26:09 2012 From: roblamora at hotmail.com (Rob LaMora) Date: Wed, 8 Feb 2012 21:26:09 -0500 Subject: [publican-list] Install Set In-Reply-To: <4F30906A.4080901@redhat.com> References: <4F30906A.4080901@redhat.com> Message-ID: Is there a command that lets you install a documentation set to a website? Seems like the build can be run across a set but not the install? Thanks as always for the great help. Rob Sent from my Kindle Fire _____________________________________________ From: E Deon Lackey Sent: Mon Feb 06 21:46:02 EST 2012 To: Publican discussions Cc: Rob LaMora Subject: Re: [publican-list] Website ToC Structure On 2/6/2012 8:12 PM, Rob LaMora wrote: > > Hi, > > I am unable to emulate the RedHat product documentation website table > of contents that does not include a version number expand/collapse > section. Regardless of what I try I still get a version number > component. Does anyone know how to accomplish this? > In your publican.cfg file, add this line: web_version_label: UNUSED That should do it! Deon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlackey at redhat.com Thu Feb 9 03:25:50 2012 From: dlackey at redhat.com (E Deon Lackey) Date: Wed, 08 Feb 2012 21:25:50 -0600 Subject: [publican-list] Install Set In-Reply-To: References: <4F30906A.4080901@redhat.com> Message-ID: <4F333CBE.8030806@redhat.com> Yep. First you build the docs in whatever format you want, and then you use "publican install_book" and point it to the (local) site directory. Real instructions are here: http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Users_Guide/sect-Users_Guide-Website.html On 2/8/2012 8:26 PM, Rob LaMora wrote: > > Is there a command that lets you install a documentation set to a > website? Seems like the build can be run across a set but not the install? > > Thanks as always for the great help. > > Rob > > Sent from my Kindle Fire > > ------------------------------------------------------------------------ > *From:* E Deon Lackey > *Sent:* Mon Feb 06 21:46:02 EST 2012 > *To:* Publican discussions > *Cc:* Rob LaMora > *Subject:* Re: [publican-list] Website ToC Structure > > On 2/6/2012 8:12 PM, Rob LaMora wrote: > > > > Hi, > > > > I am unable to emulate the RedHat product documentation website table > > of contents that does not include a version number expand/collapse > > section. Regardless of what I try I still get a version number > > component. Does anyone know how to accomplish this? > > > > > In your publican.cfg file, add this line: > > web_version_label: UNUSED > > That should do it! > Deon > > > > _______________________________________________ > 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 roblamora at hotmail.com Thu Feb 9 22:31:45 2012 From: roblamora at hotmail.com (Rob LaMora) Date: Thu, 9 Feb 2012 17:31:45 -0500 Subject: [publican-list] publican-list Digest, Vol 47, Issue 8 In-Reply-To: References: Message-ID: So if I need to install several documents to a website under one product name (say "Product Widget"), should I use separate books within a set or something else? The format I need is: +-- Product Widget | - User Guide | - FAQs | - Reference Thanks for the help... just trying to figure out which XML files I need to modify to accomplish this. Rob > From: publican-list-request at redhat.com > Subject: publican-list Digest, Vol 47, Issue 8 > To: publican-list at redhat.com > Date: Thu, 9 Feb 2012 12:00:04 -0500 > > Send publican-list mailing list submissions to > publican-list at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/publican-list > or, via email, send a message with subject or body 'help' to > publican-list-request at redhat.com > > You can reach the person managing the list at > publican-list-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of publican-list digest..." > > > Today's Topics: > > 1. Install Set (Rob LaMora) > 2. Re: Install Set (E Deon Lackey) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 8 Feb 2012 21:26:09 -0500 > From: Rob LaMora > To: publican-list at redhat.com > Subject: [publican-list] Install Set > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Is there a command that lets you install a documentation set to a website? Seems like the build can be run across a set but not the install? > > Thanks as always for the great help. > > Rob > > Sent from my Kindle Fire > > _____________________________________________ > From: E Deon Lackey > Sent: Mon Feb 06 21:46:02 EST 2012 > To: Publican discussions > Cc: Rob LaMora > Subject: Re: [publican-list] Website ToC Structure > > > On 2/6/2012 8:12 PM, Rob LaMora wrote: > > > > Hi, > > > > I am unable to emulate the RedHat product documentation website table > > of contents that does not include a version number expand/collapse > > section. Regardless of what I try I still get a version number > > component. Does anyone know how to accomplish this? > > > > > In your publican.cfg file, add this line: > > web_version_label: UNUSED > > That should do it! > Deon > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Wed, 08 Feb 2012 21:25:50 -0600 > From: E Deon Lackey > To: publican-list at redhat.com > Subject: Re: [publican-list] Install Set > Message-ID: <4F333CBE.8030806 at redhat.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Yep. First you build the docs in whatever format you want, and then you > use "publican install_book" and point it to the (local) site directory. > > Real instructions are here: > http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Users_Guide/sect-Users_Guide-Website.html > > > On 2/8/2012 8:26 PM, Rob LaMora wrote: > > > > Is there a command that lets you install a documentation set to a > > website? Seems like the build can be run across a set but not the install? > > > > Thanks as always for the great help. > > > > Rob > > > > Sent from my Kindle Fire > > > > ------------------------------------------------------------------------ > > *From:* E Deon Lackey > > *Sent:* Mon Feb 06 21:46:02 EST 2012 > > *To:* Publican discussions > > *Cc:* Rob LaMora > > *Subject:* Re: [publican-list] Website ToC Structure > > > > On 2/6/2012 8:12 PM, Rob LaMora wrote: > > > > > > Hi, > > > > > > I am unable to emulate the RedHat product documentation website table > > > of contents that does not include a version number expand/collapse > > > section. Regardless of what I try I still get a version number > > > component. Does anyone know how to accomplish this? > > > > > > > > > In your publican.cfg file, add this line: > > > > web_version_label: UNUSED > > > > That should do it! > > Deon > > > > > > > > _______________________________________________ > > 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: > > ------------------------------ > > _______________________________________________ > publican-list mailing list > publican-list at redhat.com > https://www.redhat.com/mailman/listinfo/publican-list > > End of publican-list Digest, Vol 47, Issue 8 > ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdalrymple at redhat.com Fri Feb 10 15:58:12 2012 From: fdalrymple at redhat.com (Fred Dalrymple) Date: Fri, 10 Feb 2012 10:58:12 -0500 (EST) Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: <20120203090855.GA5909@bowman.infotech.monash.edu.au> Message-ID: Hi Peter -- If I'm reading your post correctly... You're saying that simply invoking a locale-specific collating sequence during publishing (i.e., with no additional collating clues provided) may produce results acceptable to each locale? Unless anyone knows otherwise, it sounds like that hypothesis is worth testing: select/create a source document with enough collating edge conditions, format locale-specific versions, and have the results reviewed by locale-skilled readers. If it works, obviously it's a lot easier than building a new solution... Thanks -- Fred ----- Original Message ----- > On Tue, Jan 31, 2012 at 06:45:12PM +1100, I wrote: > > Apparently, the mapping from a string of Kanji to its pronunciation > > (ordering) isn't even a deterministic operation, at least for > > proper > > names. > (Of course I meant "proper nouns". Actual non-determinism might even > be > limited to proper nouns, though I'm not sure that that changes > anything > from a coding point of view.) > > Thus, the solution would have to involve supplying pronunciations > > somehow > > for at least some glossary entries. > More precisely, it follows that sorting Kanji entries by > pronunciation > would in general require supplying pronunciations for some entries. > However, I don't want my unclear wording to contribute to wrong > conclusions about what Publican actually requires: I'm not in a > position > to say whether Publican requires index or glossary entries involving > Kanji to be sorted by contextually-correct pronunciation. All I've > learnt over the past couple of days is that *outside of* a book index > or > glossary, Kanji are sorted sometimes by contextually-correct > pronunciation and sometimes by some other order (and I think there's > more > than one alternative, even). > If anyone wants a concrete sample for an "is this output acceptable" > question (and if not using software just for japanese sorting, like > Lingua::JA::Sort::JIS), then I suggest making sure that the collation > function is tailored for a Japanese locale (e.g. using > Unicode::Collate::Locale->new(locale => 'ja-JP')): without that, > collation software is unlikely to try to use a specifically-japanese > ordering of Kanji characters or intersperse Katakana with Hiragana. > In particular, the documentation for plain Unicode::Collate is > explicit > that it doesn't intersperse Katakana with Hiragana, and that its > Kanji > ordering is simply by unicode block & code point rather than by a JIS > ordering. > So I think the easiest thing to do that has a good chance of getting > a > "yes, this is acceptable" answer would be to switch from > Unicode::Collate > to Unicode::Collate::Locale and pass locale => $LANG to the > constructor > (where $LANG is the Publican language like en-US or ja-JP). > Effect on other languages: > Switching to a locale-sensitive collator might also make for a better > collation of Indic languages (handling of virama, and some related > reordering rules). > Whereas if applied to Spanish for indexes, note that it might move > entries like chkconfig from near the beginning of the C entries to > just > before D; it's not clear to me whether that's a good or bad thing for > a > word like chkconfig that isn't even spanish and thus arguably isn't > using > the Spanish ch digraph. > (In both cases, I haven't actually tested the behaviour, nor have I > asked > a native speaker for their preferences for index/glossary sorting in > technical documentation.) > pjrm. > _______________________________________________ > 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 Mon Feb 13 04:01:23 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Mon, 13 Feb 2012 14:01:23 +1000 Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: References: Message-ID: <4F388B13.1050002@redhat.com> On 02/11/2012 01:58 AM, Fred Dalrymple wrote: > Hi Peter -- > > If I'm reading your post correctly... You're saying that simply invoking > a locale-specific collating sequence during publishing (i.e., with no > additional collating clues provided) may produce results acceptable to > each locale? > > Unless anyone knows otherwise, it sounds like that hypothesis is worth > testing: select/create a source document with enough collating edge > conditions, format locale-specific versions, and have the results > reviewed by locale-skilled readers. > > If it works, obviously it's a lot easier than building a new solution... The link I posted to "a good explanation of the issues" is for the tests we ran using unicode collation. https://www.redhat.com/archives/publican-list/2010-May/msg00025.html Cheers, Jeff. From jfearn at redhat.com Tue Feb 14 03:57:59 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 14 Feb 2012 13:57:59 +1000 Subject: [publican-list] Publican 2.9/3.0 Plans Message-ID: <4F39DBC7.8060403@redhat.com> Hi all, people watching the SVN repo might have noticed quite a bit of work in the 2x branch and a slowing down of work on trunk. This has been because we are doing a lot of work to the website structure on the 2x branch to alleviate scaling issues in the web site menu structure, and the 3.0 trunk has stalled somewhat waiting for DocBook 5.1 to arrive. Rudi and I had a chat today and went over all the bugs for 2.9 and 3.0 and asked how long should we hold back 3.0 for DocBook 5.1? We have decided that we will be releasing 3.0 with DocBook 5 as a tech preview. This will allow us to get a lot of the DocBook 5 code in place so people can test it easily, but allow us to release all the other features quickly. There will be some work required making sure that DocBook 4 and 5 work well side by side, a lot of work testing the integration of patch sets from the 2x branch, and some effort testing the new features. We hope to have a public test site for the web redesign up on the 26th for general input. We hope to release 3.0 two weeks after that. It's quite a tight dead line but barring disastrous feedback, or me getting my time reallocated at work, we should be able to hit this with support from the E.C.S. guys and girls testing things for us. I've already ported most of the 2.9 changes to trunk, but I haven't done a lot of testing on it, so it'll probably be a place for fools rather than angels for a few days ;) This is a complete list of all bugs targeted for 2.9 and 3.0 [1] we will be pushing some of the DocBook 5 bugs to 3.1. Anything in the state 'MODIFIED' will be shipping in 3.0. Cheers, Jeff. 1: https://bugzilla.redhat.com/buglist.cgi?columnlist=target_milestone%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc&component=publican&product=Publican&query_format=advanced&target_milestone=2.9&target_milestone=3.0&order=bug_status%2Ctarget_milestone%2Ctarget_release%2Cbug_severity%2Cchangeddate%20DESC&query_based_on= From peter.moulder at monash.edu Tue Feb 14 04:28:25 2012 From: peter.moulder at monash.edu (Peter Moulder) Date: Tue, 14 Feb 2012 15:28:25 +1100 Subject: [publican-list] sortable lists, esp. glossaries In-Reply-To: <4F388B13.1050002@redhat.com> References: <4F388B13.1050002@redhat.com> Message-ID: <20120214042825.GA8975@bowman.infotech.monash.edu.au> On Mon, Feb 13, 2012 at 02:01:23PM +1000, Jeff Fearn wrote: > On 02/11/2012 01:58 AM, Fred Dalrymple wrote: > >If I'm reading your post correctly... You're saying that simply invoking > >a locale-specific collating sequence during publishing (i.e., with no > >additional collating clues provided) may produce results acceptable to > >each locale? Choosing an order for things is harder than one might think even in English (deciding whether to ignore a leading "The", deciding how to treat spaces or punctuation). But if the emphasis is on "acceptable" rather than "exactly as a careful human expert might decide", and if "each locale" is understood to be restricted to something like "each locale used by known Publican users" (so excluding Cuneiform, Klingon and so on); then yes, that would be the hypothesis at least. > The link I posted to "a good explanation of the issues" is for the > tests we ran using unicode collation. > > https://www.redhat.com/archives/publican-list/2010-May/msg00025.html Here it's important to distinguish between "unicode collation" in the sense of the default unicode collation, and "unicode collation" when using the cldr tailorings. The above-linked message says that "we're getting all the Katakana first, then all the Hiragana", whereas Unicode::Collate::Locale intersperses Katakana and Hiragana when told to use a 'ja' locale. [I must say that the result doesn't look to me like it's sorted "according to pronunciation", if I may judge solely from the latin names of the Hiragana and Katakana, and I was surprised to find that any latin characters after the Hiragana / Katakana affects the ordering in a complex way; but certainly Hiragana and Katakana entries are interspersed in the resulting sorted list.] Btw, the possible issue I mentioned about Spanish seems to be out of date: the official rules have now changed, such that ch is now to be sorted between cg and ci, as in most other languages. I've checked that Unicode::Collate::Locale does indeed sort ch before ci with locale set to 'es' or 'es-ES', which is what we want. (The old rules are available by setting locale to 'es-ES-traditional'.) pjrm. From bugzilla at redhat.com Fri Feb 17 01:04:45 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 16 Feb 2012 20:04:45 -0500 Subject: [publican-list] [Bug 706302] RFE: Improvements to publican-jboss brand for better docs bug BZ integration. In-Reply-To: References: Message-ID: <201202170104.q1H14jAh009143@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=706302 Jared MORGAN changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |CURRENTRELEASE Last Closed| |2012-02-16 20:04:43 --- Comment #7 from Jared MORGAN 2012-02-16 20:04:43 EST --- Rudi triaged the issue and deemed it not to be a translation risk (only urls and non-translated component strings). He implemented changes to the publican brand that allows BZURL to be supported in the .ent file. You have to add the entities manually to the .ent file. This issue is therefore resolved from my perspective. -- 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 Sun Feb 19 23:44:32 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2012 18:44:32 -0500 Subject: [publican-list] [Bug 724850] RFE: print_unused images? In-Reply-To: References: Message-ID: <201202192344.q1JNiWmJ029831@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=724850 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.9 |3.0 -- 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 Sun Feb 19 23:44:33 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2012 18:44:33 -0500 Subject: [publican-list] [Bug 687894] rendering of steps inside stepalternatives In-Reply-To: References: Message-ID: <201202192344.q1JNiXSe029839@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=687894 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.9 |3.0 -- 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 Sun Feb 19 23:44:28 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2012 18:44:28 -0500 Subject: [publican-list] [Bug 726548] tags display an "Unvalidated Tag Warning" In-Reply-To: References: Message-ID: <201202192344.q1JNiS5m029806@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=726548 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.9 |3.0 -- 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 Sun Feb 19 23:44:31 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2012 18:44:31 -0500 Subject: [publican-list] [Bug 734154] blockquote with the attribution element renders as a table In-Reply-To: References: Message-ID: <201202192344.q1JNiVS3029821@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=734154 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.9 |3.0 -- 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 Sun Feb 19 23:44:36 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 19 Feb 2012 18:44:36 -0500 Subject: [publican-list] [Bug 705953] Formatting issues in PDF version of HTTP Connectors Load Balancing Guide In-Reply-To: References: Message-ID: <201202192344.q1JNiaEZ029853@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=705953 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.9 |3.0 -- 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 Feb 20 06:25:16 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 20 Feb 2012 01:25:16 -0500 Subject: [publican-list] [Bug 711348] Linking to a bridgehead does not work in html formats In-Reply-To: References: Message-ID: <201202200625.q1K6PG83009632@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=711348 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED Fixed In Version|2.3 | Target Milestone|--- |3.0 --- Comment #4 from Jeff Fearn 2012-02-20 01:25:15 EST --- hmm must have been reverted at some time... Reapplied patch to trunk. Committed revision 2022. -- 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 Feb 21 05:20:12 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2012 00:20:12 -0500 Subject: [publican-list] [Bug 628786] emphasis, citetitle, and xref don't render in Japanese PDFs In-Reply-To: References: Message-ID: <201202210520.q1L5KCKl017237@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=628786 --- Comment #10 from Noriko Mizumoto 2012-02-21 00:20:02 EST --- This problem has been reported with Bug 784132 again. RHEV Admin GD and RHEV REST API GD are also affected. -- 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 Feb 21 05:49:00 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2012 00:49:00 -0500 Subject: [publican-list] [Bug 628786] emphasis, citetitle, and xref don't render in Japanese PDFs In-Reply-To: References: Message-ID: <201202210549.q1L5n0Mb031725@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=628786 Noriko Mizumoto changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |etowns at redhat.com --- Comment #12 from Noriko Mizumoto 2012-02-21 00:48:58 EST --- *** Bug 784132 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 Feb 21 05:47:12 2012 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 21 Feb 2012 00:47:12 -0500 Subject: [publican-list] [Bug 628786] emphasis, citetitle, and xref don't render in Japanese PDFs In-Reply-To: References: Message-ID: <201202210547.q1L5lCwD031270@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=628786 Manuel Ospina changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |ASSIGNED CC| |mospina at redhat.com Resolution|ERRATA | Keywords| |Reopened --- Comment #11 from Manuel Ospina 2012-02-21 00:47:11 EST --- trying to reopen this bug as the problem is still present in Japanese (see Comment 10) -- 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 hertzog at debian.org Mon Feb 27 10:46:44 2012 From: hertzog at debian.org (Raphael Hertzog) Date: Mon, 27 Feb 2012 11:46:44 +0100 Subject: [publican-list] annoying perl warnings with publican 2.9 Message-ID: <20120227104644.GA6750@rivendell.home.ouaza.com> Hello, I am running publican 2.9 (publican-2x, commit r2011) and it spews lots of warnings on me: Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 724. Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 732. [ ... Several duplicates of the above warnings ... ] Use of uninitialized value $product in string eq at /usr/share/perl5/Publican/Builder.pm line 2273. Use of uninitialized value $RPM_VERSION in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 860. Use of uninitialized value $RPM_RELEASE in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 860. And this even if the product name is set in the XML, etc. In any case, it should either fail when some important information is missing and properly initialize unset variables otherwise. Thank you. Let me know if you prefer that I file this in a ticket. Cheers, -- Rapha?l Hertzog ? Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ From jfearn at redhat.com Tue Feb 28 00:15:15 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 28 Feb 2012 10:15:15 +1000 Subject: [publican-list] annoying perl warnings with publican 2.9 In-Reply-To: <20120227104644.GA6750@rivendell.home.ouaza.com> References: <20120227104644.GA6750@rivendell.home.ouaza.com> Message-ID: <4F4C1C93.6080402@redhat.com> On 02/27/2012 08:46 PM, Raphael Hertzog wrote: > Hello, > > I am running publican 2.9 (publican-2x, commit r2011) and it spews lots > of warnings on me: > > Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 724. > Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 732. > [ ... Several duplicates of the above warnings ... ] > Use of uninitialized value $product in string eq at /usr/share/perl5/Publican/Builder.pm line 2273. > Use of uninitialized value $RPM_VERSION in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 860. > Use of uninitialized value $RPM_RELEASE in concatenation (.) or string at /usr/share/perl5/Publican/Builder.pm line 860. > > And this even if the product name is set in the XML, etc. In any case, it > should either fail when some important information is missing and properly > initialize unset variables otherwise. > > Thank you. Let me know if you prefer that I file this in a ticket. > > Cheers, Hi Raphael, I've migrated all the 2.9 changes to trunk and am fixing everything there now. Do you get the same issue with trunk? There are a bunch more changes in trunk, so it might be a bit intrusive in some ways. Cheers, Jeff. From jfearn at redhat.com Tue Feb 28 00:16:42 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Tue, 28 Feb 2012 10:16:42 +1000 Subject: [publican-list] annoying perl warnings with publican 2.9 In-Reply-To: <4F4C1C93.6080402@redhat.com> References: <20120227104644.GA6750@rivendell.home.ouaza.com> <4F4C1C93.6080402@redhat.com> Message-ID: <4F4C1CEA.5050902@redhat.com> On 02/28/2012 10:15 AM, Jeff Fearn wrote: > On 02/27/2012 08:46 PM, Raphael Hertzog wrote: >> Hello, >> >> I am running publican 2.9 (publican-2x, commit r2011) and it spews lots >> of warnings on me: >> >> Use of uninitialized value in concatenation (.) or string at >> /usr/share/perl5/Publican/Builder.pm line 724. >> Use of uninitialized value in concatenation (.) or string at >> /usr/share/perl5/Publican/Builder.pm line 732. >> [ ... Several duplicates of the above warnings ... ] >> Use of uninitialized value $product in string eq at >> /usr/share/perl5/Publican/Builder.pm line 2273. >> Use of uninitialized value $RPM_VERSION in concatenation (.) or string >> at /usr/share/perl5/Publican/Builder.pm line 860. >> Use of uninitialized value $RPM_RELEASE in concatenation (.) or string >> at /usr/share/perl5/Publican/Builder.pm line 860. >> >> And this even if the product name is set in the XML, etc. In any case, it >> should either fail when some important information is missing and >> properly >> initialize unset variables otherwise. >> >> Thank you. Let me know if you prefer that I file this in a ticket. >> >> Cheers, > > Hi Raphael, I've migrated all the 2.9 changes to trunk and am fixing > everything there now. Do you get the same issue with trunk? > > There are a bunch more changes in trunk, so it might be a bit intrusive > in some ways. Jeff. From hertzog at debian.org Tue Feb 28 07:56:54 2012 From: hertzog at debian.org (Raphael Hertzog) Date: Tue, 28 Feb 2012 08:56:54 +0100 Subject: [publican-list] annoying perl warnings with publican 2.9 In-Reply-To: <4F4C1CEA.5050902@redhat.com> <4F4C1C93.6080402@redhat.com> Message-ID: <20120228075654.GD20677@rivendell.home.ouaza.com> On Tue, 28 Feb 2012, Jeff Fearn wrote: > Hi Raphael, I've migrated all the 2.9 changes to trunk and am fixing > everything there now. Do you get the same issue with trunk? Does trunk support both docbook 4.x and 5.x? I will try anyway and report. > +1 Any reason why you can't switch? (I have a git svn of publican for my own needs when I have to hack on it) Cheers, -- Rapha?l Hertzog ? Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ From jfearn at redhat.com Tue Feb 28 23:05:28 2012 From: jfearn at redhat.com (Jeff Fearn) Date: Wed, 29 Feb 2012 09:05:28 +1000 Subject: [publican-list] annoying perl warnings with publican 2.9 In-Reply-To: <20120228075654.GD20677@rivendell.home.ouaza.com> References: <20120228075654.GD20677@rivendell.home.ouaza.com> Message-ID: <4F4D5DB8.7000908@redhat.com> On 02/28/2012 05:56 PM, Raphael Hertzog wrote: > On Tue, 28 Feb 2012, Jeff Fearn wrote: >> Hi Raphael, I've migrated all the 2.9 changes to trunk and am fixing >> everything there now. Do you get the same issue with trunk? > > Does trunk support both docbook 4.x and 5.x? It has basic support for DB5, but it defaults to DB4.5. If you set dtd_ver to 5... it'll switch to DB5 processing. It's not very polished ATM. > I will try anyway and report. > >> > > +1 Any reason why you can't switch? Only inertia. I've got so many things to do that switching to git hasn't bubbled to the top yet. > (I have a git svn of publican for my own needs when I have to hack on it) I should do that myself one day, it'd no doubt motivate me more to move in the long run. Cheers, Jeff. -- "Reply All" why you shouldn't use it: http://www.emailreplies.com/#12replytoall