Re: [docbook-apps] Docbook Editors
On Monday 14 May 2007 15:01:23 Eitan Zabari wrote: I would like to use an editor for writing Docbook, preferably WYSIWYG. I used to write Latex with GVIM (non-wysiwyg), but trying to do the same for Docbook XML is too much overhead, code wise. Which editors are used with Docbook? Can anyone please recommend? Are there free editors? Are there commercial editors that are good? Not free, but if you want a word replacement look at Syntext Serna. -- Sean Wheller Technical Author email: [EMAIL PROTECTED] im: [EMAIL PROTECTED] skype: seanwhe cel: +27-84-854-9408 web: http://www.inwords.co.za - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] translation of docbook documents
On Wednesday 04 April 2007 15:44, Hinrich Aue wrote: Does anyone have experience in translating docbook documents? Are there any tools out there to assist? What is the best approach? Hello Hinrich, The best solution at the best price (free) is the POT/PO (gnu getext) chain. It's used extensively on most Open Source projects. Leaders obviously the GNOME and KDE l18n projects and documentation projects. You can find more info on http://www.kde.org and http://www.gnome.org. Hope this helps, -- Sean Wheller Technical Author email: [EMAIL PROTECTED] im: [EMAIL PROTECTED] skype: seanwhe cel: +27-84-854-9408 web: http://www.inwords.co.za - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Better-looking DocBook XSL-FO stylesheets?
On Sunday 04 March 2007 21:10, Hendy Irawan wrote: It's been several years and the XSL-for-FO/PDF still very plain yet with fine functionality. I've been searching for better-looking XSL stylesheets (like those used by commercial publishers), but haven't found any. I wonder if there is already work on producing [open-source] customized stylesheets from the official DocBook XSL so that people will have more fun writing their books. :-) The stylesheets are fine. The fun is in making your own custom layers. -- Sean Wheller Technical Author email: [EMAIL PROTECTED] im: [EMAIL PROTECTED] skype: seanwhe cel: +27-84-854-9408 web: http://www.inwords.co.za - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DOCBOOK-APPS: Best Practices
-Original Message- From: Juan R. Migoya [mailto:[EMAIL PROTECTED] I have been forced (yes, sounds strange) to implement some solution(s) to allow people in the company write documents that could be easily (?) translated to XML. Well, due to the lack of time I had to make it run, and being unable in this short time to discover if I would be capable of customizing some programs like Frame Maker, I took the quick approach and choose Word, which is the text processor all in my company use. Although there is a long way before we reach the items you mentioned, I have concluded that the task can be done (even with Word). I would happily participate in any forum/work dedicated to this question, surely much more to learn than to contribute ;-) Juan, Thanks for the offer of support. Word is certainly a tool under consideration, especially since MS intends to include XML Support with the new Office. However, it is not the only solution and the tool chain extends beyond just the editing environment. Personally I don't mind which editor people use, so long as it is productive and conforms to open standards and hence has no lock in to proprietary formats. Unfortunately MS does not have a very good track record when it comes to standards compliance. I hope they will stay in compliance with W3C with the new Office. Certainly, many users can only use Word and are not technical enough to learn another tool. Using an existing tool like Word, in parts or the organization, will dramatically reduce implementation costs. Especially in the areas of licensing and training. More technical departments/users may use more specialized editors or even emacs + psgmls. Can you imagine asking the reception to use emacs? Perhaps you can lend us your requirements and reasoning for concluding that the task can be done (even with Word). This, together with other contributions can be a starting point for further discussion/debate within the community. Regards, Sean Wheller
DOCBOOK-APPS: Best Practices
Hello all, Is anyone maintaining a"Best Practices" to do with developing an XML Authoring system? To explain: For non-technicalpersons, or those short on time, who already realize the benefit ofXML Authoring,the implementation process can seem to be complex andlengthy. Often this would result in management concluding that while long-term benefit can be demonstrated, thecost and risk associated with implementation of an XML Authoring system is prohibitively costly and risky. That benefit will not beattainedfor the short to medium term. In an effort to reduce the barrier to entry I would like to develop a document called "Best Practices for Implementation of an XML Authoring". This document is a not a business case. Rather it is an addendum to the business case. The document assumes that a business case has been demonstrated and that the solution will include the use of DocBook XML DTD or Scheme. As a by product, the document may provide input or insight to enable more accurate assessment of the cost involved. The purpose of the document is to demonstrate a readily available,acceptable solution, cost optimized and implemental within a reasonable time frame of six months. The content should assist in fast tracking the implementation by providing "Best Practices"or a "Standard" by which to measure andselect systems/methods: Desktop Tool chain Revision Control Database Storage Translation System Porting Legacy to XML Training Authors Markup Guide Style Guide If I have left anything out, please let me know. Naturally I have been able to locate some of this information by reading across a number of Web Sites, but I cannot find a single resource that is made credible by way of community backing. Some Web Sites are maintained by people on doc-book-apps and generally I can consider them useful input. Others are not and generally have a marketing bias. While many articles concur with one another, they generally have conflicts in their suggestions, which inevitablyleads to debate and ultimately results in my having toperform a detailed competitive analysis across a number of tools. A task I dread as it takes me of the fast track. The question is: What are the "Best Practices" as seen by people that have extensive experience in the subject? Does such a guideline exist? Can we produce it as benchmark? If this is not being done, I am willing to contribute to coordinating and developing the document as a resource. However, in a document of suchnature it is important to have majority consensus within the community. I will therefore need the assistance of list members with input and resolution of just what is preferred "Best Practice". Please feel free to contact me if you feel you can provide the baseline for discussion one one or more of the points above. If you feel that I have neglected something please let me know. Alternately, if you feelthat this project should not be undertaken, please say so. Best, Sean Wheller [EMAIL PROTECTED] XWriter
DOCBOOK-APPS: Screenshots in procedures
Is there a way to place screenshots into a procedure without using figure as a wrapper? When I add figure I must add title in order to validate. But I don't want a title and I don't want the xsl to add the figure #. caption to the the screenshots in a procedure. What can I do? I have tried the following, but neither validate. procedure titleJava Installation Package/title step paraOpen a Shell and commandcd/command to the directory containing the Treebeard jar file./para /step step paraStart the install by typing commandjava -jar treebeard_V07_Java.jar/command. The first Treebeard Install dialog is displayed./para. /step screenshot mediaobject imageobject imagedata fileref=install1.jpg format=JPG scale=100/ /imageobject /mediaobject /screenshot ... and procedure titleJava Installation Package/title step paraOpen a Shell and commandcd/command to the directory containing the Treebeard jar file./para /step step paraStart the install by typing commandjava -jar treebeard_V07_Java.jar/command. The first Treebeard Install dialog is displayed./para screenshot mediaobject imageobject imagedata fileref=install1.jpg format=JPG scale=100/ /imageobject /mediaobject /screenshot /step -- Sean Wheller [EMAIL PROTECTED] XWriter
Re: DOCBOOK-APPS: Screenshots in procedures
On Sunday 16 February 2003 03:55 pm, Paul A. Hoadley wrote: Hi Sean, On Sun, Feb 16, 2003 at 03:43:36PM +1100, Sean Wheller wrote: procedure titleJava Installation Package/title step paraOpen a Shell and commandcd/command to the directory containing the Treebeard jar file./para /step step paraStart the install by typing commandjava -jar treebeard_V07_Java.jar/command. The first Treebeard Install dialog is displayed./para screenshot mediaobject imageobject imagedata fileref=install1.jpg format=JPG scale=100/ /imageobject /mediaobject /screenshot /step /procedure This should certainly validate. What tool is saying it does not, and what is the actual error message? Your other fragment was not valid. Hello Paul, I am using the Oxygen XML Editor (http://www.oxygenxml.com) it implements Xerces XML Parser. Having read your confirmation that the code above works, I went and made some strong coffee, came back and did a double check. Sure as nails I have a single period in the wrong place. The error message made was confusing as I was looking for error in the nesting of my elements. Fixed that and now it validates. Thanks, -- Sean Wheller [EMAIL PROTECTED] XWriter
RE: DOCBOOK-APPS: XMLSPY and DocBook
Also try oXygen (http://www.oxygenxml.com), this application is young, but has loads of potential. I have used it to create a number of manuals. -Original Message- From: Corey Arnold [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 7:49 AM To: [EMAIL PROTECTED] Subject: DOCBOOK-APPS: XMLSPY and DocBook Hi, I am considering using DocBook to create a Manual of Procedures. Ideally I'd like to do so in an environment that is easy for those who are unfamiliar with programming and mark up to understand. Currently I am trying to use XMLSPY. If someone has attempted this before I would very much appreciate input into the feasibility of this plan or if someone can suggest an information resource that would be great too. Thanks, Corey
DOCBOOK-APPS: xref linkend
In the archives I found the message below which illustrates my problem. I also found a solution for DSSSL from another list member. However, I am using: XSL Stylesheets V1.58.1 DocBook XML DTD V4.2 My xref points to a chapter element chapter id=introductiontitleIntroduction/title The xref looks like this xref linkend=introduction/ Has anyone come across this problem? If so is there a solution? Preferably something I can add to my customization layer, rather than editing the docbook xsl. Also, has someone added this to the buglist? Subject: DOCBOOK-APPS: Re: DOCBOOK: xref or link? From: Bob McIlvride [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Fri, 08 Jun 2001 10:24:49 -0400 Xref will automatically generate the link text; I don't get the output that TDG suggests. TDG says this SGML: paraA straight link generates the cross-reference text: xref linkend=ch02. /para reasonably renders like this: A straight link generates the cross-reference text: Chapter 2, The Second Chapter My SGML: paraHere is a test xref to xref linkend=testoftables./para renders like this: Here is a test xref to Chapter 3. I'd really like to get the name of the chapter in there, if possible. Any suggestions? Currently using: DocBook v. 4.1.2 DocBook stylesheets v. 1.64 OpenJade v. 1.3 Many thanks, -- Sean Wheller [EMAIL PROTECTED] XWriter
RE: DOCBOOK-APPS: xref linkend
Thanks Bob, I have read that and found a solution. Thanks. But I think that on the overall it missed the point. Which, is that TDG and the XSL are not aligned, so making the expected results, explained by TDG, unreliable. This demotes the value of the TDG as the definitive guide and IMHO should be fixed. My definition of a BUG is when a piece of software does not behave as specified in the requirements. Which for me is TDG. TDG V.2.07 is a work in progress, so we should be able to update either TDG or the XSL to perform as required. In this case, given that linkend, endterm and xreflabel do not perform as required, I think it should be the XSL. How do we do that? On the changes to the XSL, I really don't want to change the DocBook Sources. If I do, then I will have to remember all the fixes I have done when it comes to the next release. As with many, I prefer to change my customization layer, but once again, there will be a problem with knowing what was fixed in the next release so I can remove fixes from my customization. Warm Regards, Sean Wheller -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 3:25 AM To: Sean Wheller Cc: [EMAIL PROTECTED] Subject: Re: DOCBOOK-APPS: xref linkend There is an example of an XSL customization to add title to chapter xrefs in: http://www.sagehill.net/xml/docbookxsl/CustomMethods.html#CustomGenText Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: [EMAIL PROTECTED] On Sat, Jan 11, 2003 at 11:41:29PM +1100, Sean Wheller wrote: In the archives I found the message below which illustrates my problem. I also found a solution for DSSSL from another list member. However, I am using: XSL Stylesheets V1.58.1 DocBook XML DTD V4.2 My xref points to a chapter element chapter id=introductiontitleIntroduction/title The xref looks like this xref linkend=introduction/ Has anyone come across this problem? If so is there a solution? Preferably something I can add to my customization layer, rather than editing the docbook xsl. Also, has someone added this to the buglist? Subject: DOCBOOK-APPS: Re: DOCBOOK: xref or link? From: Bob McIlvride [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Fri, 08 Jun 2001 10:24:49 -0400 Xref will automatically generate the link text; I don't get the output that TDG suggests. TDG says this SGML: paraA straight link generates the cross-reference text: xref linkend=ch02. /para reasonably renders like this: A straight link generates the cross-reference text: Chapter 2, The Second Chapter My SGML: paraHere is a test xref to xref linkend=testoftables./para renders like this: Here is a test xref to Chapter 3. I'd really like to get the name of the chapter in there, if possible. Any suggestions? Currently using: DocBook v. 4.1.2 DocBook stylesheets v. 1.64 OpenJade v. 1.3 Many thanks, -- Sean Wheller [EMAIL PROTECTED] XWriter -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: [EMAIL PROTECTED]
RE: DOCBOOK-APPS: procedure - Getting Extra Line in step
Hello David, I have added your fix to my customization layer and performed a test. The result on steps, listitems and callouts is as follows: 1. This is the thing to do. This is the thing that happens. 2. This is the next thing to do. This is the next thing that happens. Conclusion, the Extra Line in Step is fixed, pretty much what Brads step/para[1] did, only now an additional white space is inserted at the beginning of the line. Sean Wheller XWriter -Original Message- From: David Cramer [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 5:40 PM To: Bob Stayton; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: DOCBOOK-APPS: procedure - Getting Extra Line in step I'd posted a fix for the problem in answer to a question a while back http://sources.redhat.com/ml/docbook-apps/2002-q2/msg00493.html, but neglected to log a bug or ask the poster to. Looks like half the fix was put into the distribution (at revision 1.25 of lists.xsl), but the other half (which ends up doing the same thing that Brad Thacker's fix does) wasn't. The template in question has been made smarter since my original post, so now add the following to your customization if you use procedures: xsl:template match=listitem/*[1][local-name()='para' or local-name()='simpara' or local-name()='formalpara'] |step/*[1][local-name()='para' or local-name()='simpara' or local-name()='formalpara'] |callout/*[1][local-name()='para' or local-name()='simpara' or local-name()='formalpara'] priority=2 fo:block xsl:apply-templates/ /fo:block /xsl:template I committed this change to cvs (revision 1.31 of lists.xsl). David -Original Message- From: Bob Stayton [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 8:53 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: DOCBOOK-APPS: procedure - Getting Extra Line in step On Tue, Dec 24, 2002 at 05:24:19PM +1100, Sean Wheller wrote: On Date: Thu, 25 Jul 2002 12:28:08 -0600, Thacker, Brad [EMAIL PROTECTED] wrote: From my experience, this appears to be a bug in the xsl stylesheets. I've seen this problem for over a year, and I've upgraded through three versions of docbook-xsl (I'm currently at 1.49). I was able to fix the problem by adding the following template to my customization layer: xsl:template match=step/para[1] fo:block xsl:apply-templates/ /fo:block /xsl:template I don't know if the solution Brad posted, works or if any other patch was posted, so if somebody knows of a solution to this problem other than that posted by Brad please let me know. I have added Brads template suggestion to my customization layer, but when performing the transform from DocBook XML FOP I get the following error: F org.xml.sax.SAXParseException: The prefix fo for element fo:block is not bound. I use the oXygen XML Editor for my editing. As I don't understand XSL-FO I am not able to dig into the problem myself. Hope somebody can help. This is just a namespace problem. Look at the top of the fo/docbook.xsl distribution file and you will see how the fo: namespace is declared, and copy that to your customization layer. Has someone file a sourceforge bug report on this problem? -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: [EMAIL PROTECTED]
RE: DOCBOOK-APPS: procedure - Getting Extra Line in step
On Date: Thu, 25 Jul 2002 12:28:08 -0600, Thacker, Brad [EMAIL PROTECTED] wrote: From my experience, this appears to be a bug in the xsl stylesheets. I've seen this problem for over a year, and I've upgraded through three versions of docbook-xsl (I'm currently at 1.49). I was able to fix the problem by adding the following template to my customization layer: xsl:template match=step/para[1] fo:block xsl:apply-templates/ /fo:block /xsl:template I don't know if the solution Brad posted, works or if any other patch was posted, so if somebody knows of a solution to this problem other than that posted by Brad please let me know. I have added Brads template suggestion to my customization layer, but when performing the transform from DocBook XML FOP I get the following error: F org.xml.sax.SAXParseException: The prefix fo for element fo:block is not bound. I use the oXygen XML Editor for my editing. As I don't understand XSL-FO I am not able to dig into the problem myself. Hope somebody can help. -- Sean Wheller [EMAIL PROTECTED] XWriter
