Re: DOCBOOK: Re: On the size of DocBook...
On Fri, Sep 06, 2002 at 03:24:09PM -0400, Norman Walsh wrote: Why is Simplified DocBook easier to use than full DocBook? 1. Because when you open the DTD in emacs and read the content models, it's smaller. 2. Because the user documentation for Simplified lists fewer elements. 3. Because when you pull down the what can I insert here list, it's shorter. 4. Because it's named Simplified, it's less intimidating. 5. ...? Options 3 and 4 seem most likely to me. Option 1 really requires making the schema smaller, but I can't imagine the set of people comfortable reading DocBook in the raw who are also disturbed by its size is very large. That's a tautology: people who are using the 400-element DocBook DTD aren't put off by the fact that it's a 400-element DTD. There are many people out there who aren't using DocBook, and it's important to understand why. That it takes 650 pages to describe is rather intimidating. That there are elements like errorcode and calloutlist doesn't help someone trying to write an article, or a simple HOWTO structured as a book. I've tried to introduce DocBook in a handful of organizations. The TDG made it somewhat easier (it *must* be real; there's an O'Reilly book about it). But in the end, I've seen a lot of efforts fail because using DocBook only seems to work for people who have decided that learning how to use the DTD and tools is eventually better than the alternatives, despite the initial pain. Just for kicks, how difficult would it be to refactor DocBook into a simple core (based on Simplified DocBook, or the moral equivalent), and implement the full DTD as multiple layers of customizations on top of the simpler core? Once that's done, then it's easier[*] to consider adding more elements in the DTD: a simple core plus the required extra layers plus a few more elements, vs. a huge core plus a few extra elements. Z. *: easier from the user perspective, not from the DTD maintainer/tool writer's perspective.
DOCBOOK: Re: On the size of DocBook...
On Fri, Sep 06, 2002 at 05:14:18PM -0400, Norman Walsh wrote: / Adam Turoff [EMAIL PROTECTED] was heard to say: | Just for kicks, how difficult would it be to refactor DocBook into | a simple core (based on Simplified DocBook, or the moral equivalent), | and implement the full DTD as multiple layers of customizations on Quite. Hard that is. And it would introduce N! different DocBooks. How easy would that be to explain? I thought it would be difficult. How would I explain N! DocBook DTDs? Well, they're all subsets of the main DocBook DTD. :-) How difficult would it be to do that work conceptually, without going through the exercise creating DTDs, as customization layers or otherwise? I suspect it wouldn't be difficult at all. Most of that work is already done in TDG. Identifying the most important core 25-50 elements might be a little tricky, but identifying the 25-50 related tag groups (gui..., func...) shouldn't be *that* hard. :-) Basically, there are a bunch of people who understand HTML and the idea behind XML that still find the concepts behind DocBook too daunting. Figuring out how to subset DocBook is key. I think RSS 1.0 is on to something with a simple core and a series of extension modules (groups of related tags). | fail because using DocBook only seems to work for people who have | decided that learning how to use the DTD and tools is eventually | better than the alternatives, despite the initial pain. Would the learning curve for DocBook Core + DocBook Dublin Core + DocBook Unix really have a significantly gentler slope? Aren't the really hard issues editorial? I'd submit that Core + DC + UNIX wouldn't be that difficult to learn. Most programming language introductions build on concentric layers of features. This kind of breakdown is somewhat similar. Also, it mimics RSS 1.0 (modulo RDF syntactic sugar): a small, simple core, with discrete groups of additional elements. Most of the hard issues *are* editorial. I don't use authoring tools, but I'd expect that someone who wants to use a particular 75 elements that describe the content in their document want to necessarily ignore the other 325 or so that aren't useful. (Is this similar to the TEI pizza cutter approach you wanted to avoid?) Learning how to do structured authoring is hard. I suggest that it's possible that learning how to do structured authoring with a big DTD is only incrementally more difficult than learning how to do it with a small DTD. I don't know about that. Structured authoring with a 14 element DTD doesn't really compare to structured authoring with a 100 or a 400 element DTD. People know how to use HTML now, and the good ideas behind XML are rather well entrenched. Z.
Re: DOCBOOK: embedded image in RTF
On Mon, Aug 19, 2002 at 02:55:08PM +0200, Stefan Kuhn wrote: Hi Jirka, thanks for the tip. It's a linux server :-( (first time in my live a windows server would have advantages!). I've come across this problem as well. I believe (but have not yet confirmed) that RTF *can* support embedded images. The issue is that the RTF backend in Jade does not support image embedding, just linking to external images. If so, then it should be possible to post-process the RTF output (with Perl or some other script) to embed the linked images. But given how nasty RTF is as a format, I doubt it'll happen anytime soon. Z.
Re: DOCBOOK-APPS: Problems with passivetex / pdfxmltex
On Wed, Feb 27, 2002 at 08:51:05AM +0100, Holger Rauch wrote: On Wed, 27 Feb 2002, Adam Turoff wrote: I started out with a vanilla teTeX 1.0.7 install, [...] I recommend that you use TeXLive instead of the teTeX that comes with FreeBSD. It's available from I understand that TeXLive might be the best TeX distribution out there today, but I'd really prefer to fix the up-to-date teTeX installation if at all possible. From what I gather, it's *mostly* working. pdflatex is fine, and in some cases xmltex - dvipdfm is fine (some tests fail for some unexplained reason). The errors I'm seeing appear to be fundemental (i.e. fotex.xmt isn't loading properly with xmltex.tex). This ISO image contains TeX setups for various Unix derivates (including FreeBSD) and for Win*. In my opinion, it's got the best setup for TeX stuff related to SGML/XML processing. Ideally, I'd like to solve the problem of upgrading pdftex and installing passivetex to get the job done. Once that's complete, I want to make a couple of ports for the FreeBSD Ports collection to solve this problem for FreeBSD users who tend to be running teTeX anyway. While TeXLive may be better, it's a rather big download (~270 MB), a snapshot of an ISO filesystem, and quite unlikey to become a FreeBSD port... Thanks for your recommendation, and I'm downloading the ISO file at the moment. It looks like it'll take 12 hours to download over a modem. :-S Z.
DOCBOOK-APPS: Problems with passivetex / pdfxmltex
I'm trying to install PassiveTeX on a handful of computers. The
Win* boxen configured like a charm thanks to MiKTeX. My FreeBSD box,
however, has been no end of headaches.
I started out with a vanilla teTeX 1.0.7 install, and had some problems
with pdfxmltex; after poking around the list archives for a while, I
saw that I needed to upgrade from pdftex-13d to pdftex-14h; after a lot
of guesswork that seems to be OK.
But now something still seems to be broken. pdflatex works just
fine, and I can format one of the test files in the passivetex/test
directory just fine with xmltex/dvipdfm, but never with pdfxmltex:
$ pdfxmltex teiu5.fo
This is pdfTeX, Version 3.14159-14h-released-20010417 (Web2C 7.3.3.1)
(./teiu5.fo{/usr/local/share/texmf/pdftex/config/pdftex.cfg}
LaTeX2e 1999/12/01 patch level 1
Babel v3.6Z and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
xmltex version: 2000-03-08 v0.14 DPC
(/usr/local/share/texmf/tex/latex/passivetex/xmltex.cfg)
No File: teiu5.cfg (/usr/local/share/texmf/tex/latex/passivetex/fotex.xmt
! Undefined control sequence.
l.24 \XMLstringX
\prop@widthproportional-column-width(1)/
? ^D
! Emergency stop.
And xmltex fails on some of the *.fo files, particularly darkness.fo:
$ xmltex darkness.fo
This is TeX, Version 3.14159 (Web2C 7.3.1)
(darkness.fo
LaTeX2e 1999/12/01 patch level 1
Babel v3.6Z and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
xmltex version: 2000/09/07 v1.8y (Exp):
(/usr/local/share/texmf/tex/latex/passivetex/xmltex.cfg)
[...]
(/usr/local/share/texmf/tex/latex/psnfss/t1ptm.fd)
! Missing \endcsname inserted.
to be read again
\Odd:
l.1 ...r//fo:block/fo:static-contentfo:flow
I've run texhash many times, and built pdfxmltex.fmt and xmltex.fmt
thusly:
initex \latex /usr/local/share/texmf/tex/latex/passivetex/xmltex.tex
pdfinitex \pdflatex \
/usr/local/share/texmf/tex/latex/passivetex/pdfxmltex.ini
Any ideas what might be going wrong? Both errors seem pretty fundemental...
Thanks,
Z.
Re: DOCBOOK: Linking in DocBook V5.0
On Wed, Nov 14, 2001 at 11:07:10AM -0500, Norman Walsh wrote: So my proposal is that we allow most (all?) inline elements to optionally function as simple links. We may also want to allow selected other elements (like funcprototype) to function as simple links as well. Which inline elements do you mean here (i.e., which PE definitions)? Or, do you mean anything that can be found inside of para? There's a reasonably good case for making block elements such as section and chapter take xlinks as well; it makes it easier to compose larger works from smaller works without resorting to defining entities in the local subset, especially when using xlink:show=embed. (Perhaps this means that there are a class of elements where xlink:show is only meaningful if it is xlink:show=embed...) For extended links, I'm not sure what makes the most sense. For those of us who aren't keeping track of XLink progress, can you please provide a 30-second refresher of what an extended link is? :-) Thanks muchly, Z. To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Tables in print output
On Fri, Oct 12, 2001 at 02:15:51PM +0200, Katharina Udemadu wrote: I have trouble producing tables in print output. I get only one table row. And this message: openjade:/home/documentation/DocBook/dsssl/print/dbtable.dsl:404:5:E: flow object not accepted by port; only table-column flow objects followed by table-row or table-cell flow objects allowd I am using XML DocBook 4.1.2, Openjade 1.4 and the Norman Walsh DSSSL-Stylesheets 1.71. Does anybody know how to solve this problem? It's difficult to say without seeing a small piece of your table markup that causes this problem. The error is occurring in this function: (define ($process-row$ ...) ...) which leads me to suspect that the stylesheet is processing a row without some of the required markup surrounding a row. Z. To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: XSLT 'or' statement (Was Re: DOCBOOK-APPS: How can I getstylesheet to bold?)
On Tue, Jul 31, 2001 at 01:39:38PM -0400, Dan York wrote: xsl:template match=emphasis xsl:choose xsl:when test=@role='bold'|@role='strong' !-- changed line -- xsl:call-template name=inline.boldseq/ /xsl:when xsl:otherwise xsl:call-template name=inline.italicseq/ /xsl:otherwise /xsl:choose /xsl:template However, in running it through 'xsltproc' I found that I was getting an error generated. It actually seemed to work correctly, but gave me error messages. I did some research and found that the 'or' functionality of XSLT actually uses the word or. So the test needs to be: xsl:when test=(@role='strong') or (@role='bold') Once I changed that, everything worked fine and no errors were produced. One source for this is on the XPath page at: http://www.w3.org/TR/xpath#booleans I was a bit surprised as I expected the | symbol to work, but it appears that it is at least not proper XSLT. (At least that is what I could see in the docs.) Dan, The '|' operator creates the union of 2 XPath location paths. The 'or' operator evaluates the boolean or of two XPath predicates. Both predicates and location paths are valid XPath expressions, but they can be used in completely different contexts: Location paths: section | sect1 | sect2 | sect3 | sect4 | sect5 /book/title | /article/title Predicates (and similar expressions): @role='bold' or @role='strong' count(ancestor::section) = 0 or @id='1' The easiest thing to do is to know when you're dealing with a location path, and know when you're dealing with a predicate or other such expression. Hope this helps, Z. -- To unsubscribe from this elist send a message with the single word unsubscribe in the body to: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: saxon
On Fri, May 25, 2001 at 03:59:22PM -0400, Kunath, Marcel wrote: I was trying out an example but it gave me this error: F:\saxon\samplesjava com.icl.saxon.StyleSheet data\othello.xml styles\play.xsl dir=playhtml Exception in thread main java.lang.NoClassDefFoundError: com/icl/saxon/StyleSheet It says to add the directory to the classpath. God knows what this means under Windows. I added f:\saxon to the System PATH variable. Doesn't help. Adding the directory to the PATH variable isn't sufficient. You need to add the path to the file saxon.jar in the CLASSPATH variable. Make sure your environment variable called CLASSPATH that contains the path to saxon.jar. Once you've done that, java can then find com.icl.saxon.StyleSheet and Saxon can then process your document. What is the difference in this binary and the saxon.jar file and where do I get it (the binary) from? The binary form is a prepackaged version of the same code; it's a convenience for people who don't want/need to deal with setting up Java to run Saxon on Windows. :-) http://users/iclway.co.uk/mhkay/saxon/saxon6.0.2/instant-saxon.zip Z. -- To unsubscribe from this elist send a message with the single word unsubscribe in the body to: [EMAIL PROTECTED]
Re: DOCBOOK: Re: Linking in DocBook V5.0
-> Re: DOCBOOK: Re: Linking in DocBook V5.0 docbook -- Thread -- -- Date -- Find Re: DOCBOOK: Re: Linking in DocBook V5.0, Elliotte Rusty Harold -- Chronological -- -- Thread -- p04330102b82ff394677a@[192.168.254.4]"> Reply via email to Re: DOCBOOK: Re: Linking in DocBook V5.0, Elliotte Rusty Harold -- Chronological -- -- Thread -- p04330102b82ff394677a@[192.168.254.4]"> Reply via email to Re: DOCBOOK: Re: Linking in DocBook V5.0, Elliotte Rusty Harold -- Chronological -- -- Thread -- p04330102b82ff394677a@[192.168.254.4]"> Reply via email to Re: DOCBOOK: Re: Linking in DocBook V5.0, Elliotte Rusty Harold -- Chronological -- -- Thread -- p04330102b82ff394677a@[192.168.254.4]"> Reply via email to Re: DOCBOOK: Re: Linking in DocBook V5.0, Elliotte Rusty Harold -- Chronological -- -- Thread -- p04330102b82ff394677a@[192.168.254.4]"> Reply via email to Re: DOCBOOK: Re: Linking in DocBook V5.0, Elliotte Rusty Harold -- Chronological -- -- Thread -- p04330102b82ff394677a@[192.168.254.4]"> Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "3243237953"; google_color_border = "CE9689"; google_color_bg = ["FF","ECE5DF"]; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: DOCBOOK: Re: Linking in DocBook V5.0 Adam Turoff DOCBOOK: Re: Linking in DocBook V5.0 Norman Walsh Re: DOCBOOK: Re: Linking in DocBook V5.0 Elliotte Rusty Harold DOCBOOK: Re: Linking in DocBook V5.0 Norman Walsh Re: DOCBOOK: Re: Linking in DocBook V5.0 Elliotte Rusty Harold DOCBOOK: Re: Linking in DocBook V5.0 Norman Walsh Re: DOCBOOK: Re: Linking in DocBook V5.0 Elliotte Rusty Harold Re: DOCBOOK: Re: Linking in DocBook V5.0 Bob Stayton DOCBOOK: Re: Linking in DocBook V5.0 Norman Walsh Re: DOCBOOK: Re: Linking in DocBook V5.0 Bob Stayton Re: DOCBOOK: Re: Linking in DocBook V5.0 Elliotte Rusty Harold Reply via email to
