Re: DOCBOOK: Warning: Newbie Question
Robert, If there is anyone one out there who has successfully been able to use DocBook on a PC and who would be willing to help a clueless newbie, please contact me at [EMAIL PROTECTED] We do most of our work on Linux, but I have had no problem at all generating DocBook files on a Windows box using the Windows version of Daniel Veillard's 'xsltproc' command (http://www.xmlsoft.org/XSLT/ ) and Norm's XSLT stylesheets. Now, we write most of our files using text editors with macros, so I have no idea about authoring/editing tools for Windows. But general production of DocBook documents on Windows *is* possible. Regards, Dan -- Dan York, Director of Training, Network Server Solutions Group Mitel Networks Corporation [EMAIL PROTECTED] Ph: +1-613-751-4401 Cell: +1-613-263-4312 Fax: +1-613-564-7739 150 Metcalfe Street, Suite 1500, Ottawa,ON K2P 1P1 Canada http://www.e-smith.com/ http://www.mitel.com/sme/ To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK: Warning: Newbie Question
At 11:18 24/10/2001 -0400, Dan York wrote: Robert, If there is anyone one out there who has successfully been able to use DocBook on a PC and who would be willing to help a clueless newbie, please contact me at [EMAIL PROTECTED] We do most of our work on Linux, but I have had no problem at all generating DocBook files on a Windows box using the Windows version of Daniel Veillard's 'xsltproc' command (http://www.xmlsoft.org/XSLT/ ) and Norm's XSLT stylesheets. Now, we write most of our files using text editors with macros, so I have no idea about authoring/editing tools for Windows. But general production of DocBook documents on Windows *is* possible. Robert is looking for a working windows SGML + dsssl setup, catalog example for dsssl stylesheets and dtd etc. I haven't used it for some time, so my memory is failing me. Anyone help him please? Regards DaveP To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Error: Output character not available
Gershon L Joseph wrote: I've got Saxon 6.4.3 working with the XSL DocBook stylesheets, and on some XML source files produce nice HTML Help. However, on a large docset I get the following error: Error on line 117 of file:/C:/tools/docbook/docbook-xsl-1.45/html/chunker.xsl: Output character not available in this encoding (decimal 8217) Transformation failed: run-time errors were reported My XML files are encoded in UTF-8, so I don't understand what's going on here. Any ideas? Well, there is another prove of bad design of HTML Help Workshop. This appliacation can't handle Unicode properly. You must use single-byte encodings in configuration files. By default ISO-8859-1 encoding is used and this encoding didn't contain Unicode character 8217 (right single quotation mark). Only solution to get around this problem is using other encoding which contains this character. It depends on language you are using, but windows-1252 might be useful for you. You can change encoding used for project file by parameter htmlhelp.encoding. You can set this parameter in customization file or pass it on command line: saxon yourfile.xml /path/to/htmlhelp.xsl "htmlhelp.encoding=windows-1252" This will solve error mentioned in your message. If you will get some "funny" characters in ToC or index, you should use two additional parameters to finaly solve lacks in HTML Help: saxon yourfile.xml /path/to/htmlhelp.xsl "htmlhelp.encoding=windows-1252" "default.encoding=windows-1252" "saxon.character.representation=native" Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Error: Output character not available
Jirka, Thanks for your help. Adding htmlhelp.encoding=windows-1252 helped. But then I get the following error: ... Writing htmlhelp.hhp Error on line 117 of file:/C:/tools/docbook/docbook-xsl-1.45/html/chunker.xsl: Output character not available in this encoding (decimal 174) Transformation failed: run-time errors were reported Using the following command with all 3 parameters you suggested makes no difference: saxon M:\doc\doc\products\mainwin\techdoc\src\docset.xml m:\doc\doc\tools\xsl\hh.xsl htmlhelp.encoding=windows-1252 default.encoding=windows-1252 saxon.character.representation=native The truth is I don't need to encode my XML source in UTF-8. I use English language only, so I could use ISO-8859-1. I used UTF-8 because it's become the default in Epic and I figured this way I could write other languages in the future without needing any further changes. Perhaps I was wrong. Do you suggest I change my XML source to ISO-8859-1, or is there a better solution? By the way, I get the above errors while processing the XSL stylesheet, not when running hhc.exe. The error occurs while the htmlhelp.hhp file is being written. Thanks again, Gershon On Wed, 24 Oct 2001, Jirka Kosek wrote: Gershon L Joseph wrote: I've got Saxon 6.4.3 working with the XSL DocBook stylesheets, and on some XML source files produce nice HTML Help. However, on a large docset I get the following error: Error on line 117 of file:/C:/tools/docbook/docbook-xsl-1.45/html/chunker.xsl: Output character not available in this encoding (decimal 8217) Transformation failed: run-time errors were reported My XML files are encoded in UTF-8, so I don't understand what's going on here. Any ideas? Well, there is another prove of bad design of HTML Help Workshop. This appliacation can't handle Unicode properly. You must use single-byte encodings in configuration files. By default ISO-8859-1 encoding is used and this encoding didn't contain Unicode character 8217 (right single quotation mark). Only solution to get around this problem is using other encoding which contains this character. It depends on language you are using, but windows-1252 might be useful for you. You can change encoding used for project file by parameter htmlhelp.encoding. You can set this parameter in customization file or pass it on command line: saxon yourfile.xml /path/to/htmlhelp.xsl htmlhelp.encoding=windows-1252 This will solve error mentioned in your message. If you will get some funny characters in ToC or index, you should use two additional parameters to finaly solve lacks in HTML Help: saxon yourfile.xml /path/to/htmlhelp.xsl htmlhelp.encoding=windows-1252 default.encoding=windows-1252 saxon.character.representation=native To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Error: Output character not available
Please ignore my previous plea for further assistance. I saved my source XML as iso-8859-1 encoding and put the 3 parameter settings in my driver file instead of on the command line. One or all of these fixed the problem. Thanks Jirka for pointing me in the right direction. I did read that in the docs, but did not realize it applies to English and UTF-8 under all circumstances. Gershon On Wed, 24 Oct 2001, Gershon L Joseph wrote: Jirka, Thanks for your help. Adding htmlhelp.encoding=windows-1252 helped. But then I get the following error: ... Writing htmlhelp.hhp Error on line 117 of file:/C:/tools/docbook/docbook-xsl-1.45/html/chunker.xsl: Output character not available in this encoding (decimal 174) Transformation failed: run-time errors were reported Using the following command with all 3 parameters you suggested makes no difference: saxon M:\doc\doc\products\mainwin\techdoc\src\docset.xml m:\doc\doc\tools\xsl\hh.xsl htmlhelp.encoding=windows-1252 default.encoding=windows-1252 saxon.character.representation=native The truth is I don't need to encode my XML source in UTF-8. I use English language only, so I could use ISO-8859-1. I used UTF-8 because it's become the default in Epic and I figured this way I could write other languages in the future without needing any further changes. Perhaps I was wrong. Do you suggest I change my XML source to ISO-8859-1, or is there a better solution? By the way, I get the above errors while processing the XSL stylesheet, not when running hhc.exe. The error occurs while the htmlhelp.hhp file is being written. Thanks again, Gershon On Wed, 24 Oct 2001, Jirka Kosek wrote: Gershon L Joseph wrote: I've got Saxon 6.4.3 working with the XSL DocBook stylesheets, and on some XML source files produce nice HTML Help. However, on a large docset I get the following error: Error on line 117 of file:/C:/tools/docbook/docbook-xsl-1.45/html/chunker.xsl: Output character not available in this encoding (decimal 8217) Transformation failed: run-time errors were reported My XML files are encoded in UTF-8, so I don't understand what's going on here. Any ideas? Well, there is another prove of bad design of HTML Help Workshop. This appliacation can't handle Unicode properly. You must use single-byte encodings in configuration files. By default ISO-8859-1 encoding is used and this encoding didn't contain Unicode character 8217 (right single quotation mark). Only solution to get around this problem is using other encoding which contains this character. It depends on language you are using, but windows-1252 might be useful for you. You can change encoding used for project file by parameter htmlhelp.encoding. You can set this parameter in customization file or pass it on command line: saxon yourfile.xml /path/to/htmlhelp.xsl htmlhelp.encoding=windows-1252 This will solve error mentioned in your message. If you will get some funny characters in ToC or index, you should use two additional parameters to finaly solve lacks in HTML Help: saxon yourfile.xml /path/to/htmlhelp.xsl htmlhelp.encoding=windows-1252 default.encoding=windows-1252 saxon.character.representation=native To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Need help including c source
Norman Walsh wrote: / Eric Richardson [EMAIL PROTECTED] was heard to say: | Thanks for the quick response. I found that it is very close. The | first markup works except for some extra leading whitespace on the | first line so perhaps I need to left justify the imagedata tag. The Yes. All whitespace is significant in programlisting | second way has no pre and perhaps that is okay? Yes, the programlisting provides the pre. I've spent some time to evaluate how this portion of the stylesheets renders to HTML. Here is what I found about programlisting and literallayout. 1. If the markup includes only text inside of programlisting or literallayout class=monospaced then all whitespace is significant. This is expected as these translate directly to pre class=xxx. This includes filename inside programlisting as this translates to tt. 2. If the elements have a inlinemediaobject inside so you can use imageobject and then imagedata fileref=sometext format=linespecific so you can enable extensions to include the external file then things change a bit. Only the space between the programlisting|literallayout and inlinemediaobject seem to be relevent. There are three ways it works okay from my perspective. 1. If there is no space between the elements then it works but the source looks ugly. 2. If you put the inlinemediaobject on the next line, left justified. This looks better and doesn't seem to effect the output. The span class=inlinemediaobject is put on the next line after the pre. 3. Leave an extra empty line in the file. This makes extra space in the result and is really undesirable. I really don't understand the stylesheets well enough to play around for different approaches but I feel this is a bit confusing. Most people understand the idea of literal text like pre but the interaction with included text is really non-intuitive based on the fact that markup isn't suppose to matter that much in source form and indenting seems the most comfortable. Also postprocessors are a factor as well but they should not mess with the content of a pre either way. Is there any way that the stylesheets could implement 2. above? They could look for the inlinemediaobject inside the tags that get translated to pre and then make sure that it gets put on the next line or the whitespace removed. This would be complicated a bit since programlistingfilenameinlinemediaobject is valid as well. I don't know if this is possible but I think it would help myself and other people doen the road. Thanks, Eric To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: Re-post: DOCBOOK-APPS: typographical characters encoding
Ok, some progress. The issue appears to be special apostrophes that were an artifact of the text having started out life in MS Word. XMetaL doesn't seem to do much about sorting these characters out or replacing them with correct apostrophes. Nor does it seem very good at finding and replacing these characters, or distinguishing among them. Once the MS apostrophes are gone, PassiveTeX does an admirable job of rendering to PDF as does FOP (provided you don't have much/any table markup in your source). Specifically the bullets work properly and all other typographical characters appear to be correct. Unfortunately, the IBM FOComposer software still doesn't deal with the bullet points, or em dashes for that matter. Perhaps next release. Why is it that these curly apostrophes are not flagged in some way by the various validators and/or procesors? XMetaL, Saxon, Xalan/Xerxes? PassiveTeX was the only package that flagged these characters as anomalies. ...edN At 01:31 PM 24/10/2001 -0400, Ed Nixon wrote: My PDF output contains incorrect characters for typographical symbols like the bullet, em-dash, and double quotes. Version: docbook-xsl-1.41 I haven't made any progress with this problem on my own since yesterday and I haven't seen any response from the list. Is there no one who can take a minute to give me some direction? The XML file is encoded in UTF-8 and today in iso-8859-1. The FO file has been encoded alternatively in UTF-8 and UTF-16. Looking at the FO source file, the bullet actually displays. However... After generating the PDF from IBM PDFComposer, the bullet is replaced with the number 42; out of PassiveTeX, vertical double quotes appear instead of bullets. PassiveTeX is polite enough to also alert me to the fact that it doesn't understand my apostrophes; there are no to screen diagnostics from the IBM processor. One thing that is confusing to me is the fact that some of the problem characters are generated by the stylesheets, i.e., the bullets. I can see that corrupt characters might end up in my source file given the Win2K environment and XMetaL but I don't see how the stylesheet generated characters could be problematical. And I have to confess, I don't understand why the encoding parameter isn't enough to sort everything out like magic. I'm happy to do the legwork if someone could simply point me to some appropriate information. Thanks for your help. ...edN To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Error: Output character not available
Gershon L Joseph wrote: Please ignore my previous plea for further assistance. I saved my source XML as iso-8859-1 encoding and put the 3 parameter settings in my driver file instead of on the command line. One or all of these fixed the problem. Thanks Jirka for pointing me in the right direction. I did read that in the docs, but did not realize it applies to English and UTF-8 under all circumstances. Your input document can by in any encoding (including UTF-8) supported by your XSLT processor. Only problem with HTML Help format is, that all characters used in your file must be directly representable in some of windows-125x encoding. Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
