From mospina at redhat.com Tue Dec 1 00:20:05 2009 From: mospina at redhat.com (Manuel Ospina) Date: Tue, 01 Dec 2009 10:20:05 +1000 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B143AFD.7050102@redhat.com> References: <4B143AFD.7050102@redhat.com> Message-ID: <4B146135.204@redhat.com> Jeffrey Fearn wrote: > Eric Christensen wrote: >> Just wanted to point out that the current Publican build, 1.x, is >> creating SRPMs and spec files that are inline with the Fedora's >> packaging policy (using the --short_sighted mode). I submitted[1] a >> package for the Fedora Accessibility Guide for review and it passed >> without batting an eye. This should be helpful for other guides as >> well. >> >> I'm still pondering the best way to handle the different languages, >> though. > > I will remind everyone that the reason we do the languages separately > is that it proved impossible to keep a sane translation work flow with > a single SRPM. This isn't a guess, we expended significant energy > trying to make it work pre-RHEL5 and it proved unworkable for > non-trivial content. > > Unless someone has a cogent approach to solving this then you are > better off sucking it up and using separate SRPMs. > > If someone does have a cogent approach I am more than willing to help > implement it. > > If you are a translator and care about the effects of this kind of > approach then now is the time to speak up. I mean really, if you don't > care enough to speak about it then maybe I am misremembering how bad > it was. > > Cheers, Jeff. > Totally agree. Using separate SRPMs is important to keep a maintainable/scalable localization work-flow. Cheers -- Manuel Ospina Supervisor, Localization Services Red Hat Asia-Pacific Phone: +61 7 3514 8112 Mobile: +61 413 228 601 From eric at christensenplace.us Tue Dec 1 00:27:15 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 30 Nov 2009 19:27:15 -0500 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B146135.204@redhat.com> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> Message-ID: <4B1462E3.2040407@christensenplace.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/30/2009 07:20 PM, Manuel Ospina wrote: > Jeffrey Fearn wrote: >> Eric Christensen wrote: >>> Just wanted to point out that the current Publican build, 1.x, is >>> creating SRPMs and spec files that are inline with the Fedora's >>> packaging policy (using the --short_sighted mode). I submitted[1] a >>> package for the Fedora Accessibility Guide for review and it passed >>> without batting an eye. This should be helpful for other guides as >>> well. >>> >>> I'm still pondering the best way to handle the different languages, >>> though. >> >> I will remind everyone that the reason we do the languages separately >> is that it proved impossible to keep a sane translation work flow with >> a single SRPM. This isn't a guess, we expended significant energy >> trying to make it work pre-RHEL5 and it proved unworkable for >> non-trivial content. >> >> Unless someone has a cogent approach to solving this then you are >> better off sucking it up and using separate SRPMs. >> >> If someone does have a cogent approach I am more than willing to help >> implement it. >> >> If you are a translator and care about the effects of this kind of >> approach then now is the time to speak up. I mean really, if you don't >> care enough to speak about it then maybe I am misremembering how bad >> it was. >> >> Cheers, Jeff. >> > Totally agree. Using separate SRPMs is important to keep a > maintainable/scalable localization work-flow. > > Cheers > That makes sense if you don't have a single maintainer of the SRPMS. For the Fedora guides and articles (like the Release Notes) there is a single maintainer of the SRPM. So as translations are completed for the Release Notes the maintainer adds them to the SPRM and does the update in the packaging system. This has the benefit of including a single package in the release that Yelp will automagically select the proper language for the user. This is quite important as so the end user won't have to do anything but select the document they are wanting to read. No fuss. - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksUYuIACgkQfQTSQL0MFME2bACg0ZARX6w8lmlw25m+IbvbCr8s LD4AnAuDEry/jKGdYdI9/bcHd9fAWNMH =07Dy -----END PGP SIGNATURE----- From jfearn at redhat.com Tue Dec 1 01:00:40 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Tue, 01 Dec 2009 11:00:40 +1000 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B1462E3.2040407@christensenplace.us> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> <4B1462E3.2040407@christensenplace.us> Message-ID: <4B146AB8.3000802@redhat.com> Eric Christensen wrote: >> Totally agree. Using separate SRPMs is important to keep a >> maintainable/scalable localization work-flow. >> >> Cheers >> > > That makes sense if you don't have a single maintainer of the SRPMS. > For the Fedora guides and articles (like the Release Notes) there is a > single maintainer of the SRPM. This is the scenario we tested pre-RHEL 5 and having a gate keeper for all languages proved to be one of the biggest problems. It simply does not scale, the gate keeper gets swamped, updates get delayed, and the system falls down. We were dealing with less than half the languages Fedora supports and we had a dedicated team of full timers on hand, so this is not a trivial problem in the Fedora space. > So as translations are completed for the > Release Notes the maintainer adds them to the SPRM and does the update > in the packaging system. This failed miserably when we tried this, how are you going to make it work without changing the approach? I'll concede that the release notes have a special place somewhere between help text and stand alone docs, but because of this it is a poor example of why you'd add this to a system dedicated to packaging stand alone documentation. > This has the benefit of including a single package in the release that > Yelp will automagically select the proper language for the user. Yelp is less than optimal for many reasons, such as: you just lost all your branding, you are tied to a single desktop, you just increased the payload by 50 times, you are ignoring section 508 compliance, etc. > This > is quite important as so the end user won't have to do anything but > select the document they are wanting to read. No fuss. You can do that without yelp, without coupling to a particular desktop, without losing the section 508 work we have done, without over riding their chosen HTML viewer, etc. I'm still waiting for an approach that isn't "we will do it the same way you did it when it failed, but it will just work now (TM)." Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From eric at christensenplace.us Tue Dec 1 01:04:31 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 30 Nov 2009 20:04:31 -0500 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B146AB8.3000802@redhat.com> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> <4B1462E3.2040407@christensenplace.us> <4B146AB8.3000802@redhat.com> Message-ID: <4B146B9F.6080000@christensenplace.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/30/2009 08:00 PM, Jeffrey Fearn wrote: > Eric Christensen wrote: >>> Totally agree. Using separate SRPMs is important to keep a >>> maintainable/scalable localization work-flow. >>> >>> Cheers >>> >> >> That makes sense if you don't have a single maintainer of the SRPMS. >> For the Fedora guides and articles (like the Release Notes) there is a >> single maintainer of the SRPM. > > This is the scenario we tested pre-RHEL 5 and having a gate keeper for > all languages proved to be one of the biggest problems. It simply does > not scale, the gate keeper gets swamped, updates get delayed, and the > system falls down. > > We were dealing with less than half the languages Fedora supports and we > had a dedicated team of full timers on hand, so this is not a trivial > problem in the Fedora space. > >> So as translations are completed for the >> Release Notes the maintainer adds them to the SPRM and does the update >> in the packaging system. > > This failed miserably when we tried this, how are you going to make it > work without changing the approach? > > I'll concede that the release notes have a special place somewhere > between help text and stand alone docs, but because of this it is a poor > example of why you'd add this to a system dedicated to packaging stand > alone documentation. > >> This has the benefit of including a single package in the release that >> Yelp will automagically select the proper language for the user. > > Yelp is less than optimal for many reasons, such as: you just lost all > your branding, you are tied to a single desktop, you just increased the > payload by 50 times, you are ignoring section 508 compliance, etc. > >> This >> is quite important as so the end user won't have to do anything but >> select the document they are wanting to read. No fuss. > > You can do that without yelp, without coupling to a particular desktop, > without losing the section 508 work we have done, without over riding > their chosen HTML viewer, etc. > > I'm still waiting for an approach that isn't "we will do it the same way > you did it when it failed, but it will just work now (TM)." > > Cheers, Jeff. > I'm interested to hear your solution. I need to be able to have a user that installs Fedora to NOT have to choose the language for each document that they use (since they already selected the language during install). I'm not asking you to change the way you do business in RHEL. I'm simply asking for the freedom to let me do business the way we know it works in Fedora. I'm open to new ideas, though, so if you have a way to make it as easy on the end user I'm all ears. - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksUa58ACgkQfQTSQL0MFMFoEACg0ugdPH8jHJ6w3riX9q791eE3 SvoAn1PAHLphaitoWr2V4pP7MAJNCzZc =SQsA -----END PGP SIGNATURE----- From jfearn at redhat.com Tue Dec 1 01:27:43 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Tue, 01 Dec 2009 11:27:43 +1000 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B146B9F.6080000@christensenplace.us> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> <4B1462E3.2040407@christensenplace.us> <4B146AB8.3000802@redhat.com> <4B146B9F.6080000@christensenplace.us> Message-ID: <4B14710F.1060503@redhat.com> Eric Christensen wrote: > > I'm interested to hear your solution. I need to be able to have a user > that installs Fedora to NOT have to choose the language for each > document that they use (since they already selected the language during > install). I've repeatedly stated the approach that you want has been tested and fails, and that I'm happy to listen to any ideas on how to fix that approach, clearly if I had a fix I'd impliment it. > I'm not asking you to change the way you do business in RHEL. I'm > simply asking for the freedom to let me do business the way we know it > works in Fedora. You are free to automate anything you want, whether or not I chose to automate it for you has nothing to do with your freedom and everything to do with mine. We tested that idea, it fails, I don't want to ship software I know fails, complaining I'm restricting your freedom by excessing good over site does not seem cogent. You can use publican inside any spec file, so lack of automation in publican is not locking you in to anything and is in no way preventing you from exercising your freedom and using the content however you want. There is a good example of using publican inside a non-publican generated spec file in publican's own spec file. I'm happy to look at any use of publican in spec files and give feedback on how to improve it. > I'm open to new ideas, though, so if you have a way to > make it as easy on the end user I'm all ears. If you have a way to make a system that failed real world testing work, I am all ears. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From eric at christensenplace.us Tue Dec 1 01:48:34 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 30 Nov 2009 20:48:34 -0500 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B14710F.1060503@redhat.com> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> <4B1462E3.2040407@christensenplace.us> <4B146AB8.3000802@redhat.com> <4B146B9F.6080000@christensenplace.us> <4B14710F.1060503@redhat.com> Message-ID: <4B1475F2.8070106@christensenplace.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/30/2009 08:27 PM, Jeffrey Fearn wrote: > Eric Christensen wrote: >> >> I'm interested to hear your solution. I need to be able to have a user >> that installs Fedora to NOT have to choose the language for each >> document that they use (since they already selected the language during >> install). > > I've repeatedly stated the approach that you want has been tested and > fails, and that I'm happy to listen to any ideas on how to fix that > approach, clearly if I had a fix I'd impliment it. > >> I'm not asking you to change the way you do business in RHEL. I'm >> simply asking for the freedom to let me do business the way we know it >> works in Fedora. > > You are free to automate anything you want, whether or not I chose to > automate it for you has nothing to do with your freedom and everything > to do with mine. > > We tested that idea, it fails, I don't want to ship software I know > fails, complaining I'm restricting your freedom by excessing good over > site does not seem cogent. > > You can use publican inside any spec file, so lack of automation in > publican is not locking you in to anything and is in no way preventing > you from exercising your freedom and using the content however you want. > > There is a good example of using publican inside a non-publican > generated spec file in publican's own spec file. I'm happy to look at > any use of publican in spec files and give feedback on how to improve it. > >> I'm open to new ideas, though, so if you have a way to >> make it as easy on the end user I'm all ears. > > If you have a way to make a system that failed real world testing work, > I am all ears. > > Cheers, Jeff. > I don't know, Jeff. It doesn't appear to fail for us. The Fedora release notes were built with Publican and then combined to form a single SRPM using an additional step outside of Publican. We push that single SRPM out and people end up with the Release Notes on their desktop in their local language that they selected for the entire system. Perhaps our implementation is different? - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksUdfIACgkQfQTSQL0MFME9hQCgjXJeeEcOlj9bO1sTh74+lYWe h1IAn32D7F36gLwKIe4hB6PFRH5Dmi04 =9xug -----END PGP SIGNATURE----- From bugzilla at redhat.com Tue Dec 1 01:45:09 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 30 Nov 2009 20:45:09 -0500 Subject: [publican-list] [Bug 542524] http://documentation-stage.bne.redhat.com doesn't function as expected under IE7/IE8 In-Reply-To: References: Message-ID: <200912010145.nB11j9nC032675@bz-web1.app.phx.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=542524 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jfearn at redhat.com --- Comment #3 from Jeff Fearn 2009-11-30 20:45:08 EDT --- This is due to window.top.location not working as expected in IE7/8 ... haven't been able to track down an alternative yet. -- 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 Dec 1 02:18:16 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Tue, 01 Dec 2009 12:18:16 +1000 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B147CC3.7020106@redhat.com> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> <4B1462E3.2040407@christensenplace.us> <4B146AB8.3000802@redhat.com> <4B146B9F.6080000@christensenplace.us> <4B14710F.1060503@redhat.com> <4B1475F2.8070106@christensenplace.us> <4B147CC3.7020106@redhat.com> Message-ID: <4B147CE8.2050906@redhat.com> Jeffrey Fearn wrote: > Eric Christensen wrote: >> I don't know, Jeff. It doesn't appear to fail for us. The Fedora >> release notes were built with Publican and then combined to form a >> single SRPM using an additional step outside of Publican. We push that >> single SRPM out and people end up with the Release Notes on their >> desktop in their local language that they selected for the entire >> system. Perhaps our implementation is different? > > It doesn't fail in the sense of you can't install packages, it fails in > the sense of it's not scalable and fails to meet what are IMHO pretty > basic standards for maintainability. > > Using publican to generate arbitrary output is fine, embedding that > process in to publican, requiring us to maintain it and meet the > standards expected of us, is not necessarily fine. In this case I don't > think it's maintainable, so unless you can give me a solution I think is > maintainable it's not going to be embedded in publican ... unless of > course you rustle up someone else to maintain it, in which case, patches > are accepted. > > BTW I haven't been able to check the release notes on rawhide because > yelp is broken. > > Cheers, Jeff. > bah! stupid reply button, I thought we fixed that :( -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From mhideo at redhat.com Tue Dec 1 02:29:15 2009 From: mhideo at redhat.com (Mike Hideo) Date: Tue, 01 Dec 2009 12:29:15 +1000 Subject: [publican-list] Publican SRPMs in Fedora In-Reply-To: <4B146B9F.6080000@christensenplace.us> References: <4B143AFD.7050102@redhat.com> <4B146135.204@redhat.com> <4B1462E3.2040407@christensenplace.us> <4B146AB8.3000802@redhat.com> <4B146B9F.6080000@christensenplace.us> Message-ID: <4B147F7B.7060901@redhat.com> On 12/01/2009 11:04 AM, Eric Christensen wrote: > I'm not asking you to change the way you do business in RHEL. I'm > simply asking for the freedom to let me do business the way we know it > works in Fedora. I'm open to new ideas, though, so if you have a way to > make it as easy on the end user I'm all ears. If you put the l10n'd packages in an entry in the i18n section in the comps.xml it will default install correctly. We have defaulted to English in the comps for other products in the past where translation was missing. then when translation caught up, it was easy to respin just that one package. From experience, this will require oversight and some process documentation. - Mike From jfearn at redhat.com Wed Dec 2 04:31:31 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 02 Dec 2009 14:31:31 +1000 Subject: [publican-list] Publican 1.3 next week. In-Reply-To: <4B0E1037.7080500@redhat.com> References: <4B0E1037.7080500@redhat.com> Message-ID: <4B15EDA3.4010706@redhat.com> FYI we have delayed this for "a bit" to allow the translations for the common content to be updated. I've attached a list of translation statuses in case you are curios about such things. Cheers, Jeff. Jeffrey Fearn wrote: > Hi all, we will be pushing Publican 1.3 next week. We wanted to wait a > bit longer but there are 4 high priority bugs that changed our minds. > > Here is a list of the changes: > > - Fixed --version BZ #533081 > - Fixed empty params in new book cfg file. BZ #533322 > - Fixed clean_ids taking too long. > - Added nowait option for brew. > - Improved epub support. BZ #536706 > - Add missing rpm-build req. BZ #537970 > - Changed ol ol style. BZ #537256 > - Fix missing revision history field crash. BZ #539741 > - Fix bug in condition logic in XmlClean. BZ #540685 > - Add translation stats. BZ #540696 > - Stopped processing xml files in extras dir. BZ #540383 > - Fixed callout rendering. BZ #531686 > - Fix wrong docs for condition usage. BZ #540691 > - Remove list style from stepalternatives. BZ #511404 > - Force step::para to keep-with-next if followed by a figure. > > My personal favorites are: > > 1: epub target now generates a fully formed and valid epub file* > > 2: callout list layout no longer makes you vomit! > > Cheers, Jeff. > > * Thanks to Ryan for testing the rather _large_ deployment guide! > -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: all_langs.txt URL: From jfearn at redhat.com Wed Dec 2 05:39:56 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Wed, 02 Dec 2009 15:39:56 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 Message-ID: <4B15FDAC.9020007@redhat.com> Hi, I have been giving some thought to the issues around the formatting of articles vs books, and thought I'd poll the list for input. The question of layout seems to depend on what the fundamental difference between a book and an article is. The answer appears to be not much. If this is the case there is no need to have a layout that varies more than required by the minimal structural differences between a book and an article then. So, as a base, an article should look pretty much like a book ... but why bother having articles at all then? Because there are special types of articles that could look different! Article has an attribute, class, which can contain the following values: * NULL * faq * journalarticle * productsheet * specification * techreport * whitepaper Now these things may be worth styling differently, perhaps much differently, than a book. Maybe journalarticle should be dual column? Perhaps a whitepaper should have extra wide margins for people to scribble in? A special cover page for a productsheet perchance? Speak up now or forever hold your peace as I purge the layout differences between books and articles and you kiss goodbye to the chance of having funky layouts at your finger tips! Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From r.landmann at redhat.com Wed Dec 2 06:06:27 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Wed, 02 Dec 2009 16:06:27 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B15FDAC.9020007@redhat.com> References: <4B15FDAC.9020007@redhat.com> Message-ID: <4B1603E3.7020001@redhat.com> On 12/02/2009 03:39 PM, Jeffrey Fearn wrote: > Hi, I have been giving some thought to the issues around the > formatting of articles vs books, and thought I'd poll the list for input. > > The question of layout seems to depend on what the fundamental > difference between a book and an article is. The answer appears to be > not much. > From a writing point of view, the fundamental difference seems to be one of scope; an article is typically narrow in focus, and generally "shorter" than a book (yes, I know, "how long is a piece of string?") From a publishing point of view, I think the key difference is that an article is often not published by itself, but as part of a longer work like a magazine, journal, or book; which is where (for example), I think that the difference in how Publican formats books and articles in PDF is useful. Questions of layout aside, the default structure produced by Publican for books (including our lengthy "Document Conventions" section) I think overwhelms a short piece of writing, like a "How To", which is the kind of thing I've used
for up to now, for example: http://docs.fedoraproject.org/readme-live-image/en-US.html http://docs.fedoraproject.org/readme-burning-isos/en-US.html Of course, I know that the same effect can be generated by overriding the defaults (and you'll notice that in those two examples, I actually /added/ the Feedback section, which is not there by default in articles...) > If this is the case there is no need to have a layout that varies more > than required by the minimal structural differences between a book and > an article then. > > So, as a base, an article should look pretty much like a book ... but > why bother having articles at all then? > > Because there are special types of articles that could look different! > > Article has an attribute, class, which can contain the following values: > > * NULL > * faq > * journalarticle > * productsheet > * specification > * techreport > * whitepaper > > Now these things may be worth styling differently, perhaps much > differently, than a book. > I agree; this has useful possibilities, because, like you say, some of these (say, FAQ) might have practically no resemblance to a book at all... > Maybe journalarticle should be dual column? And maybe somehow inherit the "parentbook" attribute if it's being built as part of a and display this somewhere on the page? > > Perhaps a whitepaper should have extra wide margins for people to > scribble in? > > A special cover page for a productsheet perchance? Or be laid out in landscape, designed to be folded in half? I'm sure other people here have other ideas about what we could do with those specific formats... Cheers Rudi From pmorgan at redhat.com Wed Dec 2 14:18:22 2009 From: pmorgan at redhat.com (Paul Morgan) Date: Wed, 2 Dec 2009 09:18:22 -0500 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B1603E3.7020001@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> Message-ID: <20091202141822.GA3042@redhat.com> On Wed, Dec 02, 2009 at 04:06:27PM +1000, Ruediger Landmann wrote: > On 12/02/2009 03:39 PM, Jeffrey Fearn wrote: >> Hi, I have been giving some thought to the issues around the >> formatting of articles vs books, and thought I'd poll the list >> for input. >> >> The question of layout seems to depend on what the fundamental >> difference between a book and an article is. The answer appears >> to be not much. >> > > From a writing point of view, the fundamental difference seems to > be one of scope; an article is typically narrow in focus, and > generally "shorter" than a book (yes, I know, "how long is a piece > of string?") > > From a publishing point of view, I think the key difference is > that an article is often not published by itself, but as part of a > longer work like a magazine, journal, or book; which is where (for > example), I think that the difference in how Publican formats > books and articles in PDF is useful. > > Questions of layout aside, the default structure produced by > Publican for books (including our lengthy "Document Conventions" > section) I think overwhelms a short piece of writing, like a "How > To", which is the kind of thing I've used
for up to now, > for example: > > http://docs.fedoraproject.org/readme-live-image/en-US.html > > http://docs.fedoraproject.org/readme-burning-isos/en-US.html > > Of course, I know that the same effect can be generated by > overriding the defaults (and you'll notice that in those two > examples, I actually /added/ the Feedback section, which is not > there by default in articles...) > >> If this is the case there is no need to have a layout that >> varies more than required by the minimal structural differences >> between a book and an article then. >> >> So, as a base, an article should look pretty much like a book >> ... but why bother having articles at all then? >> >> Because there are special types of articles that could look different! >> >> Article has an attribute, class, which can contain the following values: >> >> * NULL >> * faq >> * journalarticle >> * productsheet >> * specification >> * techreport >> * whitepaper >> >> Now these things may be worth styling differently, perhaps much >> differently, than a book. >> > > I agree; this has useful possibilities, because, like you say, > some of these (say, FAQ) might have practically no resemblance to > a book at all... > >> Maybe journalarticle should be dual column? > > And maybe somehow inherit the "parentbook" attribute if it's being > built as part of a and display this somewhere on the page? this would be useful. >> Perhaps a whitepaper should have extra wide margins for people >> to scribble in? I'm not sure what the difference would be between whitepaper and techreport, but I could see a definite benefit to formatting one of the classes as a slide deck, optionally (based on Makefile parameter) with a notes section. For example, with notes the format would be portrait. Top half is slide, bottom half is notes. If Makefile "notes=0", the layout would be landscape and no notes section. -paul >> A special cover page for a productsheet perchance? > > Or be laid out in landscape, designed to be folded in half? > > I'm sure other people here have other ideas about what we could do > with those specific formats... > > Cheers > > Rudi -- Paul Morgan RHCE, RHCX, RHCDS, RHCSS, RHCA Voice: 317-jumanji (317-586-2654) GPG Public Key ID: 0xf59e77c2 Fingerprint = 3248 D0C8 4B42 2F7C D92A AEA0 7D20 6D66 F59E 77C2 From bugzilla at redhat.com Thu Dec 3 02:18:44 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Dec 2009 21:18:44 -0500 Subject: [publican-list] [Bug 540383] Publican seems to be pre-processing .xml files in extras/ In-Reply-To: References: Message-ID: <200912030218.nB32IhO5015496@bz-web2.app.phx.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=540383 Michael Hideo changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Documentation -- 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 Dec 3 02:19:00 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Dec 2009 21:19:00 -0500 Subject: [publican-list] [Bug 542524] http://documentation-stage.bne.redhat.com doesn't function as expected under IE7/IE8 In-Reply-To: References: Message-ID: <200912030219.nB32J0x6015561@bz-web2.app.phx.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=542524 Michael Hideo changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Documentation -- 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 Thu Dec 3 04:02:18 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Thu, 03 Dec 2009 14:02:18 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B1603E3.7020001@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> Message-ID: <4B17384A.3060409@redhat.com> Ruediger Landmann wrote: > On 12/02/2009 03:39 PM, Jeffrey Fearn wrote: >> Hi, I have been giving some thought to the issues around the >> formatting of articles vs books, and thought I'd poll the list for input. >> >> The question of layout seems to depend on what the fundamental >> difference between a book and an article is. The answer appears to be >> not much. >> > > From a writing point of view, the fundamental difference seems to be > one of scope; an article is typically narrow in focus, and generally > "shorter" than a book (yes, I know, "how long is a piece of string?") > > From a publishing point of view, I think the key difference is that an > article is often not published by itself, but as part of a longer work > like a magazine, journal, or book; which is where (for example), I think > that the difference in how Publican formats books and articles in PDF is > useful. The difference you are talking about is user controlled content and not formatting, there is almost no difference in the way the same content is formatted. > Questions of layout aside, the default structure produced by Publican > for books (including our lengthy "Document Conventions" section) I think > overwhelms a short piece of writing, like a "How To", which is the kind > of thing I've used
for up to now, for example: > > http://docs.fedoraproject.org/readme-live-image/en-US.html > > http://docs.fedoraproject.org/readme-burning-isos/en-US.html > > Of course, I know that the same effect can be generated by overriding > the defaults (and you'll notice that in those two examples, I actually > /added/ the Feedback section, which is not there by default in articles...) Try adding the rest of the common content to your article, or removing it from a book, and you will see their are only minor style changes, like a missing HR, or slightly different formatting on a title, etc. The change is so small there is no justification for having both these tags, after all the only change required to a book would be commenting out an xi:include or two. >> If this is the case there is no need to have a layout that varies more >> than required by the minimal structural differences between a book and >> an article then. >> >> So, as a base, an article should look pretty much like a book ... but >> why bother having articles at all then? >> >> Because there are special types of articles that could look different! >> >> Article has an attribute, class, which can contain the following values: >> >> * NULL >> * faq >> * journalarticle >> * productsheet >> * specification >> * techreport >> * whitepaper >> >> Now these things may be worth styling differently, perhaps much >> differently, than a book. >> > > I agree; this has useful possibilities, because, like you say, some of > these (say, FAQ) might have practically no resemblance to a book at all... > >> Maybe journalarticle should be dual column? > > And maybe somehow inherit the "parentbook" attribute if it's being built > as part of a and display this somewhere on the page? You need to build the garden before you plant the flowers! >> >> Perhaps a whitepaper should have extra wide margins for people to >> scribble in? >> >> A special cover page for a productsheet perchance? > > Or be laid out in landscape, designed to be folded in half? > > I'm sure other people here have other ideas about what we could do with > those specific formats... But will they actually post about them or wait until we make decisions and then bitch endlessly that they didn't get to have any input? Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Thu Dec 3 04:29:10 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Thu, 03 Dec 2009 14:29:10 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <20091202141822.GA3042@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <20091202141822.GA3042@redhat.com> Message-ID: <4B173E96.9000901@redhat.com> Paul Morgan wrote: > On Wed, Dec 02, 2009 at 04:06:27PM +1000, Ruediger Landmann wrote: >>> Article has an attribute, class, which can contain the following values: >>> >>> * NULL >>> * faq >>> * journalarticle >>> * productsheet >>> * specification >>> * techreport >>> * whitepaper >>> >>> Now these things may be worth styling differently, perhaps much >>> differently, than a book. >>> >> I agree; this has useful possibilities, because, like you say, >> some of these (say, FAQ) might have practically no resemblance to >> a book at all... >> >>> Maybe journalarticle should be dual column? >> And maybe somehow inherit the "parentbook" attribute if it's being >> built as part of a and display this somewhere on the page? > > this would be useful. > > >>> Perhaps a whitepaper should have extra wide margins for people >>> to scribble in? > > I'm not sure what the difference would be between whitepaper > and techreport, but I could see a definite benefit to formatting > one of the classes as a slide deck, optionally (based on Makefile > parameter) with a notes section. > > For example, with notes the format would be portrait. Top half is > slide, bottom half is notes. If Makefile "notes=0", the layout would > be landscape and no notes section. There is a dedicated DTD for this http://wiki.docbook.org/topic/SlidesDoctype I've not used it myself, but it's probably a better fit than trying to shoe horn it in to the article stuff. Then again I'm a compulsive shoe horner, as it were, so it wouldn't be out of character :D Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From r.landmann at redhat.com Thu Dec 3 05:07:27 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Thu, 03 Dec 2009 15:07:27 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B17384A.3060409@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> Message-ID: <4B17478F.5080300@redhat.com> On 12/03/2009 02:02 PM, Jeffrey Fearn wrote: > The difference you are talking about is user controlled content and > not formatting, there is almost no difference in the way the same > content is formatted. > True. What I'd personally like to see in articles is even more minimal front matter. Taking http://docs.fedoraproject.org/readme-live-image/en-US.html as an example, I'd prefer to see: * the Product Name and Article Name combined into one line and reduced in size * the logo gone or reduced in size * author names, affiliations, and email addresses collapsed into one line * Table of Contents turned off (or at least turned off by default) * Legal notice reduced in size and moved to the end of the article (or maybe a footer) * Revision history reduced in size and perhaps limited to only the last revision? I think that this would better present a short piece (without the formatting overwhelming such a short piece of writing) and that the resulting doc would more easily lend itself to inclusion in a longer work. Maybe I should mock this up to better illustrate what I have in mind? Cheers Rudi From jfearn at redhat.com Thu Dec 3 05:24:08 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Thu, 03 Dec 2009 15:24:08 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B17478F.5080300@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> <4B17478F.5080300@redhat.com> Message-ID: <4B174B78.5040809@redhat.com> Ruediger Landmann wrote: > On 12/03/2009 02:02 PM, Jeffrey Fearn wrote: >> The difference you are talking about is user controlled content and >> not formatting, there is almost no difference in the way the same >> content is formatted. >> > > True. What I'd personally like to see in articles is even more minimal > front matter. Taking > > http://docs.fedoraproject.org/readme-live-image/en-US.html > > as an example, I'd prefer to see: > > * the Product Name and Article Name combined into one line and reduced > in size Or just the Article Name. > * the logo gone or reduced in size Remove it from, or comment it out in, Article_Info.xml > * author names, affiliations, and email addresses collapsed into one line Or just the name, which is an email link. > * Table of Contents turned off (or at least turned off by default) +1 > * Legal notice reduced in size and moved to the end of the article (or > maybe a footer) Engaging legal discussion avoidance engine! ;) > * Revision history reduced in size and perhaps limited to only the last > revision? I'd just leave it out, it's required for building the RPM, but you can just leave out the xi:include. > I think that this would better present a short piece (without the > formatting overwhelming such a short piece of writing) and that the > resulting doc would more easily lend itself to inclusion in a longer work. There is no reason you can't format an article in a book differently than the same article when it's stand alone. > Maybe I should mock this up to better illustrate what I have in mind? Mock ups are always good :) Don't forget Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From r.landmann at redhat.com Thu Dec 3 07:11:39 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Thu, 03 Dec 2009 17:11:39 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B174B78.5040809@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> <4B17478F.5080300@redhat.com> <4B174B78.5040809@redhat.com> Message-ID: <4B1764AB.80003@redhat.com> On 12/03/2009 03:24 PM, Jeffrey Fearn wrote: > > Mock ups are always good :) > So here's my idea of what an article might look like with minimalist formatting: http://rlandmann.fedorapeople.org/artdemo/ I did toy with the idea of making the names clickable email addresses, but thought again about how this might look when printed on dead trees, and kept the names separate. Too stark? From Daniel.W.Ottey at questdiagnostics.com Thu Dec 3 17:34:56 2009 From: Daniel.W.Ottey at questdiagnostics.com (Ottey, Daniel W) Date: Thu, 3 Dec 2009 12:34:56 -0500 Subject: [publican-list] Spacing on programlisting Message-ID: Hi all, The Linux Systems group here at Quest Diagnostics has been using Publican extensively in the last few months as we migrate our Linux Server Disaster Recovery documentation from Microsoft Word to Publican (output as PDF). We have received amazing feedback on how professional our documentation now looks compared to many of the Word documents that have been reviewed. So I am sending my thanks to the authors and contributors of Publican - this is an excellent open source project! We have just converted our document to Publican 1.2 version since its release in Fedora 12. We are eager to introduce the syntax highlighting for many of our command line bash examples using programlisting. The issue we are seeing is that , unlike , has a 1 or 2 line buffer/spacing at both the top and bottom of the listing. For larger code examples this is not a big deal, but it is very obvious when the code sample only has one line. Please see the attached PDF. The test chapter contains two programlistings and one screen. I have attached the chapter's XML file as well. I'd like to know if there is an option to disable that spacing? If not, can it be made an option? And is there any way to "get around it" in the mean time? Thanks so much for any assistance! PS. I do hope this is the correct forum for such questions. If it is, I may have a few others down the line. Daniel W. Ottey Quest Diagnostics | Linux Admin | Linux & Web Services | 400 Egypt Road | West Norriton, PA 19403 USA | phone +1.610.650.6681 | fax +1.610.650.2171 | Daniel.W.Ottey at QuestDiagnostics.com | www.QuestDiagnostics.com ------------------------------------------ The contents of this message, together with any attachments, are intended only for the use of the person(s) to which they are addressed and may contain confidential and/or privileged information. Further, any medical information herein is confidential and protected by law. It is unlawful for unauthorized persons to use, review, copy, disclose, or disseminate confidential medical information. If you are not the intended recipient, immediately advise the sender and delete this message and any attachments. Any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: test.pdf Type: application/pdf Size: 42374 bytes Desc: test.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.xml Type: text/xml Size: 739 bytes Desc: test.xml URL: From jfearn at redhat.com Thu Dec 3 22:11:08 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 04 Dec 2009 08:11:08 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B1764AB.80003@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> <4B17478F.5080300@redhat.com> <4B174B78.5040809@redhat.com> <4B1764AB.80003@redhat.com> Message-ID: <4B18377C.2090201@redhat.com> Ruediger Landmann wrote: > On 12/03/2009 03:24 PM, Jeffrey Fearn wrote: >> >> Mock ups are always good :) >> > > So here's my idea of what an article might look like with minimalist > formatting: > > http://rlandmann.fedorapeople.org/artdemo/ > > > I did toy with the idea of making the names clickable email addresses, > but thought again about how this might look when printed on dead trees, > and kept the names separate. A: We don't care what HTML looks like printed. If we did care we'd have a style sheet for it. B: The PDF already handles this with footnotes with the full URL in it. > Too stark? Not for me. I'd drop the revision history, shorten the legal notice, and move the copyright and legal link to the top. I'd also just use the license acronym as a link to the upstream text. e.g. Copyright ? 2009 Red Hat, Inc. and others. CC-BY-SA Where CC-BY-SA is a link to http://creativecommons.org/licenses/by-sa/3.0/ Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Thu Dec 3 23:27:51 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 04 Dec 2009 09:27:51 +1000 Subject: [publican-list] Spacing on programlisting In-Reply-To: References: Message-ID: <4B184977.2050607@redhat.com> Hi Daniel, welcome :) Ottey, Daniel W wrote: > Hi all, > > The Linux Systems group here at Quest Diagnostics has been using > Publican extensively in the last few months as we migrate our Linux > Server Disaster Recovery documentation from Microsoft Word to Publican > (output as PDF). We have received amazing feedback on how professional > our documentation now looks compared to many of the Word documents that > have been reviewed. So I am sending my thanks to the authors and > contributors of Publican - this is an excellent open source project! Thanks :) > We have just converted our document to Publican 1.2 version since its > release in Fedora 12. We are eager to introduce the syntax highlighting > for many of our command line bash examples using programlisting. The > issue we are seeing is that , unlike , has a 1 > or 2 line buffer/spacing at both the top and bottom of the listing. For > larger code examples this is not a big deal, but it is very obvious when > the code sample only has one line. Please see the attached PDF. The > test chapter contains two programlistings and one screen. I have > attached the chapter's XML file as well. > > I'd like to know if there is an option to disable that spacing? If not, > can it be made an option? This is a bug, the only change that should ever be made to verbatim content is line wrapping long lines. Please open a bug and I'll try and get a fix in to 1.3. > And is there any way to "get around it" in > the mean time? The extra space is being added by the syntax highlighting code, so the workaround is to remove the language attribute :( > Thanks so much for any assistance! > > PS. I do hope this is the correct forum for such questions. If it is, > I may have a few others down the line. This is definitely the right place :) Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From r.landmann at redhat.com Thu Dec 3 23:36:33 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Fri, 04 Dec 2009 09:36:33 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B18377C.2090201@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> <4B17478F.5080300@redhat.com> <4B174B78.5040809@redhat.com> <4B1764AB.80003@redhat.com> <4B18377C.2090201@redhat.com> Message-ID: <4B184B81.4080904@redhat.com> On 12/04/2009 08:11 AM, Jeffrey Fearn wrote: > I'd drop the revision history, shorten the legal notice, and move the > copyright and legal link to the top. I'd also just use the license > acronym as a link to the upstream text. > > e.g. > > Copyright ? 2009 Red Hat, Inc. and others. CC-BY-SA > > > Where CC-BY-SA is a link to > http://creativecommons.org/licenses/by-sa/3.0/ OK -- I've streamlined the author and copyright/licensing information even further, per your suggestions. However, I did still keep a last (further reduced) vestige of the Revision History at the foot of the document; I think that for technical writing, it's important to identify this revision somehow so that when an article ends up republished in a number of places, people can readily identify which version is the more recent. Actually -- discussions of article formatting aside, I think that including the version number in the header could be a useful addition to Publican's HTML output... but that's probably another post :) Also -- would it be possible to allow the abstract to be switched on and off? An abstract is a normal feature in a tech report or journal article, but not so well suited to a how-to (like this example) or, say, a product sheet. Cheers Rudi From r.landmann at redhat.com Thu Dec 3 23:48:23 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Fri, 04 Dec 2009 09:48:23 +1000 Subject: [publican-list] Spacing on programlisting In-Reply-To: References: Message-ID: <4B184E47.6050304@redhat.com> On 12/04/2009 03:34 AM, Ottey, Daniel W wrote: > I'd like to know if there is an option to disable that spacing? If not, > can it be made an option? And is there any way to "get around it" in > the mean time? > I can only help with the last part of this question: since these are commands that the user enters, I wouldn't use here at all. My suggestion: Step 1 Step 2 mkdir /foo Edit /etc/fstab and add the new logical volume. /dev/vg_bar/lv_foo /foo ext3 acl,user_xattr,noatime 1 2 Reboot the system. rebootThe system is ready for turnover. > PS. I do hope this is the correct forum for such questions. > Absolutely! Welcome aboard :) Cheers Rudi From jfearn at redhat.com Fri Dec 4 01:10:00 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 04 Dec 2009 11:10:00 +1000 Subject: [publican-list] Spacing on programlisting In-Reply-To: <4B184E47.6050304@redhat.com> References: <4B184E47.6050304@redhat.com> Message-ID: <4B186168.6060409@redhat.com> Ruediger Landmann wrote: > On 12/04/2009 03:34 AM, Ottey, Daniel W wrote: >> I'd like to know if there is an option to disable that spacing? If not, >> can it be made an option? And is there any way to "get around it" in >> the mean time? >> > > I can only help with the last part of this question: since these are > commands that the user enters, I wouldn't use here at > all. My suggestion: > > > Step 1 > Step 2 > mkdir /foo > Edit /etc/fstab and add the new logical > volume. > /dev/vg_bar/lv_foo /foo ext3 acl,user_xattr,noatime 1 > 2 > Reboot the system. > rebootThe system is ready for > turnover. > IMHO The evil here is mixed mode content, BOOOOOO! I filed a bug for this as I wanted to get the fix in 1.3 https://bugzilla.redhat.com/show_bug.cgi?id=544141 Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From jfearn at redhat.com Fri Dec 4 02:06:22 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Fri, 04 Dec 2009 12:06:22 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B184B81.4080904@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> <4B17478F.5080300@redhat.com> <4B174B78.5040809@redhat.com> <4B1764AB.80003@redhat.com> <4B18377C.2090201@redhat.com> <4B184B81.4080904@redhat.com> Message-ID: <4B186E9E.5050108@redhat.com> Ruediger Landmann wrote: > On 12/04/2009 08:11 AM, Jeffrey Fearn wrote: >> I'd drop the revision history, shorten the legal notice, and move the >> copyright and legal link to the top. I'd also just use the license >> acronym as a link to the upstream text. >> >> e.g. >> >> Copyright ? 2009 Red Hat, Inc. and others. CC-BY-SA >> >> >> Where CC-BY-SA is a link to >> http://creativecommons.org/licenses/by-sa/3.0/ > > OK -- I've streamlined the author and copyright/licensing information > even further, per your suggestions. > > However, I did still keep a last (further reduced) vestige of the > Revision History at the foot of the document; I think that for technical > writing, it's important to identify this revision somehow so that when > an article ends up republished in a number of places, people can readily > identify which version is the more recent. Actually -- discussions of > article formatting aside, I think that including the version number in > the header could be a useful addition to Publican's HTML output... but > that's probably another post :) > > Also -- would it be possible to allow the abstract to be switched on and > off? An abstract is a normal feature in a tech report or journal > article, but not so well suited to a how-to (like this example) or, say, > a product sheet. This is what the class attribute is for ... I thought we were talking about what the default article should look like? Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Tue Dec 8 02:14:51 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:14:51 -0500 Subject: [publican-list] [Bug 537970] publican does not brew on CSB In-Reply-To: References: Message-ID: <200912080214.nB82EpRi021989@bz-web1.app.phx.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=537970 --- Comment #2 from Fedora Update System 2009-12-07 21:14:50 EDT --- publican-1.3-0.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/publican-1.3-0.fc12 -- 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 Dec 8 02:14:20 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:14:20 -0500 Subject: [publican-list] [Bug 511404] RFE: support stepalternatives In-Reply-To: References: Message-ID: <200912080214.nB82EKoL021709@bz-web1.app.phx.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=511404 --- Comment #8 from Fedora Update System 2009-12-07 21:14:19 EDT --- publican-1.3-0.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/publican-1.3-0.fc12 -- 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 Dec 8 02:14:35 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:14:35 -0500 Subject: [publican-list] [Bug 533322] When creating a new book with Publican it cannot be built In-Reply-To: References: Message-ID: <200912080214.nB82EZ7B031381@bz-web2.app.phx.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=533322 --- Comment #3 from Fedora Update System 2009-12-07 21:14:35 EDT --- publican-1.3-0.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/publican-1.3-0.fc12 -- 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 Dec 8 02:18:12 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:18:12 -0500 Subject: [publican-list] [Bug 537970] publican does not brew on CSB In-Reply-To: References: Message-ID: <200912080218.nB82ICon023263@bz-web1.app.phx.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=537970 --- Comment #3 from Fedora Update System 2009-12-07 21:18:11 EDT --- publican-1.3-0.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/publican-1.3-0.fc11 -- 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 Dec 8 02:17:44 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:17:44 -0500 Subject: [publican-list] [Bug 511404] RFE: support stepalternatives In-Reply-To: References: Message-ID: <200912080217.nB82Hi9Q023028@bz-web1.app.phx.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=511404 --- Comment #9 from Fedora Update System 2009-12-07 21:17:43 EDT --- publican-1.3-0.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/publican-1.3-0.fc11 -- 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 Dec 8 02:17:58 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:17:58 -0500 Subject: [publican-list] [Bug 533322] When creating a new book with Publican it cannot be built In-Reply-To: References: Message-ID: <200912080217.nB82HwIj023139@bz-web1.app.phx.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=533322 --- Comment #4 from Fedora Update System 2009-12-07 21:17:57 EDT --- publican-1.3-0.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/publican-1.3-0.fc11 -- 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 Dec 8 02:15:01 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:15:01 -0500 Subject: [publican-list] [Bug 540383] Publican seems to be pre-processing .xml files in extras/ In-Reply-To: References: Message-ID: <200912080215.nB82F165022161@bz-web1.app.phx.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=540383 --- Comment #2 from Fedora Update System 2009-12-07 21:15:00 EDT --- publican-1.3-0.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/publican-1.3-0.fc12 -- 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 Dec 8 02:18:21 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 Dec 2009 21:18:21 -0500 Subject: [publican-list] [Bug 540383] Publican seems to be pre-processing .xml files in extras/ In-Reply-To: References: Message-ID: <200912080218.nB82ILPX032632@bz-web2.app.phx.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=540383 --- Comment #3 from Fedora Update System 2009-12-07 21:18:20 EDT --- publican-1.3-0.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/publican-1.3-0.fc11 -- 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 Tue Dec 8 04:59:23 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Tue, 08 Dec 2009 14:59:23 +1000 Subject: [publican-list] Publican 1.3 is away! In-Reply-To: <4B15EDA3.4010706@redhat.com> References: <4B0E1037.7080500@redhat.com> <4B15EDA3.4010706@redhat.com> Message-ID: <4B1DDD2B.2000809@redhat.com> Hey all -- Publican 1.3 is now packaged up and in the updates queue for Fedora -- F-11, F-12, and Rawhide users should see it arrive on your desktops shortly. For anyone packaging Publican for other operating systems, you can find the tarball here as usual: https://fedorahosted.org/releases/p/u/publican/ The Windows installer for 1.3 should be available from the same location shortly too :) Cheers Rudi From bugzilla at redhat.com Tue Dec 8 08:09:01 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 Dec 2009 03:09:01 -0500 Subject: [publican-list] [Bug 545334] New: You can't represent XML entities in a document Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: You can't represent XML entities in a document https://bugzilla.redhat.com/show_bug.cgi?id=545334 Summary: You can't represent XML entities in a document Product: Red Hat Enterprise Linux 5 Version: 5.2 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: publican AssignedTo: mhideo at redhat.com ReportedBy: dmison at redhat.com QAContact: jwulf at redhat.com CC: publican-list at redhat.com Classification: Red Hat Target Release: --- Description of problem: You can't represent XML entities in a document. It would appear that the entities are being expanded more than once Version-Release number of selected component (if applicable): publican-ovirt-1.0-0.el5 publican-gimp-1.0-0.el5 publican-redhat-1.1-0.el5 publican-1.3-0.el5 publican-redhat-internal-1.0-1.el5 publican-jboss-1.1-0.el5 perl-Publican-WebSite-1.2-1.el5 publican-WebSite-obsoletes-1.14-1.el5 publican-fedora-1.0-0.el5 publican-doc-1.3-0.el5 How reproducible: Steps to Reproduce: 1.add to book The entity to use is: &allproperties; 2.build Actual results: Release_Notes.xml:32: parser error : Entity 'allproperties' not defined &allproperties; ^ Expected results: book contains the text: The entity to use is: &allproperties; Additional info: -- 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 Dec 8 22:34:21 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 Dec 2009 17:34:21 -0500 Subject: [publican-list] [Bug 545334] You can't represent XML entities in a document In-Reply-To: References: Message-ID: <200912082234.nB8MYLb2001942@bz-web1.app.phx.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=545334 --- Comment #1 from Jeff Fearn 2009-12-08 17:34:20 EDT --- The problem here is that the wrong error message is being generated. When you feed Publican invalid XML that matches the above format the entity parsing code chokes on it before the XML validation can flag it as invalid. This is because the entities are expanded prior to validation to ensure the full tree is being validated. I'm looking in to how to get the correct error message to be generated. The workaround is to use valid XML. e.g &allproperties; -- 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 Tue Dec 8 22:45:46 2009 From: r.landmann at redhat.com (Ruediger Landmann) Date: Wed, 09 Dec 2009 08:45:46 +1000 Subject: [publican-list] Formatting Articles, a discussion of BZ #494147 In-Reply-To: <4B186E9E.5050108@redhat.com> References: <4B15FDAC.9020007@redhat.com> <4B1603E3.7020001@redhat.com> <4B17384A.3060409@redhat.com> <4B17478F.5080300@redhat.com> <4B174B78.5040809@redhat.com> <4B1764AB.80003@redhat.com> <4B18377C.2090201@redhat.com> <4B184B81.4080904@redhat.com> <4B186E9E.5050108@redhat.com> Message-ID: <4B1ED71A.4000609@redhat.com> Sorry -- I must have missed this reply last week. On 12/04/2009 12:06 PM, Jeffrey Fearn wrote: > Ruediger Landmann wrote: >> Also -- would it be possible to allow the abstract to be switched on >> and off? An abstract is a normal feature in a tech report or journal >> article, but not so well suited to a how-to (like this example) or, >> say, a product sheet. > > This is what the class attribute is for ... I thought we were talking > about what the default article should look like? Indeed we are, and so the answer seems to be that yes, we could leave it to the class to determine the presence or absence of the Abstract (depending on what was set as the default). In which case, I'd suggest leaving the abstract visible in the default article, leaving it to be turned off in various classes where it's not appropriate. What do you (and anybody else) think of http://rlandmann.fedorapeople.org/artdemo/ as a default article now? Cheers Rudi From bugzilla at redhat.com Wed Dec 9 05:59:04 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 00:59:04 -0500 Subject: [publican-list] [Bug 545698] New: Publican creates unnecessary POT files Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Publican creates unnecessary POT files https://bugzilla.redhat.com/show_bug.cgi?id=545698 Summary: Publican creates unnecessary POT files Product: Red Hat Enterprise Linux 5 Version: 5.4 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: publican AssignedTo: mhideo at redhat.com ReportedBy: mospina at redhat.com QAContact: jwulf at redhat.com CC: publican-list at redhat.com Classification: Red Hat Target Release: --- Description of problem: When creating POT/PO files, publican takes all the XML files from en-US/ directory, even those that are not included in the book/article. Those files that are not included in the book (drafts, excluded chapters, etc.) should not produce POT files as they don't need translation. Version-Release number of selected component (if applicable): 1.3 How reproducible: Always Steps to Reproduce: 1. Create a draft XML file in en-US 2. publican update_pot 3. Actual results: A POT file of the draft XML file is created in the pot directory Expected results: The draft XML file should be ignored when creating the POT files as it doesn't need translation. Only POT files of those XML files included in a book should be created. Additional info: -- 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 Dec 9 06:23:02 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 01:23:02 -0500 Subject: [publican-list] [Bug 545698] Publican creates unnecessary POT files In-Reply-To: References: Message-ID: <200912090623.nB96N2ln018346@bz-web1.app.phx.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=545698 --- Comment #1 from Jeff Fearn 2009-12-09 01:23:01 EDT --- IMHO this highlights a flaw in the translation work flow and isn't a bug in publican. You should only be translating files marked for translation. Files that _are_ included in the book may not be ready for translation yet, so relying on whether or not they are currently included in the book is, at best, unreliable. Furthermore since writers are responsible, or would be in any sane system, for checking in POT files that are ready for translation, they should not be checking in POT files they don't want translated. Cheers, Jeff. -- 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 josh.kayse at gtri.gatech.edu Wed Dec 9 16:39:34 2009 From: josh.kayse at gtri.gatech.edu (Josh Kayse) Date: Wed, 9 Dec 2009 11:39:34 -0500 Subject: [publican-list] Custom Header/Footer In-Reply-To: <20091123210335.GA2868@redhat.com> References: <4B0AF5FC.4010408@gtri.gatech.edu> <20091123210335.GA2868@redhat.com> Message-ID: <4B1FD2C6.6030909@gtri.gatech.edu> On 11/23/2009 04:03 PM, Paul Morgan wrote: > On Mon, Nov 23, 2009 at 03:52:12PM -0500, Josh Kayse wrote: > >> I'm attempting to switch our documentation to publican at my workplace >> and was wondering if publican supports custom headers/footers on each >> page for PDF output or top and bottom of HTML output. Could I use the >> override.css for the HTML output? We want to include something like "Our >> Company" at the top and bottom of each page. >> > Here's a stylesheet I hacked together that has running footers and > headers. The stylesheet belongs in a "brand" directory, such as > /usr/share/publican/xsl/mybrand/pdf.xsl > > hth, > -paul > > > Thanks! That works great. The only problem I'm running in to now is I cannot seem to get the header/footer to show up on the first page. Here's my current version of the pdf.xsl Thanks! -josh ]> NOT CLASSIFIED Page Page -- A: No. Q: Should I include quotations after my reply? Don't top post: see http://www.caliburn.nl/topposting.html for more. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2687 bytes Desc: S/MIME Cryptographic Signature URL: From jfearn at redhat.com Thu Dec 10 04:07:32 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Thu, 10 Dec 2009 14:07:32 +1000 Subject: [publican-list] Custom Header/Footer In-Reply-To: <4B1FD2C6.6030909@gtri.gatech.edu> References: <4B0AF5FC.4010408@gtri.gatech.edu> <20091123210335.GA2868@redhat.com> <4B1FD2C6.6030909@gtri.gatech.edu> Message-ID: <4B207404.9070103@redhat.com> Josh Kayse wrote: > On 11/23/2009 04:03 PM, Paul Morgan wrote: >> On Mon, Nov 23, 2009 at 03:52:12PM -0500, Josh Kayse wrote: >> >>> I'm attempting to switch our documentation to publican at my workplace >>> and was wondering if publican supports custom headers/footers on each >>> page for PDF output or top and bottom of HTML output. Could I use the >>> override.css for the HTML output? We want to include something like >>> "Our >>> Company" at the top and bottom of each page. >>> >> Here's a stylesheet I hacked together that has running footers and >> headers. The stylesheet belongs in a "brand" directory, such as >> /usr/share/publican/xsl/mybrand/pdf.xsl >> >> hth, >> -paul >> >> >> > > > Thanks! That works great. The only problem I'm running in to now is I > cannot seem to get the header/footer to show up on the first page. > Here's my current version of the pdf.xsl You probably need to override the preface.titlepage.recto template to get headers and footers on the cover page. Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From bugzilla at redhat.com Thu Dec 10 04:13:20 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:13:20 -0500 Subject: [publican-list] [Bug 511404] RFE: support stepalternatives In-Reply-To: References: Message-ID: <200912100413.nBA4DKLH026916@bz-web1.app.phx.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=511404 --- Comment #10 from Fedora Update System 2009-12-09 23:13:18 EDT --- publican-1.3-0.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:13:35 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:13:35 -0500 Subject: [publican-list] [Bug 533322] When creating a new book with Publican it cannot be built In-Reply-To: References: Message-ID: <200912100413.nBA4DZ5u026985@bz-web1.app.phx.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=533322 --- Comment #5 from Fedora Update System 2009-12-09 23:13:34 EDT --- publican-1.3-0.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:13:49 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:13:49 -0500 Subject: [publican-list] [Bug 537970] publican does not brew on CSB In-Reply-To: References: Message-ID: <200912100413.nBA4DnBW009325@bz-web2.app.phx.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=537970 --- Comment #4 from Fedora Update System 2009-12-09 23:13:48 EDT --- publican-1.3-0.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:13:58 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:13:58 -0500 Subject: [publican-list] [Bug 540383] Publican seems to be pre-processing .xml files in extras/ In-Reply-To: References: Message-ID: <200912100413.nBA4Dw4T009365@bz-web2.app.phx.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=540383 --- Comment #4 from Fedora Update System 2009-12-09 23:13:58 EDT --- publican-1.3-0.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:26:40 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:26:40 -0500 Subject: [publican-list] [Bug 537970] publican does not brew on CSB In-Reply-To: References: Message-ID: <200912100426.nBA4QenN015498@bz-web2.app.phx.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=537970 --- Comment #5 from Fedora Update System 2009-12-09 23:26:40 EDT --- publican-1.3-0.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:26:11 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:26:11 -0500 Subject: [publican-list] [Bug 511404] RFE: support stepalternatives In-Reply-To: References: Message-ID: <200912100426.nBA4QBfA015260@bz-web2.app.phx.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=511404 --- Comment #11 from Fedora Update System 2009-12-09 23:26:11 EDT --- publican-1.3-0.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:26:50 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:26:50 -0500 Subject: [publican-list] [Bug 540383] Publican seems to be pre-processing .xml files in extras/ In-Reply-To: References: Message-ID: <200912100426.nBA4QoNs015572@bz-web2.app.phx.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=540383 --- Comment #5 from Fedora Update System 2009-12-09 23:26:49 EDT --- publican-1.3-0.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 04:26:26 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Dec 2009 23:26:26 -0500 Subject: [publican-list] [Bug 533322] When creating a new book with Publican it cannot be built In-Reply-To: References: Message-ID: <200912100426.nBA4QQWX032730@bz-web1.app.phx.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=533322 --- Comment #6 from Fedora Update System 2009-12-09 23:26:25 EDT --- publican-1.3-0.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. -- 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 Dec 10 05:12:59 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Dec 2009 00:12:59 -0500 Subject: [publican-list] [Bug 511404] RFE: support stepalternatives In-Reply-To: References: Message-ID: <200912100512.nBA5CxYf011844@bz-web1.app.phx.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=511404 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |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 Thu Dec 10 05:13:25 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Dec 2009 00:13:25 -0500 Subject: [publican-list] [Bug 540383] Publican seems to be pre-processing .xml files in extras/ In-Reply-To: References: Message-ID: <200912100513.nBA5DPRE011931@bz-web1.app.phx.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=540383 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |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 Thu Dec 10 05:13:16 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Dec 2009 00:13:16 -0500 Subject: [publican-list] [Bug 537970] publican does not brew on CSB In-Reply-To: References: Message-ID: <200912100513.nBA5DGBG027421@bz-web2.app.phx.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=537970 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |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 Thu Dec 10 05:13:08 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Dec 2009 00:13:08 -0500 Subject: [publican-list] [Bug 533322] When creating a new book with Publican it cannot be built In-Reply-To: References: Message-ID: <200912100513.nBA5D8Fw027391@bz-web2.app.phx.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=533322 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ON_DEV |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 Fri Dec 11 01:33:51 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Dec 2009 20:33:51 -0500 Subject: [publican-list] [Bug 545334] You can't represent XML entities in a document In-Reply-To: References: Message-ID: <200912110133.nBB1XpXk021421@bz-web2.app.phx.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=545334 Jeff Fearn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dlackey at redhat.com --- Comment #2 from Jeff Fearn 2009-12-10 20:33:49 EDT --- *** Bug 546488 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 Fri Dec 11 01:41:54 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 10 Dec 2009 20:41:54 -0500 Subject: [publican-list] [Bug 545334] You can't represent XML entities in a document In-Reply-To: References: Message-ID: <200912110141.nBB1fs3j009984@bz-web1.app.phx.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=545334 --- Comment #3 from Darrin Mison 2009-12-10 20:41:54 EDT --- ah ; .. face->palm 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 gginiu at gmail.com Sat Dec 12 14:38:29 2009 From: gginiu at gmail.com (Andrzej Giniewicz) Date: Sat, 12 Dec 2009 15:38:29 +0100 Subject: [publican-list] Cannot build publican 1.3, "mismatched tag"? Message-ID: Hello, I remember hearing about Publican back on Libre Graphics Meeting in 2008, it was still in very early stage back then, but I tried it. I was able to build it back then, but it wasn't ready in my opinion so I decided to wait some time. Now I wanted to give 1.3 another shot, but wasn't able to build it. After solving lots of perl dependencies, perl Build.PL seemed to end well, but I'm getting errors, i.e. one tag is missing - close of ulink in some documents that are built as part of build process. Any ideas what I might be missing? Thanks in advance, Andrzej. PS.: I would open ticket for it, but there is only place to open tickets related to Fedora or Red Hat, what is right place to open general (not related to any particular distribution) issues/troubles/bugs/etc? Or maybe will this mailing list do? I'm pasting build results below: [giniu at raven3 Publican-1.3]$ perl Build.PL Creating custom builder _build/lib/My/Builder.pm in _build/lib/My Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Creating new 'Build' script for 'Publican' version '1.3' [giniu at raven3 Publican-1.3]$ ./Build Copying lib/Publican/TreeView.pm -> blib/lib/Publican/TreeView.pm Copying lib/Publican/CreateBook.pm -> blib/lib/Publican/CreateBook.pm Copying lib/Publican.pm -> blib/lib/Publican.pm Copying lib/Publican/XmlClean.pm -> blib/lib/Publican/XmlClean.pm Copying lib/Publican/Translate.pm -> blib/lib/Publican/Translate.pm Copying lib/Publican/CreateBrand.pm -> blib/lib/Publican/CreateBrand.pm Copying lib/Publican/Localise.pm -> blib/lib/Publican/Localise.pm Copying lib/Publican/Builder.pm -> blib/lib/Publican/Builder.pm Copying bin/publican -> blib/script/publican Setting up ar-SA PO file 'ar-SA/Legal_Notice.po' not found! Using base XML! Processing file tmp/ar-SA/xml_tmp/Conventions.xml mismatched tag at line 11, column 3, byte 800: In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default. ==^
at /usr/lib/perl5/vendor_perl/XML/Parser.pm line 187 From jfearn at redhat.com Mon Dec 14 02:33:48 2009 From: jfearn at redhat.com (Jeffrey Fearn) Date: Mon, 14 Dec 2009 12:33:48 +1000 Subject: [publican-list] Cannot build publican 1.3, "mismatched tag"? In-Reply-To: References: Message-ID: <4B25A40C.6090808@redhat.com> Hi Andrzej :) Andrzej Giniewicz wrote: > Hello, > > I remember hearing about Publican back on Libre Graphics Meeting in > 2008, it was still in very early stage back then, but I tried it. I > was able to build it back then, but it wasn't ready in my opinion so I > decided to wait some time. Now I wanted to give 1.3 another shot, but > wasn't able to build it. After solving lots of perl dependencies, perl > Build.PL seemed to end well, but I'm getting errors, i.e. one tag is > missing - close of ulink in some documents that are built as part of > build process. Any ideas what I might be missing? This is a bug in HTML::TreeBuilder, we carry a patch for this in Fedora. Upstream bug with patch at http://rt.cpan.org/Public/Bug/Display.html?id=49932 There is a patch for XML::TreeBuilder that is also required, again carried in Fedora and opened upstream with patch at http://rt.cpan.org/Public/Bug/Display.html?id=50060 Make sure you grab the later patch since the original had a bug :( > Thanks in advance, > Andrzej. > > PS.: I would open ticket for it, but there is only place to open > tickets related to Fedora or Red Hat, what is right place to open > general (not related to any particular distribution) > issues/troubles/bugs/etc? Or maybe will this mailing list do? We are currently using the fedora BZ as our development issue tracker, there is an on again, off again, discussion about changing that ... but trac really does suck and it's all Fedora hosted offers ATM :( Cheers, Jeff. -- Jeff Fearn Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY From gginiu at gmail.com Mon Dec 14 09:25:01 2009 From: gginiu at gmail.com (Andrzej Giniewicz) Date: Mon, 14 Dec 2009 10:25:01 +0100 Subject: [publican-list] Cannot build publican 1.3, "mismatched tag"? In-Reply-To: <4B25A40C.6090808@redhat.com> References: <4B25A40C.6090808@redhat.com> Message-ID: Hi, > This is a bug in HTML::TreeBuilder, we carry a patch for this in Fedora. > Upstream bug with patch at > http://rt.cpan.org/Public/Bug/Display.html?id=49932 > > There is a patch for XML::TreeBuilder that is also required, again carried > in Fedora and opened upstream with patch at > http://rt.cpan.org/Public/Bug/Display.html?id=50060 Make sure you grab the > later patch since the original had a bug :( Thanks, that was it - it works now. > We are currently using the fedora BZ as our development issue tracker, there > is an on again, off again, discussion about changing that ... but trac > really does suck and it's all Fedora hosted offers ATM :( then I think I prefer mailing list for now :) cheers, Andrzej.