[docbook-apps] Re: XSLT cannot find UnwrapLinks.so
Jirka Kosek writes:
> On 11.12.2019 10:10, Frank Arensmeier wrote:
>> When observing a HTML build with strace, I see a ridiculous large number of
>> entries like this:
>>
>> stat("/usr/lib/libxslt-plugins/nwalsh_com_xslt_ext_com_nwalsh_saxon_UnwrapLinks.so",
>> 0x7ffc9f117ee0) = -1 ENOENT (No such file or directory)
There’s never been an “so” file for that; it’s a Saxon extension, not
an xsltproc extension.
>> That plugin seems dead
>> (http://nwalsh.com/xslt/ext/com.nwalsh.saxon.UnwrapLinks
>> <http://nwalsh.com/xslt/ext/com.nwalsh.saxon.UnwrapLinks>). Can
>> someone shed some light on this? Why would you need that plugin? Can
>> you download that plugin somewhere?
It’s in the 1.0 stylesheets repository in
…/xsl-saxon/src/com/nwalsh/saxon/UnwrapLinks.java
Be seeing you,
norm
--
Norman Walsh | Men of genius do not excel in any
http://nwalsh.com/| profession because they labor in it,
| but they labor in it because they
| excel.--William Hazlitt
signature.asc
Description: PGP signature
[docbook-apps] Re: How do I generate a PDF through the gradle DocBookTask
Loren Cahlander writes:
> I found Norm Walsh’s grade DocBookTask in his article
> https://so.nwalsh.com/2018/03/05/easy
[…]
> I need to find the settings for generating a PDF.
I’ve been exploring the answer to that question recently. There are
two obvious avenues: through XSL-FO or through CSS. I’ve made both
work, though the DocBook 2.0 stylesheets for FO aren’t really as well
developed as the HTML ones.
Something as simple as this, should produce FO:
task myPdfDocument(type: DocBookTask) {
// And tell the pipeline to validate with the schema
option("schema", "https://docbook.org/xml/5.1/rng/docbook.rng;)
input("source", "document.xml")
output("result", "output.fo")
option("format", "print")
}
I’ve produced PDF with CSS (via AntennaHouse) recently, see the xproc_pdf
task in build.gradle in github.com/xproc/3.0-specification/
Be seeing you,
norm
--
Norman Walsh | Waste no more time arguing what a good
http://nwalsh.com/| man should be. Be one.--Marcus Aurelius
signature.asc
Description: PGP signature
[docbook-apps] Re: Some beginner questions for db xslt20-stylesheets
aanno writes:
> 1. So far I have used 'java -jar docbook-xslt2-2.3.8.jar -f foprint -o
> out.fo howto.xml' to get an PDF of my document. However, I wonder if
> it is possible to get the _xsl-fo output_ of the document as well.
> There seems to be a lot of options (and I have played around with
> 'return-secondary' but with no useful result), so perhaps this is easy.
I think you’d have to modify the pipeline to do that.
> 2. When I try the '(css)print' format, I only get the error:
> 'XProcException: No CSS processor class defined'. I guess I'm
> missing something here.
Right. You need a tool to do CSS printing. I believe you can use
either AntennaHouse or Prince, but I confess I haven’t tried anything
but AntennaHouse recentluy.
> 3. What are my options for using _math_ inside a docbook document?
You can put MathML in an inlineequation. Successful output is going
to depend on a processor that can render MathML, of course.
If you’ve got a tool that can turn MathML into bitmaps, you could
construct a pipeline to do that, I expect.
> 4. Is it possible to do source code highlighting in docbook?
In the browser, yes. I don’t think there’s a solution for doing it in
print at the moment.
Be seeing you,
norm
--
Norman Walsh | So, are you working on finding that bug
http://nwalsh.com/| now, or are you leaving it until later?
| Yes.
signature.asc
Description: PGP signature
[docbook-apps] Re: XML databases
Camille Bégnis <cami...@neodoc.biz> writes: > thanks for this interesting discussion, what DB would you use or suggest > for XML? I’m strongly biased to suggest a particular commercial database, one that you can download and use for free from developer.marklogic.com. But I hear good things about BaseX as well and eXist has been around for ages. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | There has never been a perfect http://nwalsh.com/| government, because men have passions; | and if they did not have passions, | there would be no need for | government.--Voltaire signature.asc Description: PGP signature
[docbook-apps] Re: XML databases
Dave Pawson <dave.paw...@gmail.com> writes: > Agree with your logic. Good for thousands (hard to index) > Less so for hundreds (I use db indexing) Yes, but as I said, it depends on the app you’re trying to build. drinks.nwalsh.com: ~200 small documents, easy to build in a DB, harder outside. so.nwalsh.com: ~600 documents and growing, easy to build in a DB, *much* harder outside photos.nwalsh.com: ~14,000 documents, same story tzinfo.nwalsh.com: ~225,000 documents, probably not practical any other way (Drinks.nwalsh.com is a simple app, you could do that off the filesystem with a little bit of Python and some cleverness. So.nwalsh.com would be much harder because it’s using full-text, semantic, and geospatial indexes and runs queries in real time that rely on those indexes to perform well.) > I'd hate to have the data in a corrupt database Or a corrupt filesystem. I don’t think databases are inherently a riskier place to put your data. And if having them in a database encourages you to have a more reliably backup strategy, they’re arguably less risky. Backup early. Backup often. And remember: if you copy data to a backup drive, then remove the data from your computer, you don’t have a backup, you have a vulnerable data set on a single external drive. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | Limited in his nature, infinite in his http://nwalsh.com/| desires, man is a fallen god who | remembers heaven.--Lamartine signature.asc Description: PGP signature
[docbook-apps] Re: XML databases
Dave Pawson <dave.paw...@gmail.com> writes:
> What use cases are there for dropping a few hundred
> XML files into a (purpose built for XML) database?
I put XML in a database for the ability to index and search it,
primarily. Here’s a screenshot of my personal “evernote clone” that
stores a combination of XML and other formats.
The documents that contained the word DocBook (stemmed appropriately,
so DocBooking and DocBooked, if they were words, would also have
matched) are found quickly. The facets are constructed from other
fields in the those documents.
The ability to quickly search and use indexes to build facets allows
me to make an application that would be more difficult without a
database.
> I can see a risk (db failure) above the file system
> failure risks.
Backups. You want to have backups!
> Has anyone done that assessment and decided in
> favour of a database over the file system?
For a few hundred documents, it’s probably hard to make a compelling
argument for a database unless you want to build applications like the
one I described above.
For a few hundred thousand documents, ti’s probably hard to make a
compelling case for the filesystem.
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | The finest amusements are the most
http://nwalsh.com/| pointless ones.--Jacques Chardonne
signature.asc
Description: PGP signature
[docbook-apps] Re: Using the DocBook XSLT 2.0 stylesheets with Gradle
Dave Pawson <dave.paw...@gmail.com> writes: > It was probably quite a while since Norm used Windows! I haven’t done any development on a Windows box in this millenium. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | One should never make one's debut with http://nwalsh.com/| a scandal. One should reserve that to | give interest to one's old age.--Oscar | Wilde signature.asc Description: PGP signature
[docbook-apps] Re: Using the DocBook XSLT 2.0 stylesheets with Gradle
Dave Pawson <dave.paw...@gmail.com> writes:
> My position.
> 1. I don't stretch the schema (db simple would likely suffice)
> 2. I haven't updated my stylesheets in ages
> 3. I build html / pdf with svg ... (500k + words)
> 4. I want (need?) to validate as an option.
> 5. All files are on my hard drive
>
> ant lets me pick / choose bits|all
> Am I odd? Minority? Majority?
I don’t know if you’re in the minority or the majority. You’re
definitely in the “I’ve had this working since the previous millenium”
group, though.
There’s no reason you have to change.
That said, if you switch from the 1.0 stylesheets to the 2.0
stylesheets, you’ll find that you need to update your environment with
new tools.
If you want to do that by grabbing all the jars and installing them
locally and setting up your classpath and updating your shell scripts,
etc., by all means go for it. I’ve done it that way lots of times.
> Who needs steenkin
> esisinternet
>
> Sorry - that quote stuck from dsssl days Norm - bet you've forgotten it.
I remember the ESIS. :-)
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | We discover in ourselves what others
http://nwalsh.com/| hide from us, and we recognize in
| others what we hide from
| ourselves.--Vauvenargues
signature.asc
Description: PGP signature
[docbook-apps] Re: Using the DocBook XSLT 2.0 stylesheets with Gradle
Dave Pawson <dave.paw...@gmail.com> writes:
> I stopped at "you don't have to understand it" Norm?
> ... rude words.
Apologies. No disrespect intended.
> I got as far as ant for builds. I can understand most of that.
> Bash script... similar? Maybe
> gradle? Wozzat.
>
> Why make it deeper than needs be?
Well…I’m not sure I agree that it’s deeper than it needs to be.
I’ve been building toolchains for ages: make, ant, bash, perl,
ruby, python, sbt, etc. etc. etc.
I settled on Gradle because of the advantages I outlined in that
posting: it’s significantly better than ant for dealing with Maven and
for extensibility; it’s cross platform (unlike bash); it’s relatively
easy to install on most platforms (unlike make, perl, etc.); and it
transparently deals with a whole lot of the backend infrastructure.
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | The finest amusements are the most
http://nwalsh.com/| pointless ones.--Jacques Chardonne
signature.asc
Description: PGP signature
[docbook-apps] Using the DocBook XSLT 2.0 stylesheets with Gradle
Hello, Of possible interest to the readers of this list: https://so.nwalsh.com/2018/03/05/easy (I found a couple of bugs so there’ll be updates within a day or two, but I still think it might be of interest.) Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | Sun System & Network Admin manualIt is http://nwalsh.com/| important to realize that any lock can | be picked with a big enough hammer. signature.asc Description: PGP signature
[docbook-apps] Re: REST API description
Dave Pawson <dave.paw...@gmail.com> writes: > http://vrici.lojban.org/~cowan/XML/tagsoup/#tsaxon is available if you want to > use XSLT with an html source. These days, I’d recommend Henri Sivonen’s validator.nu parser for reading HTML. Tagsoup is great, but the point of the validator.nu parser is that it gives the same structures that browsers give, so it’s a more consistent place to start. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | The finest amusements are the most http://nwalsh.com/| pointless ones.--Jacques Chardonne signature.asc Description: PGP signature
[docbook-apps] DocBook.org may wobble
Hello world, I’m attempting to transition docbook.org to being automatically built by Travis CI on GitHub. This will ease maintenance and contributions. That may make access to DocBook.org a bit flakey over the next few hours/days. Apologies in advance. I’m also going to try to map wiki.docbook.org to the GitHub DocBook wiki. But that’s a separate thing. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | 'I have done that,' says my memory. 'I http://nwalsh.com/| cannot have done that'—says my pride, | and remains adamant. At last—memory | yields.--Nietzsche signature.asc Description: PGP signature
[docbook-apps] Re: [OT] DocBook XSL license
"Jan Tosovsky" <j.tosov...@email.cz> writes:
> I'd like to verify if this license is compatible with that found in DocBook
> XSL distribution:
>
> http://docbook.sourceforge.net/release/xsl/current/COPYING or alternatively
> http://docbook.sourceforge.net/release/xsl/current/doc/copyright.html
>
> What do you think?
I think it’s probably ok.
> Btw, do you happen plan changing this license to something more common? :-)
Turns out the license is the MIT license, I think, but we can change
things to make that more clear.
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | A rusty nail placed near a
http://www.oasis-open.org/docbook/ | faithful compass, will sway it
Chair, DocBook Technical Committee | from the truth, and wreck the
| argosy.--Sir Walter Scott
signature.asc
Description: PGP signature
[docbook-apps] Re: Tools to make DocBook easier
Lars Vogel <lars.vo...@gmail.com> writes:
> May I ask where does the code for the 'org.docbook.task' Gradle
> plug-in lives?
It's in the 2.0 repo:
https://github.com/docbook/xslt20-stylesheets
It's also on Maven. I have a "getting started" project that uses it.
I should uncloak that, I guess.
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | In science, "fact" can only mean
http://nwalsh.com/| "confirmed to such a degree that it
| would be perverse to withhold
| provisional assent." I suppose that
| apples might start to rise tomorrow,
| but the possibility does not merit
| equal time in physics
| classrooms.--Stephen J. Gould
signature.asc
Description: PGP signature
[docbook-apps] Re: Slides with Docbook
camille <cami...@neodoc.biz> writes: > that's really great news. We are interested in contributing to it, is it > available anywhere yet? No, not quite. I'll see if I can get it out this week or next, though after three weeks on the road, I expect to be well and truly swamped with my day job for a bit. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | Art happens--no hovel is safe from http://www.oasis-open.org/docbook/ | it, no prince may depend upon it, Chair, DocBook Technical Committee | and vastest intelligence cannot | bring it about.--J. M. Whistler signature.asc Description: PGP signature
[docbook-apps] Re: Slides with Docbook
Niels Müller <neinalw...@gmail.com> writes: > Does anyone make slides with docbook 5? If yes, how? I've just ported my stylesheets backend to produce the markup that Reveal.JS needs. Mostly, it's a little rough around the edges. I'll get it in the next XSLT 2.0 stylesheets release. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | Resist the urge to hurry; it will http://www.oasis-open.org/docbook/ | only slow you down--Bruce Eckel Chair, DocBook Technical Committee | signature.asc Description: PGP signature
[docbook-apps] Re: DocBook XSL 1.79.0 release is available
Stefan Seefeld <ste...@seefeld.name> writes: >> I'm not sure if this definition of "large open-source project" would fit >> for a (hypothetical) DocBook organization. However, maybe it would be >> beneficial to have one as it allows more fine-grained repository >> permissions? Not sure if that's a good thing for DocBook. >> >> Just my thoughts. :)) > > Yes, I fully agree to the above. I'm trying to figure it out. Suggestions comments etc most welcome. Be seeing you, norm -- Norman Walsh <n...@nwalsh.com> | A child becomes an adult when he http://www.oasis-open.org/docbook/ | realizes he has a right not only Chair, DocBook Technical Committee | to be right but also to be | wrong.--Thomas Szasz signature.asc Description: PGP signature
[docbook-apps] Moving the DocBook wiki
Hi folks,
Over the last day or so, I captured the state of wiki.docbook.org as
best I could and ported the pages over to:
https://github.com/docbook/wiki
I think if I convert the "docbook" user at github into an "organization",
I'll be able to setup wiki.docbook.org to point to it.
In the meantime, feel free to explore and report any problems. If you
send me your github ID, I'll add you as a collaborator and then you
can edit the pages.
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | When we are tired, we are attacked
http://www.oasis-open.org/docbook/ | by ideas we conquered long ago.--
Chair, DocBook Technical Committee | Nietzsche
signature.asc
Description: PGP signature
[docbook-apps] Re: Tools to make DocBook easier
Warren Block <wbl...@wonkity.com> writes:
> What tools are there to make working with DocBook easier?
I'm just in the process of finishing up a first release of a tool
to make DocBook publishing easier with gradle. Given doc.xml, written
in DocBook, this build.gradle file will download all of the necessary
dependencies and run the transformations.
buildscript {
repositories {
mavenCentral()
maven { url "http://maven.restlet.org; }
}
dependencies {
classpath group: 'org.docbook', name: 'docbook-xslt2', version: '2.0.14'
classpath group: 'com.xmlcalabash', name: 'xmlcalabash1-print', version:
'1.1.4'
}
}
repositories {
mavenLocal()
mavenCentral()
}
apply plugin: 'org.docbook.task'
import org.docbook.DocBookTask
task publishhtml5(type: DocBookTask) {
format "html"
input "doc.xml"
output "index.html"
}
task publishxhtml(type: DocBookTask) {
format "xhtml"
input "doc.xml"
output "index.html"
}
task publishpdf(type: DocBookTask) {
format "foprint"
input "doc.xml"
pdf "doc.pdf"
}
Needs documentation and such, but it does at least run now. :-)
Be seeing you,
norm
--
Norman Walsh <n...@nwalsh.com> | There might very well be nothing;
http://www.oasis-open.org/docbook/ | nor anyone. No one to notice that
Chair, DocBook Technical Committee | there is nothing, and to consider
| that natural. But that there is
| something, and, whatever it may
| be, the strange thing! I shall
| never cease being amazed at
| this.--André Gide
signature.asc
Description: PGP signature
[docbook-apps] Re: Syntax highlighting
Jan Tosovsky j.tosov...@email.cz writes: On 2013-12-09 Norman Walsh wrote: ... future work on XSL FO has largely been abandoned. Does it mean that XSL-FO 2.0/next is not planned any more? Is there any citation for this? http://www.w3.org/XML/XPPL/ This WOrking (sic) Group is no longer active, because of insufficient participation. The specifications are no longer maintained. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Mankind are always happy for http://www.oasis-open.org/docbook/ | having been happy; so that if you Chair, DocBook Technical Committee | make them happy now, you make them | happy twenty years hence by the | memory of it.--Sydney Smith signature.asc Description: PGP signature
[docbook-apps] Re: Syntax highlighting
Jan Tosovsky j.tosov...@email.cz writes: While I don't plan to upgrade my generating workflow to XSL 2.0 stylesheets in the near future, I am quite curious whether the proposed HTML+CSS approach can really cover all common needs: 1. ToC and Index with page numbers 2. Bookmarks 3. Double-sided version (different recto/verso margins, header/footer content) 4. Running header-footers (differences amongst title, blank or recto/verso pages) 5. Absolute positioning of title page graphics or other page elements 6. Using PDF format for images 7. Change bars Some of those things are easy, some not so easy. But I expect they can all be done. Not from the stock HTML stylesheets that you'd use on the web, but from a HTML-for-print stylesheet. I hear that O'Reilly now uses HTML+CSS for their print books. The reality is that free XSL FO tools never really matured. The commercial ones all work, but all have extensions to handle things that weren't fully specified. There's a large community focused on HTML+CSS+JS these days. It seems more likely (to me) that free HTML+CSS print tools will come along before greatly improved free XSL FO tools. Especially since future work on XSL FO has largely been abandoned. There are commercial HTML+CSS print formatters today that seem to be comparable to the XSL FO ones. AntennaHouse supports both and PrinceXML seems to do a competent job. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Everything that irritates us about http://www.oasis-open.org/docbook/ | others can lead us to an Chair, DocBook Technical Committee | understanding of ourselves.--Carl | Jung signature.asc Description: PGP signature
[docbook-apps] Re: HTML5 Audio + Video multiple sources
Peter Fleck peterfl...@gmail.com writes: video source src=video.ogg type=video/ogg / source src=video.mp4 type=video/mp4 / source src=video.webm type= video/webm /video If tried different ways but haven't been able to do it yet, is it possible? Not really. HTML5 brings significant new functionality to the realm of audio and video. It's probably time to revisit the markup that DocBook provides. Historically, neither browsers nor other rendering tools provided any facility for mutiple representations or fallback. Among the design goals for the existing mediaobject markup was the ability to provide for multiple alternatives in the DocBook source with the understanding that the transformation from DocBook to the output format would pick the right one. It was never an elegant design in part because the transformation tools rarely had any clue what the actual capabilities of the ultimate viewing tool would be. It also produced markup that's several layers deep. Those layers are needed in the case where multiple alternatives must be selected by the transformation tool, but in the (very common case) that no alternatives are provided, they're just extra tags. The situation is muddied further by the fact that, as alternatives, the videodata element has attributes that appear to be badly factored. For example, it seems likely that no matter which of two or three video alternatives you have, you want the content width, content depth, scaling, alignment and such to be the same. In defense of the odd factoring, bear in mind that for raster images, the choices are less clear. If a medium-resolution black and white image is an alternative for a high-res four color image, then perhaps you do want the size, scale, and alignment to differ between the two images. I'm not sure what the right answer is. If HTML5 is going to represent the state of the art for the forseable future, an argument can be made that we should simply copy its model. But we'd lose functionality if we did that (functionality that in the HTML5 world is pushed off to random nesting divs with class attributes). Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Labor, n. One of the processes by http://www.oasis-open.org/docbook/ | which A acquires property for Chair, DocBook Technical Committee | B.--Ambrose Bierce signature.asc Description: PGP signature
[docbook-apps] Syntax highlighting
Hello world, A fair bit of effort in the DocBook stylesheets goes into parsing, decomposing, annotating, and recomposing program listings for the purpose of adding line numbers to them. There's also a bunch of work that goes into syntax highlighting them. Occasionally, this takes a *long* time. It appears that modern systems do this in the JavaScript layer on the client. They also use tables to render line numbers. I'm tempted to move in this direction. Comments? As long as I'm airing dirty laundry, I'm also tempted to abandon the XSL stylesheets and work instead on a purpose-built HTML+CSS rendering for printing. I should say that this note is particularly about the XSLT 2.0 stylesheets that I've been working on, not the standard ones. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Resist the urge to hurry; it will http://www.oasis-open.org/docbook/ | only slow you down--Bruce Eckel Chair, DocBook Technical Committee | signature.asc Description: PGP signature
[docbook-apps] Table option for program listings
Hi folks, There was some discussion a while ago about how to format program listings. I never found a solution that I think is wholly satisfactory, but I did implement the table option in the XSLT 2.0 stylesheets, https://github.com/docbook/xslt20-stylesheets If you specify asTable=true in the linenumbering param or PI, you'll get a two column table. This has the feature that you can cut-and-paste the listing without the generated line numbers. It has the flaw that if you have a superscript or subscript or anything that causes the line height to vary, the line numbers will get out of sync. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | In great affairs men show http://www.oasis-open.org/docbook/ | themselves as they wish to be Chair, DocBook Technical Committee | seen, in small things they show | themselves as they are.-- Chamfort pgpzTWgfDnXkz.pgp Description: PGP signature
Re: [docbook-apps] Possible (brief?) {www.}docbook.org and wiki.docbook.org downtime
David Goss dg...@mueller-inc.com writes: I'm encountering an error, Element caption in namespace 'http://docbook.org/ns/docbook' encountered in figure, but no template matches whenever I try to build documents that previously built without a hitch. Could this problem be caused by docbook.org server changes? I *really* don't think so. That sounds like a stylesheet problem. Did you change your stylesheets recently? Be seeing you, norm -- Norman Walsh n...@nwalsh.com | He who will not reason is a bigot; http://www.oasis-open.org/docbook/ | he who cannot is a fool; and he Chair, DocBook Technical Committee | who dares not is a slave.--Sir | William Drummond pgpEM7uFBJ18v.pgp Description: PGP signature
[docbook-apps] Re: Better rendering for programlisting
David Cramer da...@thingbag.net writes: On 05/05/2012 10:38 AM, davep wrote: 1. Stick with what we have now. 2. Use the table solution and accept the limitation that all lines must always be the same height. Why is this an issue Norm? How often in a fixed width font do users want exponents/Drop caps etc? That's sort of the question. Is it OK if a graphic or superscript in a programlisting causes all of the line numbers to be weirdly out-of-sync? AFIACT, all of the table solutions I've seen online apply specifically to plain-text program listings, where there's no opportunity for other things to appear. In DocBook, other things can appear. Is that the author's problem, the production editor's problem, or the stylesheet's problem? The callouts cause the lines that contain them to be a little higher than the others, causing the line numbers to become out of whack. If you have more than a couple of callouts, the code listing ends up extending beyond the line numbers and obviously the line numbers aren't accurate. I think we can make the callout case work. We can use CSS to adjust the line-height so that callouts don't cause a problem. The more pressing issues are: what about cases where CSS isn't applied and what about program listings that contain other line-height-altering markup? I'm open to suggestions on 3, but I'm not likely to figure it out myself. Thoughts? Other suggestions? You've obviated the line numbers by putting content in col 2... why not finish the job and put co in col 3? Because that won't help. There could still be a superscript or image (think inlinemediaobject) in the programlisting. Then I could cut/paste? That should be hard requirement for html outputs. It's hard alright. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | I often marvel that while each man http://www.oasis-open.org/docbook/ | loves himself more than anyone Chair, DocBook Technical Committee | else, he sets less value on his | own estimate than on the opinions | of others.--Marcus Aurelius pgp36pOijo5v8.pgp Description: PGP signature
[docbook-apps] Re: Better rendering for programlisting
David Cramer da...@thingbag.net writes: 1. Remove the alt text, so that when the user copies the code listing nothing comes with it, but then you don't have alt text. All things considered, that seems the least objectionable. 2. Use SyntaxHighligher with modifications to allow callouts. This gives you syntax highlighting, line numbering, and copy, but has the tradeoffs mentioned in my previous posting in this thread. Requiring complex JavaScript goo seems...suboptimal. 3. a. Put the code listing in the page twice, once formatted however you like with callouts, syntax highlighting, line numbering, etc, and another time completely unmodified. If JavaScript is turned on, hide the unmodified version and show the modified version, but provide a Copy button which copies the content of the unmodified version into the clipboard b. Instead of a Copy button, use a Raw button/link which opens a small window showing the unmodifed version of the listing. And instead of putting the code listing in the page twice, put the unmodified listing in a separate file which is loaded in a new window when the user clicks the Raw link. Both 3a and 3b seem to impose pretty significant expectations on the rendering system. (With respect to generated files, filenames, linking etc.) Be seeing you, norm -- Norman Walsh n...@nwalsh.com | O for a Muse of fire, that would http://www.oasis-open.org/docbook/ | ascend / The brightest heaven of Chair, DocBook Technical Committee | invention, / A kingdom for a | stage, princes to act / And | monarchs to behold the swelling | scene!--William Shakespeare, Henry | V pgpVBl5qIcMup.pgp Description: PGP signature
[docbook-apps] Better rendering for programlisting
Hello world, The current rendering for verbatim environments, when line numbers are enabled, has a significant deficiency: you can't cut-and-paste the listing without also getting the line numbers and separators. Looking around at other sites with numbered program listings, the solution seems to be to use tables. Put the line numbers in the first column and the listing in the second. That works, mostly, but if anything in the listing causes a variation in line height (such as a larger callout), the numbers and the lines get out of sync. Using one-line-per-row fixes this, but then cut-and-paste doesn't work again; the selection crosses over all the columns in each row. An alternative solution uses nested divs and some slightly fancy CSS. Naturally, it doesn't work in IE. I've put an example online: http://nwalsh.com/scratch/out.html The callout graphics in the listing are intentionally broken because that was the easiest way to introduce variation. At this font-size, the callouts are actually ok. So: 1. Stick with what we have now. 2. Use the table solution and accept the limitation that all lines must always be the same height. 3. Find a way to tweak the CSS solution so that IE doesn't fall over I'm open to suggestions on 3, but I'm not likely to figure it out myself. Thoughts? Other suggestions? Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Ahhh. A man with a sharp wit. http://www.oasis-open.org/docbook/ | Someone ought to take it away from Chair, DocBook Technical Committee | him before he cuts himself.--Peter | da Silva pgpMnRLPuvKqc.pgp Description: PGP signature
[docbook-apps] Re: Indexing.
davep da...@dpawson.co.uk writes: Are you asking more about the indexing task itself or about the technical aspect? The docbook aspects please Thomas The sources for The Definitive Guide have quite a bit of index markup from the O'Reilly copyedit. That might be a good place to look for examples. Speaking about the indexing task itself, IHMO this is something that some books don't take it seriously enough. An index is a service to make the book more accessible to readers. I've seen lots of bad index which came just as an alibi, but with no value. So it isn't a surprise that a good index takes time and energy. When I've created the index of my book, it took lots of iterations and I guess it still isn't perfect. :) Indexing is an art. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | There is no kind of dishonesty http://www.oasis-open.org/docbook/ | into which otherwise good people Chair, DocBook Technical Committee | more easily and frequently fall | than that of defrauding the | government.--Benjamin Franklin pgp2y9Pk5YZcB.pgp Description: PGP signature
[docbook-apps] Re: Indexing.
davep da...@dpawson.co.uk writes: I did made a note to for myself some time back that anindexterm inside a footnote caused an error. I was using oXygenXML v12 at the time. Not sure if this is still the case. Footnotes aren't normally indexed is one piece of advice. So perhaps docbook is right. I have a vague recollection that we may have loosened that restriction. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | She was mostly immensely relieved http://www.oasis-open.org/docbook/ | to think that virtually everything Chair, DocBook Technical Committee | that anybody had ever told her was | wrong. (Mrs. E. Kapelsen)--Douglas | Adams pgpSgqUmlw0k9.pgp Description: PGP signature
[docbook-apps] Re: How to use Calabash with the DocBook XSL1.0 Stylesheets?
Thomas Schraitle tom_s...@web.de writes: [...] Or start using the DocBook XSLT 2.0 stylesheets. :-) Actually I did, but wasn't successfull. :-) The usual docbook.xsl works like a charm. I don't have any problems with it so far. However, for some unknown reason, the chunk.xsl doesn't work for me (yet). I used Saxon9 with the original DocBook XSLT 2.0 stylesheet like this: $ saxon9 -xi -s:en/xml/DoCookbook.xml \ -xsl:frameworks/db-xslt2/xslt/base/html/chunk.xsl Interestingly, this doesn't print any Writing ... messages. I get these files now: chunk-appendix-d62e5692.html chunk-book-d62e2.html chunk-chapter-d62e2464.html chunk-chapter-d62e475.html chunk-preface-d62e179.html [...] Ok, it seems, the naming has been changed, but strangly I didn't get an index.html file. My naive thought was to have some navigation headers, but they don't show up in my HTML files. Maybe there is some magic which I've missed. I would love to use the chunking stylesheet too. :-) Hmm. I'll look into that. Can you send me a source document? Oh, by the way: When I've played with the XSLT2 stylesheets, I've came across some bugs. As I wasn't sure if you prefer still the Sourceforge ticker or Github, I used the former. Here are some pointers, hope they are helpful: #3464876 xslt2: keycap/@function not used #3464633 xslt2: Parameter img.src.path has no effect #3450421 xslt2: Relative paths for transclusion do not work #3431422 xslt2: menuchoice is not correctly rendered Github would be more convenient, actually. Sigh. I need to get this all cleaned up. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Old age is the most unexpected of http://www.oasis-open.org/docbook/ | all the things that happen to a Chair, DocBook Technical Committee | man.-- Trotsky pgpAY6CkEiHmZ.pgp Description: PGP signature
[docbook-apps] Re: How to use Calabash with the DocBook XSL1.0 Stylesheets?
Thomas Schraitle tom_s...@web.de writes: Well, I assume this has something to do that Saxon9 doesn't support the exsl:document or saxon:output extensions anymore. Unfortunately, this makes the combination XProc + Calabash + Saxon9 + DocBook XSLT1.0 unusable. It seems, it doesn't help to add the Saxon6 jar into the classpath. No, it doesn't. I think the only way to fix this would be to write an XProc extension step that used the Saxon6 implementation. Or start using the DocBook XSLT 2.0 stylesheets. :-) Can anybody confirm this behaviour? Is there any method to delegate an XSLT step for version 1.0 to Saxon 6? Has anybody successfully used Calabash with the DocBook XSLT 1.0 stylesheets? I'll take a quick peek at writing an cx:xslt1 extension step. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | What is familiar is what we are http://www.oasis-open.org/docbook/ | used to; and what we are used to Chair, DocBook Technical Committee | is most difficult to 'Know'--that | is, to see as a problem; that is, | to see as strange, as distant, as | 'outside us'.-- Nietzsche pgpvQvVYefuDJ.pgp Description: PGP signature
[docbook-apps] Re: Can't select link if 'linkend' contains text
Xmplar i...@xmplar.biz writes: I have in a document, d:link - for both links to other text in the document (e.g. link to a figure) as well as links to URLs. For both types of links I am using d:link. I would like the following code to select only those instances where the @linkend contains the string 'http' - and to then put angle brackets before and after those URLs. The if:test syntax under variable content is obviously wrong - what is the correct syntax for selecting linkends that are only URLs? The linkend attribute is supposed to contain an ID, the ID of the part of *this* document that you want to link to. If you want to link to another document, you want the xlink:href attribute (in DocBook V5) or the ulink element in DocBook V4). Hope that helps. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Of all the preposterous http://www.oasis-open.org/docbook/ | assumptions of humanity over Chair, DocBook Technical Committee | humanity, nothing exceeds most of | the criticisms made on the habits | of the poor by the well-housed, | well-warmed, and well-fed.--Herman | Melville pgpeDIeyeTvKT.pgp Description: PGP signature
[docbook-apps] DocBook Stylesheets 2.0.3 released
/xslt20-stylesheets/commit/30cd17ed3ce36fd9e824d553ef8c0c578514ed31 26. https://github.com/docbook/xslt20-stylesheets/commit/85d74a9e37f5197374692f3b0d7502366bbfd69f 27. https://github.com/docbook/xslt20-stylesheets/commit/2e22775ef4ad6e6a5c0fb082a10b3190dcca302f Be seeing you, norm -- Norman Walsh n...@nwalsh.com | The fact of having been born is http://www.oasis-open.org/docbook/ | bad augury for immortality.-- Chair, DocBook Technical Committee | Santayana pgpVcSR5B38YH.pgp Description: PGP signature
[docbook-apps] Re: DocBook Stylesheets 2.0.3 released
Robin Lee Powell rlpow...@digitalkingdom.org writes: On Thu, Dec 01, 2011 at 01:57:53PM -0500, Norman Walsh wrote: Hello world, I've released a new version of my (developing) XSLT 2.0 stylesheets for DocBook. Are these intended to act as a replacement for the usual docbook - html XSLT that xmlto uses? Can xsltproc run them? (the github, https://github.com/docbook/docbook.github.com , doesn't seem to have a howto at all) In the long run, yes, I consider them a replacement. I've already switched to the 2.0 stylesheets exclusively for my own work. However, they require XSLT 2.0 and that means they won't be supported by xsltproc until xsltproc is updated to support 2.0. I've forgotten exactly what xmlto does, I think it's just a shell script around xsltproc so it could (presumably) be tweaked to use a 2.0 processor. The most widely available 2.0 processor is Saxon 9.x. MarkLogic Server also supports XSLT 2.0. I'll try to get some more docs up when I can. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | What are the thoughts of the http://www.oasis-open.org/docbook/ | canvas on which a masterpiece is Chair, DocBook Technical Committee | being created? I am being soiled, | brutally treated and concealed | from view. Thus men grumble at | their destiny, however fair.--Jean | Cocteau pgpyKyD1BtpP1.pgp Description: PGP signature
[docbook-apps] Re: Docbook and 'style'. db5 and xsl-fo output
davep da...@dpawson.co.uk writes: Some time back I had an itch, I wanted to add style information to docbook schema. I've now scratched it, adding properties to a couple of elements and creating stylesheet customizations to match. See http://dpawson.co.uk/docbook/style/style.html Interesting. I've occasionally hacked a bit in the same vein on the HTML side of the house, updating schemas and stylesheets so that elements and attributes in the HTML namespace are passed through: para html:style=font-style: italic;Someh:br/pointless example text./para produces: p style=font-style: italic;Somebr /pointless example text./p Sometimes I think it's a good idea, sometimes I think I'm clearly doing the devil's work. I dunno. In my case, it was particularly handy to allow HTML elements in the info wrapper that were transparently passed through to the HEAD of the HTML document. It's certainly a step backwards from the mantra of separation of content and presentation. But you know, sometimes you have to get the job done. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Everything has been said before, http://www.oasis-open.org/docbook/ | but since nobody every listens we Chair, DocBook Technical Committee | have to keep going back and | beginning all over again.--André | Gide pgpTh4SNHPQhz.pgp Description: PGP signature
[docbook-apps] Re: Simplified Docbook Relax NG schema
Frank Arensmeier farensme...@gmail.com writes: Not sure if those files are official. Anyway. Everything is working great except the fact that elements like warning and caution are not part of those schema file. I am not sure if there are any other elements missing too. Is this intended? Yes. Simplified DocBook is designed to have only about 100 tags. It's more-or-less HTML-level markup in DocBook. I hope to have a new release of the schema shortly. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Society is immoral and immortal; http://www.oasis-open.org/docbook/ | it can afford to commit any kind Chair, DocBook Technical Committee | of folly, and indulge in any kind | of vice; it cannot be killed, and | the fragments that survive can | always laugh at the dead.--Henry | Adams pgpULlOo7Tdj3.pgp Description: PGP signature
[docbook-apps] Re: HTML5 version?
Larry Garfield la...@garfieldtech.com writes: Hi folks. At the moment I'm using the XHTML version of the DocBook XSL scripts. That's mostly fine, but I am trying to convert all of my web work over th HTML5. (Vis, using more semantic tags, reduced-complexity head elements, fewer extra wrapping divs, assuming that CSS actually works now so I can use modern selectors for styling, etc.) Depends how far back you need to go. Unknown elements are rendered inline and IE (versions prior to 9) can't style unknown elements at all by default. There are workarounds[1][2], and I'm sorely tempted to start relying on them in the HTML output from the DocBook XSLT 2.0 stylesheets, for which HTML5 is specifically the target. Be seeing you, norm [1] http://html5doctor.com/html-5-reset-stylesheet/ [2] http://remysharp.com/2009/01/07/html5-enabling-script/ -- Norman Walsh n...@nwalsh.com | Where are you dying http://www.oasis-open.org/docbook/ | tonight?--Evelyn Waugh Chair, DocBook Technical Committee | pgp6OyLBA5vgS.pgp Description: PGP signature
[docbook-apps] Re: Alternative syntax highlighter
Jirka Kosek ji...@kosek.cz writes: It would be interisting to take this further and try to call it using Jython directly from Saxon ;-) Your wish is my command. At least when it's fun and distracting and I have a whole list of really crushing deadlines. http://norman.walsh.name/2011/08/31/xsltPygments (I can do any amount of work, as long as it's not the work I'm supposed to be doing. Though in fairness, I did this last night when I wasn't supposed to be working at all. That's...better, or something. Right?) Be seeing you, norm -- Norman Walsh n...@nwalsh.com | CNN is one of the participants in http://www.oasis-open.org/docbook/ | the war. I have a fantasy where Chair, DocBook Technical Committee | Ted Turner is elected president | but refuses because he doesn't | want to give up power.--Arthur C. | Clark pgpsqpclbgfDK.pgp Description: PGP signature
[docbook-apps] Re: Alternative syntax highlighter
Jirka Kosek ji...@kosek.cz writes: It would be interisting to take this further and try to call it using Jython directly from Saxon ;-) I've almost got that working :-) Be seeing you, norm -- Norman Walsh n...@nwalsh.com | We are at the very beginning of http://www.oasis-open.org/docbook/ | time for the human race. It is not Chair, DocBook Technical Committee | unreasonable that we grapple with | problems. But there are tens of | thousands of years in the future. | Our responsibility is to do what | we can, learn what we can, improve | the solutions, and pass them | on.--Richard Feynman pgpTeLkA6FY15.pgp Description: PGP signature
[docbook-apps] Re: footnote in title
Stefan Seefeld ste...@seefeld.name writes: My book title contains a footnote, which is ignored in the recto titlepage, but not the verso. A book title with a footnote. Wow. Can anyone please point me into the right direction ? What template processes the title footnote in the recto / verso modes, and what change do I need to apply to move the footnote display onto the recto page ? If you put this template in your customization layer: xsl:template match=title mode=book.titlepage.recto.mode ... /xsl:template I believe it'll be called for the book's recto title. It's not immediately obvious to me why the current book title processing looses the footnote, but there's book.verso.title in titlepage.xsl that might be a good starting place. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Few men are so sufficiently http://www.oasis-open.org/docbook/ | discerning to appreciate all the Chair, DocBook Technical Committee | evil that they do.--La | Rochefoucauld pgpqxKE5iOfKV.pgp Description: PGP signature
[docbook-apps] DocBook XSLT 2.0 Stylesheets released
Hello world, After some years of use and some few days of polish, I decided to pull the trigger: http://norman.walsh.name/2011/08/25/docbook-xslt-2 It's a 0.0 release, so, you know, YMMV. But please do let me know what you think. I'll write another weblog posting about it, but in the meantime, yes, you can run the image extensions with Saxon HE. Just add -init:docbook.Initializer to the Saxon command line (and put the (included) jar file in your class path, of course). Be seeing you, norm -- Norman Walsh n...@nwalsh.com | My problems start when the smarter http://www.oasis-open.org/docbook/ | bears and the dumber visitors Chair, DocBook Technical Committee | intersect.--Steve Thompson, | wildlife biologist at Yosemite | National Park pgpLiQ9yL1k1P.pgp Description: PGP signature
[docbook-apps] Re: docbook-xsl/manpages: does not handle simpara in footnote correctly
Jonathan Nieder jrnie...@gmail.com writes: I wrote this report about a month and a half ago and sent it to sub...@bugs.debian.org and docbook-apps@lists.oasis-open.org, but I am not sure it ended up in the right place. Could you take a glance and let me know? It looked ok to me, so I went ahead and applied the patch. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Faith makes many of the mountains which http://nwalsh.com/| it has to remove.--W. R. Inge pgpi6frZRbO1E.pgp Description: PGP signature
[docbook-apps] Rethinking XSLT 2.0 design
Hi folks, I'm going to be turning my hands to the XSLT 2.0 stylesheets for DocBook again soon, partly with an eye towards making them more production ready, partly to try a few experiments. When I set out on the XSLT 2.0 reimplementation, I had in mind a design where there'd be a normalization phase that does some cleanup followed by a processing phase that does the actual work. For example, normalization turns sectiontitlefoo/title... into sectioninfotitlefoo/title/info... so that subsequent processing can know that the title is section/info/title. After several years of experience, I've come to the conclusion that that was a mostly bad idea. 1. It's very expensive. The entire document gets processed at least twice. While the idea of simplifying the downstream design seemed very attractive, I think the cost is too high. 2. It doesn't actually simplify things. Oh, in theory it does, but in practice, it's harder to debug because the document you're looking at isn't actually the one being styled. 3. That problem extends to the actual users as well, if something goes wrong, the error messages don't reflect the document that the user actually sent to the stylesheets. 4. I made a DB4 to DB5 conversion phase part of that normalization, and that makes the problems even worse (three phases, an even broader disconnect). So my initial plan is to look at breaking things down so that the processing is more direct. I'll probably keep the normalization phases around as separate stylesheets. I reserve the right to change my mind again when I get underway :-) Comments most welcome. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | It is a general error to imagine http://www.oasis-open.org/docbook/ | the loudest complainers for the Chair, DocBook Technical Committee | public to be the most anxious for | its welfare.--Edmund Burke, 1769 pgp5BNJoV5GYz.pgp Description: PGP signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
Camille Bégnis cami...@neodoc.biz writes: My opinion on the subject is that we should try listing the cases (like /section/info/title) why the first step is required. And then see if the schema could not be simplified to make that first step unnecessary. I haven't reviewed all the things that normalization does recently, but the info/title case arises from a desire to make life easier for authors. If all you need on a section is a title (and/or subtitle and titleabbrev), being required to put in the info wrapper is a burden that I don't think authors would appreciate. But if you want title, pubdate, author, copyright, etc. then you do have to put in the info wrapper. At least in DocBook V5.0, you can only have the title in one place or the other. In earlier versions of DocBook, it was schema-valid to have multiple titles (that might not necessarily be the same). I have found that this kind of choice is often confusing for the end user (the writer). Notwithstanding the processing issues. You can very well decide to process differently /section/info/title and /section/title while they are theoretically the same thing according to the schema... You could decide that, but it would be wrong :-) Be seeing you, norm -- Norman Walsh n...@nwalsh.com | The human race consists of the http://www.oasis-open.org/docbook/ | dangerously insane and such as are Chair, DocBook Technical Committee | not.--Mark Twain pgpE3MyI8qusV.pgp Description: PGP signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
David Cramer dcra...@motive.com writes: And where the duplication can't be eliminated, the list would indicate the things you should consider eliminating from your local version of DocBook. For example, you would typically pick one of: * section/title or section/info/title I don't agree. I think that one's just fine the way it is. * recursive sections or sect1/sect2/sect3 Yeah, it probably makes sense to pick one of those. 1) Making a subset is very encouraged, though not required and 2) When you make your subset, a) eliminate one or the other of certain alternative legal ways of doing things to simplify things for your writers (then provide the list) b) eliminate elements you don't plan to use (or hide them in the editor, if your editor supports that) Sure, but I'm not sure how to make that advice very concrete given that every customization is likely to be pretty unique. I could even imagine a little DocBook subsetting tool where you make a few choices and then list some inlines you'll never use. Yes, something like what the TEI folks call the Pizza Chef, http://www.tei-c.org/pizza.html, would be handy. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | We ought not to heap reproaches on http://www.oasis-open.org/docbook/ | old age, seeing that we all hope Chair, DocBook Technical Committee | to reach it.-- Bion pgpVlTWnLAGJM.pgp Description: PGP signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
Jirka Kosek ji...@kosek.cz writes: 1. It's very expensive. The entire document gets processed at least twice. While the idea of simplifying the downstream design seemed very attractive, I think the cost is too high. I think that multiple passes over document are necessary anyway -- I think that profiling should be default in XSLT 2.0 stylesheets. Also I'm now working on transclusions use-cases document for DocBook TC and in DocBook specific transclusion mechanisms is emerging in my head. This means another pass over the document. I agree that it should be possible to do all those things, and that they should be easy. I'm not sure I agree that they should all always happen whenever you process a document. In an, *ahem*, database context, for example, I can imagine wanting to factor some of those processes in different ways. :-) I'm not sure whether normalization was good or bad, but I think that its processing burden is not so high compared to stylesheets load time. Yeah. Maybe. In some contexts. :-) 4. I made a DB4 to DB5 conversion phase part of that normalization, and that makes the problems even worse (three phases, an even broader disconnect). What about not supporting DB4 in XSLT 2.0 stylesheets? It will simplify things and users can always run their own DB4-DB5 process before stylesheets are applied. Yes, I think that's probably the right answer. More generally, I think I want to decompose all the functionally separate phases. We might want to provide a stylesheet that does all the steps, but I (think I) also want the ability to apply the different phases at different times. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Ignorance is a precious commodity: http://www.oasis-open.org/docbook/ | once it's gone, you can't get it Chair, DocBook Technical Committee | back. pgptJsDCSieLu.pgp Description: PGP signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
Keith Fahlgren abdela...@gmail.com writes: Hi Norm, On Thu, May 27, 2010 at 4:59 AM, Norman Walsh n...@nwalsh.com wrote: I'm going to be turning my hands to the XSLT 2.0 stylesheets for DocBook again soon, partly with an eye towards making them more production ready, partly to try a few experiments. Thanks for clarifying that you'll be working on these stylesheets again, especially in light of Jirka's Google Summer of Code project. I think your ideas about dropping normalization, segmenting the stylesheets into discrete processing chunks rather than always creating a massive, unified stylesheet, and potentially not seamlessly handling DB4 are all prudent and justified. What I'd like to understand is your current thinking on the top three goals of the XSLT2 reimplementation itself. What are they? I've written about that a little bit, for example: http://norman.walsh.name/2004/07/27/titlepages but in terms of top three goals, I'd have to say: 1. Move to XSLT 2.0 techniques to both streamline and simplify the stylesheets but also to make them easier to customize and extend. 2. They've grown by accretion for a decade or so, it's time they got a little top-down refactoring and organization. 3. They should be better documented and there should be tests for everything. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Where it is permissible both to http://www.oasis-open.org/docbook/ | die and not to die, it is an abuse Chair, DocBook Technical Committee | of valour to die.-- Mencius pgpc4aGhhB3kU.pgp Description: PGP signature
[docbook-apps] Re: should simplesect be chunked?
Bob Stayton [EMAIL PROTECTED] writes: While reviewing a stylesheet bug, I also noticed that the simplesect element is not chunked. That seems odd to me, since a simplesect is a real section, except that it cannot have child sections. Does anyone see a problem with making simplesect into chunks? The important semantic distinction between simplesect and the other sectioning elements isn't merely that they're leaves, it's that *they never occur in the table of contents*. http://docbook.org/tdg5/en/html/simplesect#d0e205533 asideBleh, those sections need proper IDs./aside So, while I think arguments on the basis of size could go either way, and while it's also not entirely impossible to imagine chunks that are only available by navigating sequentially through them, the fact that they aren't in the ToC makes them poor candidates for chunk targets, IMHO. And that's almost certainly why I left them out originally. If you've got a long chapter that consists entirely of simplesects, I don't think you're helping your reader very much. If you're putting simplesects in the ToC, you're doing it wrong :-) Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | The First Amendment is often http://www.oasis-open.org/docbook/ | inconvenient. But that is besides Chair, DocBook Technical Committee | the point. Inconvenience does not | absolve the government of its | obligation to tolerate | speech.--Justice Anthony Kennedy, | in 91-155 pgpgzd8gyU60F.pgp Description: PGP signature
[docbook-apps] Re: Saxon 9
/ Mauritz Jeanson [EMAIL PROTECTED] was heard to say: | -Original Message- | From: Lillian Sullam | | I'm trying to use a XSLT 2.0 to translate C# XML to DocBook | XML. I use a Saxon processor and it doesn't seem to | recognize the XSLT xsl:result-document Does any one know | why this is happening? | | The subject line says Saxon 9. Are you sure you are using that version? | xsl:result-document is an XSLT 2.0 instruction, and it is undoubtedly | recognized by Saxon 9. Perhaps you forgot to say 'version=2.0' on your xsl:stylesheet element? Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | The belief in a supernatural http://www.oasis-open.org/docbook/ | source of evil is not necessary; Chair, DocBook Technical Committee | men alone are quite capable of | every wickedness.--Joseph Conrad pgpnnba8M0irE.pgp Description: PGP signature
[docbook-apps] Paragraph content model
/ Dave Pawson [EMAIL PROTECTED] was heard to say: | I wonder what the original reason was, unless it was M$ type of pressure | to have everything everywhere. See http://docbook.org/tdg5/en/html/para.html :-) But more helpfully, consider the following example: There are times when it may be necessary to frob the foobar. These can be summarized as follows: some table goes here where anything that falls outside the boundaries of column 1 must be considered an error. Logically, that's a single paragraph with a table in the middle. To mark that up as two paragraphs with a table in between fails to capture what the author intended. Years of struggling with HTML has mostly trained me not to write that way, or not to worry about the mangled markup that results from making that three sibling elements, but it's still a rational markup model. | I'm tempted to put an RFE in at sourceforge. I suspect you'll be disapointed. BTW, did you ever follow-up on the RFE that you did submit about change markup? I did reply to it. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | How can there be laughter, how can http://www.oasis-open.org/docbook/ | there be pleasure, when the world Chair, DocBook Technical Committee | is burning?--The Dhammapada | (probably 3rd century BC) pgpZHwQmo969k.pgp Description: PGP signature
[docbook-apps] Re: Request For Clarification: Indexterm processing in auto-index generation.
/ Dave Pawson [EMAIL PROTECTED] was heard to say: | Norman Walsh wrote: | I wonder if *both* would be a better compromise. | Using square brackets to indicate hot text, suppose there's one index | term in the section with section title, two in the section with | other section title, three in the section with third section title | and one again in the section with fourt title: | | Term, [section title], other section title, [1], [2], | third section title, [1], [2], [3], [fourth title] | | (Though, having proposed that, I'm not actually sure it can be achieved. | | Which to my way of thinking doesn't gel with the idea of linking | to the top of the section. That's the weakness IMHO. Ok, then maybe the answer is to just always use the numbers: Term, in section title, [1], in other section title, [1], [2], in third section title, [1], [2], [3], in fourth title [1] The section titles give the reader a clue about where the links occur, the numbers link to the actual spot where the indexterm occurs. Or maybe I should just get over it and go with simple numbers like the CSS example :-/ Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Some people can stay longer in an http://www.oasis-open.org/docbook/ | hour than others can in a week Chair, DocBook Technical Committee | pgpwHxniEyzzk.pgp Description: PGP signature
[docbook-apps] Re: Request For Clarification: Indexterm processing in auto-index generation.
/ Dave Pawson [EMAIL PROTECTED] was heard to say: | Bob Stayton wrote: | FrameMaker's online help index uses this format: | | cats [1] | dogs [1] [2] | | where the [1] is the hot text that takes you to the point | destination. All entries have [1], and any duplicates get more | numbers. It is pretty obvious that those are not page numbers. | | Just another suggestion. | | My basic point is that the author should identify duplicates | (perhaps from viewing the presented format) and do something about it. But that flies completely in the face of 500-or-so years of indexing tradition. Terms in an index identify concepts that may be discussed in several places in a document. In general, *the same concept* may be discussed in several places; in such cases, it would not only be an excruciating exercise for the author to differentiate them in some way, *it would be wrong*. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Whoever is abandoned by hope has http://www.oasis-open.org/docbook/ | also been abandoned by fear; this Chair, DocBook Technical Committee | is the meaning of the word | desperate.-- Schopenhauer pgp2bj7RYVJU7.pgp Description: PGP signature
[docbook-apps] Re: Draft watermark not working. No specific customization.
/ Keith Fahlgren [EMAIL PROTECTED] was heard to say: | On Sat, Mar 8, 2008 at 4:25 AM, spr [EMAIL PROTECTED] wrote: | I have a very basic customization - only to set the draft.mode to yes | (see attached). | ... | xsl:param name=draft.mode select=yes/ Almost all of the boolean parameters in the XSLT stylesheets use 0 and 1 for false and true, respectively. As bob explained later in the thread, select=yes matches yes elements in no namespace and, in DocBook at least, there aren't any. How $draft.mode slipped through expecting the values 'no' or 'yes' is beyond me. Bleh. Probably ought to fix that. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | It is as bad as you think. And http://www.oasis-open.org/docbook/ | they are out to get you. Chair, DocBook Technical Committee | pgpqTsJEybQeB.pgp Description: PGP signature pgpI9cjKw59Nf.pgp Description: PGP signature
[docbook-apps] FO processor support
As I work on porting the XSLT 1.0 stylesheets to XSLT 2.0, I find workarounds, mostly for FOP and PassiveTeX scattered throughout. Does anyone know if these are still necessary? Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Man is an intellectual animal, and http://www.oasis-open.org/docbook/ | therefore an everlasting Chair, DocBook Technical Committee | contradiction to himself. His | senses centre in himself, his | ideas reach to the ends of the | universe; so that he is torn to | pieces between the two, without a | possibility of its ever being | otherwise.-- Hazlitt pgpOOOAoh7ejy.pgp Description: PGP signature pgpj14yZLthdY.pgp Description: PGP signature
[docbook-apps] Re: Request For Clarification: Indexterm processing in auto-index generation.
/ Stefan Seefeld [EMAIL PROTECTED] was heard to say: | earlier this year I asked about the expected and 'correct' behavior | for index generation in HTML and pdf, as I found (find) the current | behavior surprising. [...] | I still find these two texts to contradict each other. I do find the | suggested processing expectation from TDG much more intuitive than the | one explained in DocBook XSL: The Complete Guide. | | At least, I'd appreciate if those two texts could be made to agree on | what the expected processing should be like. :-) DocBook: The Definitive Guide is normative with respect to the processing expectations. The HTML stylesheets simply don't satisfy those expectations. If you can think of a way to present the index in HTML that more closely matches the expectations, I'd be happy to implement it. The screw case is this one: section xml:id=foo titleSome section title/title para.../para paraindexterm xml:id=foo.idxprimaryFoo/primary/indexterm.../para para.../para !-- 35 more paras -- para.../para paraindexterm xml:id=foo2.idxprimaryFoo/primary/indexterm.../para /section In the index, that's currently presented as: F Foo, _Some section title_ where both terms have been collapsed into one. Representing both links with the same section title F Foo, _Some section title_, _Some section title_ seems hopelessly confusing and would lead to nearly illegible indexes. Likewise, using pseudo-page numbers: F Foo, _1_, _2_ is misleading because readers have been conditioned to think of those as page numbers. A 1 under Foo should be the same place as a 1 under Bar which simply won't be the case. I suppose they could be numbered sequentially throughout the document, but that'd be misleading too. Though maybe less so. At least 14 and 15 would be near each other in the text and 14 and 352 wouldn't be. Anyway, linking to the right place isn't hard, it's finding appropriate link text for the index that's hard. Suggestions welcome. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | The finest amusements are the most http://nwalsh.com/| pointless ones.--Jacques Chardonne pgpZRzj7fto8b.pgp Description: PGP signature
[docbook-apps] Re: Request For Clarification: Indexterm processing in auto-index generation.
/ Tony Graham [EMAIL PROTECTED] was heard to say: | On Wed, Mar 12 2008 12:18:29 +, [EMAIL PROTECTED] wrote: | ... | Likewise, using pseudo-page numbers: | | F | | Foo, _1_, _2_ | | is misleading because readers have been conditioned to think of those as | page numbers. A 1 under Foo should be the same place as a 1 under | Bar which simply won't be the case. | | FWIW, I think that scheme works okay in the CSS2 index at | http://www.w3.org/TR/1998/REC-CSS2/indexlist.html Bleh. I think it looks ridiculous. But if the world disagrees with me, I won't stand in its way. I probably will give the number all index terms sequentially format a whirl when I have a chance. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | When dealing with the insane, the http://www.oasis-open.org/docbook/ | best method is to pretend to be Chair, DocBook Technical Committee | sane.--Hermann Hesse pgpudhTV3cqzf.pgp Description: PGP signature
[docbook-apps] Re: Request For Clarification: Indexterm processing in auto-index generation.
/ Dave Pawson [EMAIL PROTECTED] was heard to say: | Suggest putting the responsibility on the author? | If they choose to use | primaryFoo/primary then that is exactly what they'll get? I don't follow. Foo is the index term, that's what appears in the index: Index ... F Fable, ... Fanciful, ... Foo, ... The question is, what should go in place of ... in the HTML case. | Norm, you haven't commented on the fo case? The FO stylesheets do the right thing, using page numbers and collapsing multiple references to the same page into a single reference. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | There has never been a perfect http://nwalsh.com/| government, because men have passions; | and if they did not have passions, | there would be no need for | government.-- Voltaire pgpdY58NqXBXh.pgp Description: PGP signature
[docbook-apps] Re: FO processor support
/ [EMAIL PROTECTED] was heard to say: | Are you (or is somebody else) going to port the slides stylesheets | also? This would be greatly appreciated over here :-). Yes. Eventually. I've probably done the HTML ones, the FO ones will have to wait until the FO stylesheets more-or-less work. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Old and young, we are all on our http://www.oasis-open.org/docbook/ | last cruise.--Robert Louis Chair, DocBook Technical Committee | Stevenson pgpZghiJOGyJF.pgp Description: PGP signature
[docbook-apps] Re: DocBook XSL*2* stylesheet reorganization
/ Norman Walsh [EMAIL PROTECTED] was heard to say: | Fair warning to those of you living on the bleeding edge. Ok. So I reconsidered a bit and didn't end up going the named-template route after all. But I did change things around. Here's the new idiom for XSLT2 customization layers: ?xml version=1.0 encoding=utf-8? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:db=http://docbook.org/ns/docbook; xmlns:f=http://docbook.org/xslt/ns/extension; exclude-result-prefixes=xs db f version=2.0 xsl:import href=/path/to/base/format/docbook.xsl/ xsl:template match=/ !-- You must do this or the stylesheets won't work -- xsl:variable name=normalized as=document-node() select=f:cleanup-docbook(/)/ !-- This checks that the root is a valid root. There's a two-argument form that takes an ID. It will return the node with that ID. -- xsl:variable name=root as=element() select=f:docbook-root-element($normalized)/ xsl:apply-templates select=$root/ /xsl:template /xsl:stylesheet Checking in now. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | What is familiar is what we are http://www.oasis-open.org/docbook/ | used to; and what we are used to Chair, DocBook Technical Committee | is most difficult to 'Know'--that | is, to see as a problem; that is, | to see as strange, as distant, as | 'outside us'.-- Nietzsche pgpZMXTz42I5c.pgp Description: PGP signature
[docbook-apps] Re: DocBook XSL*2* stylesheet reorganization
/ Florent Georges [EMAIL PROTECTED] was heard to say: | Norman Walsh wrote: | | / Norman Walsh [EMAIL PROTECTED] was heard to say: | | Fair warning to those of you living on the bleeding edge. | | Here's the new idiom for XSLT2 customization layers: | | If you put this template rule in common/docbook.xsl, the | customization layer can either override template rules for precise | elements or override this template rule (matching /) if he wants to | make something more complicated that needs to take control over the | overall processing. | | So the default rule for / launches the machinery as it should be, | and if one wants to override the rule for / in the cust. layer, he | will need to call the top-level functions (as in your email). | | Sounds more intuitive, doesn't it? Right. Basically, I took your advice (from the comment) and didn't go with the whole named template thing. So I think it's exactly as you say. If you don't want to override the root, then you just import docbook.xsl and off you go. In the unlikely event that you do want to override /, you can, provided you do the couple of things I suggested. Or do I missunderstand your question? Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Where it is permissible both to die and http://nwalsh.com/| not to die, it is an abuse of valour to | die.-- Mencius pgp5gmbBQ7px7.pgp Description: PGP signature
[docbook-apps] DocBook XSL*2* stylesheet reorganization
For a little background, see http://norman.walsh.name/2008/01/01/docbookStylesheets Basically, I've had a few weeks to live with my named-template approach and it seems to be working. I've also fixed a few other bugs related to table and verbatim processing. Sometime in the next few days, I'm going to merge my xsl2-namedt branch back into the trunk and commit it. When I do, anyone using the XSL2 stylesheets is going to have to tweak their build scripts and perform a little surgery on their customization layers. Fair warning to those of you living on the bleeding edge. This has *no* impact on the production versions of the XSLT *1.0* stylesheets at all. This is just about the pre-alpha XSLT 2.0 stylesheets. If you have no idea what I'm talking about, you can ignore this message :-) Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | To what excesses will men not go http://www.oasis-open.org/docbook/ | for the sake of a religion in Chair, DocBook Technical Committee | which they believe so little and | which they practice so | imperfectly!--La Bruyère pgpJXuifRjFbe.pgp Description: PGP signature
[docbook-apps] The XSLT 2 stylesheets
As I went digging through the XSLT 2 stylesheets again this morning, after a reasonable absence, I became more and more convinced that they're a mess architecturally. It all works in its own clever way, but the fact that overriding the root template involves deducing that you actually have to override xsl:template match=* mode=m:root strikes me as setting the bar awfully high for your average customizer. Doubly so when you consider that overriding / causes the whole edifice to fall over. I'm tempted, with an eye towards an XProc-aware future, to rip it all apart and rewrite it as an explicit sequence of discrete transformations instead of a mode-driven, internal sequence of transformations. Thoughts? Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | A man can believe a considerable http://www.oasis-open.org/docbook/ | deal of rubbish, and yet go about Chair, DocBook Technical Committee | his daily work in a rational and | cheerful manner.--Norman Douglas pgpRowwHOHnjK.pgp Description: PGP signature
DOCBOOK-APPS: Re: access key customization for TOC entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / ed nixon [EMAIL PROTECTED] was heard to say: | I'm just starting to think about a customization to sdbk to html that | would put an accesskey attribute pair into the toc entries generated | by the xsl stylesheets. Admittedly, I haven't studied the stylesheets | in depth at this point, but will be doing so over the next few days. The tricky bit, I think, is going to be figuring out how to tell the stylesheets which access key to assign to each tocentry. You'll probably need some customization to allow the author to indicate it. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | certain: adj., insufficiently http://www.oasis-open.org/docbook/ | analyzed Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+c44mOyltUcwYWjsRAlrFAKCpHAsJgdQwlpxl0FmsQV4re6YLhQCbBoOW 8+eZdA+1ut1PmEDGvI4soEo= =j4Qy -END PGP SIGNATURE-
DOCBOOK-APPS: Re: no wonder i'm confused about the node() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Bob Stayton [EMAIL PROTECTED] was heard to say: | On Sun, Mar 02, 2003 at 03:01:32PM -0500, Robert P. J. Day wrote: | | XSLT, Doug Tidwell, p. 51 | | * The node() node test, which selects all nodes in the current | context, regardless of type. This includes elements, text, comments | processing instuctions, attributes, and namespace nodes. | | XSLT Programmer's Reference, 2nd ed., Michael Kay, p. 432 | | Since root nodes, attribute nodes and namespace nodes are never | children of another node ... they will never be matched by the | pattern node(). | | http://www.w3.org/TR/xslt; | | * node() matches any node other than an attribute node and | the root node | | | | at this point, i'm scared to read anything else for the fear | of getting a *fourth* opinion. | | Ask Norm. He helped write the XSLT Recommendation.[1] Heh. Thanks, Bob :-) With respect to the opinions above, I believe Tidwell is mistaken, Kay is correct, and the quoted part of the XSLT Rec is needs an erratum to add namespace node to that description of node(). On the other hand, that quote comes under the heading here are some examples of patterns so maybe it's not normative. The place to look for information about node() is the XPath Rec which says a node test node() is true for any node of any type whatsoever. But I think part of the confusion in this thread is that there are two things to consider: the test and the axis in which the test is performed. In particular, there's no test that you can write xsl:template match=node() ^^ here to match an attribute or namespace node. That's just not the way that template rules are matched. Now, if you use node() with other axes, then it matches every kind of node (though note that most axes don't match namespace or attribute nodes, so it isn't the case that you get them with node()). Going all the way back to the original question, should this template xsl:template match=node() match comments and processing-instructions? I can't find any reading of the XSLT Rec that would support the answer no. In particular, consider: The built-in template rules are treated as if they were imported implicitly before the stylesheet and so have lower import precedence than all other template rules. Thus, the author can override a built-in template rule by including an explicit template rule. Since import precedence is the primary discriminator for template matching, I think the test above should match comment and processing instruction nodes. So I think it's an xsltproc bug that they don't. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Unprovided with original learning, http://www.oasis-open.org/docbook/ | unformed in the habits of Chair, DocBook Technical Committee | thinking, unskilled in the arts of | composition, I resolved to write a | book.--Edward Gibbon -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+c5O4OyltUcwYWjsRAkurAJ4vIaF5UZi2bhpTN8fmI9uC7yGgmQCeNq7t DCYpyqXR0ich86S5+uSdGTY= =ZSqu -END PGP SIGNATURE-
DOCBOOK-APPS: Re: AW: Re: Problems with ANT and DocBook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Daniel S. Haischt [EMAIL PROTECTED] was heard to say: | the ant style/xslt task did not work out for me too, because the task | did not used the explicitely specified classpath - or at least i | had the feeling that the classpath wont be used. There are directives in ant to fix that, no? Hmm. I haven't tried myself, so maybe I should just keep quiet :-) Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Wisdom comes with age, but http://www.oasis-open.org/docbook/ | sometimes age comes alone. Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+c5U5OyltUcwYWjsRAnklAJ43XalVU3ZQmseEHAaBw3/FKo6tvQCfQdZa 1CbTumWrLPLzYW7CQDoY+xM= =i4v9 -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Context dependent styling of footnotes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / [EMAIL PROTECTED] was heard to say: | I wanted to ask if Fop is really to blame for this, since by reading | Dave Pawson's book on XSL-FO on page 27 he sais that footnotes do | inherit properties from the content in which they occur. If this is | the case, is it possible to correct this problem in the distribution? Seems reasonable to me. Done in CVS. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | A man's dying is more the survivors' http://nwalsh.com/| affair than his own.--Thomas Mann -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+b5WlOyltUcwYWjsRAjXtAKCw0AWO6dXo/iqmY3/WXSXAdq9NVgCfYxsE myXmgneORl/EoVi6uuvbQos= =+c5l -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Chunked HTML file names too long for ISO9660
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Steinar Bang [EMAIL PROTECTED] was heard to say: | Yesterday I discovered that when I inserted a CDROM containing a | chunked HTML document on a Win2k machine, I found some of the pages | missing. The reason was that the file names were too long. I have | use.id.as.filename, and some of my IDs were too long. | | I'm changing the troublesome IDs now, but is there some way to fix | this automatically? Either shorten the filenames and links to the | files when generating the chunked HTML, or generate warnings/errors? Do you need the ID-based filenames? Would the automatically generated names not be ok? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | The wonder is, not that the field http://www.oasis-open.org/docbook/ | of stars is so vast, but that man Chair, DocBook Technical Committee | has measured it.--Anatole France -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+b9RpOyltUcwYWjsRAvK+AJ0R3k/fPqZuo39F0ogNMROrHA8NxACgj14Q s+F6QtkO8y1h2M1ovY9HDsg= =Gv/9 -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Top border lacking on repeated table headers with xep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's been a month or so, has there been any follow-up on this? Do I need to add some more properties to the stylesheets? / David Cramer [EMAIL PROTECTED] was heard to say: | Ok, that make sense, but when I add border-top-width.conditionality=retain or border-before-width.conditionality=retain to the fo:table, nothing changes (the top border of the running headers are still not there in the pdf): | | fo:table margin-left=0pt margin-right=0pt border-collapse=collapse border-top-width.conditionality=retain border-left-style=solid border-right-style=solid border-top-style=solid border-bottom-style=solid border-left-width=0.5pt border-right-width=0.5pt border-top-width=0.5pt border-bottom-width=0.5pt border-left-color=black border-right-color=black border-top-color=black border-bottom-color=black width=100% | | David | | -Original Message- | From: David Tolpin [mailto:[EMAIL PROTECTED] | Sent: Thursday, February 06, 2003 2:17 AM | To: [EMAIL PROTECTED] | Subject: Re: DOCBOOK-APPS: Top border lacking on repeated | table headers | with xep | | | | XEP (2.x at least) for some reason doesn't put a border | declared in fo:table | on running headers. So even tho you have frame=all on | your docbook table | and rowseps=1 elsewhere, you still end up with this in | your output: | | David, | | I'll post your messages sent to xep-support (they have been | bounced since sent not from a subscribed | address), but the problem is not with XEP but with the | stylesheets, and XEP's behaviour is | compliant. | | border-*.conditionality is discard by default. That's why | table borders are not drawn | at the top and bottom of the intermediate chunks. If one | want's the top border to be | drawn always, border-before.conditionality=retain must be specified. | | David | | | Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Endurance is frequently a form of http://www.oasis-open.org/docbook/ | indecision.--Elizabeth Bibesco Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+b9QLOyltUcwYWjsRAha5AJ94ILLPh2iHkrsW5r5u2AtEtTwEcACfXcau HFjKvPrI232VGSh1d3NdiMI= =MLjS -END PGP SIGNATURE-
DOCBOOK-APPS: Re: FOP: boomarks don't work well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Tobias Reif [EMAIL PROTECTED] was heard to say: | Can you also offer a fix for | http://lists.oasis-open.org/archives/docbook-apps/200302/msg00056.html | ? Other FO2PDF converters displayed the list. I thought I'd fixed that recently. Does it work with the latest? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | If you run after wit you will http://www.oasis-open.org/docbook/ | succeed in catching Chair, DocBook Technical Committee | folly.--Montesquieu -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+WQxpOyltUcwYWjsRAlBiAJ9/yt7TUw8ebmO6+0NwLHaYfJDzdACggmDv 3/3guQEkMxfb42cU/Vf6PMs= =EDrY -END PGP SIGNATURE-
DOCBOOK-APPS: Re: FOP: boomarks don't work well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Tobias Reif [EMAIL PROTECTED] was heard to say:
| Marko Petersen wrote:
|
| Same for me, I fixed that the following way:
| In glossary/component/division/index.xsl and so on, search for
| titlepage. And if you find something like
| fo:flow flow-name=xsl-region-body
| xsl:call-template name=dedication.titlepage/
| /fo:flow
| add a fo:block with the id to reference:
| fo:flow flow-name=xsl-region-body
| fo:block id={$id}
| xsl:call-template name=dedication.titlepage/
| /fo:block
| /fo:flow
| And not only for dedication, for every component you need...
|
| Thanks a lot for the tip.
|
| Instead of editing the NW-DBK2FO-XSLTs themselves, I'd override the
| relevant templates by copying them to my customization layer and
| editing them there.
|
| Bob or Norm:
|
| Or is it something that could be turned on with
|s:param name=fop.extensions select=1/
| ?
Didn't I fix this recently? I thought I did, but I have been on vacation :-)
Be seeing you,
norm
- --
Norman Walsh [EMAIL PROTECTED] | It is a general error to imagine
http://www.oasis-open.org/docbook/ | the loudest complainers for the
Chair, DocBook Technical Committee | public to be the most anxious for
| its welfare.--Edmund Burke, 1769
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/
iD8DBQE+WQ0UOyltUcwYWjsRAtFvAKCrSyu7kck4MubIZyT6OfCo0Km4YQCfVwQh
t+G9C6+YBY8O2C/TyRHbZZA=
=g7Yq
-END PGP SIGNATURE-
DOCBOOK-APPS: Re: What's the most appropriate (and futureproof) way tostyle the FO?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Bob Stayton [EMAIL PROTECTED] was heard to say: | Is the purpose of the titlepage mechanism to supersede and obsolete the | property set option params, or are both mechansims intended to be combined? | | Norm might want to answer this too, but | I believe the mechanisms are meant to be combined, in | a hierarchical manner. The titlepage.templates | mechanism establishes the default values, and the | propery attribute-sets provide the runtime flexibility. Right. | I can't say how 'futureproof these various mechanisms are. | It kind of seems like there are too many places | to set properties, but I believe some of that is the result of | stylesheet evolution, rather than by design. | So perhaps these will be consolidated a bit in the future. Yes, I think a little bit of conscious redesign is in order. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Be indiscrete. Do it continuously. http://www.oasis-open.org/docbook/ | Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+WQ38OyltUcwYWjsRAsvbAJ0WkLSmyF+FqQP12KoCCoUO4waWdwCdFZM4 KCVjGNyccC0jlMa6MDUdW6U= =O+LI -END PGP SIGNATURE-
DOCBOOK-APPS: Announce: Website 2.4.1 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No major problems were reported against 2.4.0, so 2.4.1 is officially out. Changes since version 2.3 (2002-09-17) Changes to website/* | 2003-02-18 Norman Walsh [EMAIL PROTECTED] | | * VERSION: Version 2.4.1 released. | | * catalog.xml: Added rewrite rules for the schema and xsl | directories | | * catalog.xml: Added chunk-common to the catalog | | 2003-01-25 Norman Walsh [EMAIL PROTECTED] | | * Makefile: Cleanup and support reorganized directories | | * README: Updated versions, copyright, and system identifiers | | * VERSION: Version 2.4.0 released. | | * catalog.xml: Fixed typos | | 2003-01-16 Norman Walsh [EMAIL PROTECTED] | | * autolayout.dtd, catalog.xml, extensions.mod, forms.mod, | layout.dtd, namespaces.mod, rddl.mod, website-custom.dtd, | website-full.dtd, website.mod: Moved files; this messes up | the CVS tags, but I'm doing it anyway :-( | | * website-custom.dtd: Based on Simplified 1.0 | | 2003-01-12 Robert Stayton [EMAIL PROTECTED] | | * catalog.xml: New file. | | 2002-11-17 Norman Walsh [EMAIL PROTECTED] | | * VERSION, autolayout.dtd, extensions.mod, forms.mod, | layout.dtd, namespaces.mod, rddl.mod, website-custom.dtd, | website-full.dtd, website.mod: Bug #636004: fix version | numbers | | 2002-10-16 Norman Walsh [EMAIL PROTECTED] | | * website-custom.dtd: Fix typos in comments; correct spelling | of qand_a_set PEs; add blockinfo for qandaset | | * website-full.dtd: Fix typos in comments | | 2002-10-02 Norman Walsh [EMAIL PROTECTED] | | * autolayout.dtd, layout.dtd, website.mod: Add headlink | element (HTML head 'link') | Changes to website/example/* | 2003-02-18 Norman Walsh [EMAIL PROTECTED] | | * layout.xml: Moved revisionflag | | 2003-01-25 Norman Walsh [EMAIL PROTECTED] | | * catalog.xml: New file. | | 2003-01-24 Norman Walsh [EMAIL PROTECTED] | | * Makefile: Use Saxon instead of xsltproc because the warnings | about realtive namespace URIs bug me | | 2003-01-16 Norman Walsh [EMAIL PROTECTED] | | * about.xml, build-ext.xml, build-make.xml, | build-textonly.xml, building.xml, custom.xml, full.xml, | layout.xml, olink.xml, param.xml, php.xml, rddl.xml, | revflag.xml, rss.xml, test1.xml, test1a.xml, test1b.xml, | test2.xml, test3.xml, website.xml, wslayout.xml: Updated DTD | URIs | | 2003-01-12 Robert Stayton [EMAIL PROTECTED] | | * build-ext.xml: Added para about using a processor that lacks | extension functions. | | * build-make.xml: Corrections to Makefile listing. | | 2002-10-02 Norman Walsh [EMAIL PROTECTED] | | * build-make.xml, layout.xml: Add global headlink and local | headlink | Changes to website/xsl/* | 2003-02-18 Norman Walsh [EMAIL PROTECTED] | | * autolayout.xsl: Updated version numbers to 2.4.1 | | 2003-02-16 Norman Walsh [EMAIL PROTECTED] | | * rss.xsl: Check for localTime function before calling it | | 2003-01-26 Robert Stayton [EMAIL PROTECTED] | | * chunk-common.xsl: No longer terminates if exists() function | not available. Will not track dependencies, so all files | built each time. | | 2003-01-16 Norman Walsh [EMAIL PROTECTED] | | * autolayout.xsl: Update the public and system identifers | | 2003-01-11 Robert Stayton [EMAIL PROTECTED] | | * makefile-dep.xsl: Add optional output-root param so | dependency path matches the output path. | | 2002-11-17 Norman Walsh [EMAIL PROTECTED] | | * website-common.xsl: Patch #540597: add rcsdate.format named | template | | 2002-10-02 Norman Walsh [EMAIL PROTECTED] | | * autolayout.xsl, head.xsl: Support headlink element | | * chunk-common.xsl: Support references to external pages when | using XSLT exists() function to choose build order | Changes to website/tests/* | 2002-10-16 Norman Walsh [EMAIL PROTECTED] | | * test.xml, testfull.xml: Added XML declarations | Changes to website/schema/* | 2003-01-25 Norman Walsh [EMAIL PROTECTED] | | * Makefile: New file. | Changes to website/schema/relaxng/* | 2003-02-18 Norman Walsh [EMAIL PROTECTED] | | * autolayout.rng, extensions.rng, forms.rng, layout.rng, | rddl.rng, website-full.rng, website.rng: Updated version | numbers to 2.4.1 | | 2003-01-23 Norman Walsh [EMAIL PROTECTED] | | * .cvsignore: Ignore websitedb.rng | | * .cvsignore, Makefile: Updated | | * config.xml: Generated | | * config.xml, union.xml: Changed configuration strategy | | * extensions.rng, forms.rng
DOCBOOK-APPS: Re: xref to image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Follow-ups to docbook-apps, please] / Daniel Moellenbeck [EMAIL PROTECTED] was heard to say: | i do a xref to the figure with xref linkend=fg-template /. | In my convertet pdf document i get Abbildung 1.1 Template-Engine | with a link to my image. How can i format this xref-link, that the | link is only Abbildung 1.1? You need to change the cross-reference template for figures. Bob's got it covered beautifully: http://www.sagehill.net/xml/docbookxsl/CustomMethods.html#CustomGentext Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Logical consequences are the http://www.oasis-open.org/docbook/ | scarecrows of fools and the Chair, DocBook Technical Committee | beacons of wise men.--Thomas Henry | Huxley -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVnFOyltUcwYWjsRAteRAKClRpPSh1MrbeexfVA+gTYMD+Q9qACglLjc cK4pJBQcozqOqUOX19FSrzI= =pxQt -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Additional XEP extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Paul A. Hoadley [EMAIL PROTECTED] was heard to say: | I can file an RFE at SourceForge if anyone else thinks this is useful, | though my current approach is fairly crude. Please file this as a patch or enhancement and I'll get it into the distro asap. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | A lie is an abomination unto the http://www.oasis-open.org/docbook/ | Lord and a very present help in Chair, DocBook Technical Committee | time of trouble.--Adlai Stevenson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVqLOyltUcwYWjsRAnzjAJ4k9lLl+6fo0N3SpjTIOZYa9N4jgwCdE5rE HfR5CQMOiAMPjszDRx0KrgQ= =zXqX -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Open ebook conversions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Bill Lawrence [EMAIL PROTECTED] was heard to say: | Does anyone know of existing conversion scripts to transform Docbook | into Open eBook? No. Open eBook is a subset of XHTML, right? The XHTML stylesheets will probably get you most of the way there. If you have suggestions for improvements, please let us know. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | When we reduce our own liberties http://www.oasis-open.org/docbook/ | to stop terrorism, the terrorists Chair, DocBook Technical Committee | have already won.--Reverius -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVsIOyltUcwYWjsRAvm1AJ4h8A1hLjY8/7cKtQMwjgB3ZJqi5QCfSTy5 AnCY1PjFXANL+bCE6wzBY68= =T64g -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Website and catalog.xml from distro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Vitaly Ostanin [EMAIL PROTECTED] was heard to say: | I'm use website-2.4.0 and original catalog.xml from distribution | and have some questions: | | 1. | It's possible to make long names for resolving location of XSL | styles ? | | uri name=autolayout.xsl | uri=autolayout.xsl/ I'm not sure I understand what you mean. | Name from this example may be not uniq and this not worked for | import styles by full URL: | http://docbook.sourceforge.net/release/website/2.4.0/xsl/autolayout.xsl Right. I probably do need to make sure the full release URIs are in there. | BTW, | http://docbook.sourceforge.net/release/website/current | points to old website version. The current version never points to x.y.0 releases. Snapshot should, but I may have forgotten to do that. | 2. | In catalog.xml missing chunk-common.xsl - it can be used for | customization layers (for example, for my :)) Thanks. | 3 (offtopic :)). | Can XSL styles have a PUBLIC id ? Sigh. No. Though the urn:publicid: scheme could be used, it'd break for everyone not using a catalog. Yes, I kick myself for not getting this fixed in XSLT 1.0. Kick, kick, kick, ... Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Sarchasm: The gulf between the http://www.oasis-open.org/docbook/ | author of sarcastic wit and the Chair, DocBook Technical Committee | person who doesn't get it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVx5OyltUcwYWjsRAthDAJ9tSy61cU0/3v4i+/NiGu0Xfz7cPQCfcysL fKuSXHqZ5j2ryBix8FKfDgM= =9+/x -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Docbook xsl stylesheets and accessibilityrequirements?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Billard, Trish [EMAIL PROTECTED] was heard to say: [...] | Is there any documentation out there about how these transformations | meet or don't meet these requirements? I'll need to create | configurations or customizations to ensure the requriements are met. I'm not aware of any comprehensive studies, but I've tried to make sure the transformations are accessible. If you find cases where they aren't, I'll make sure it gets fixed promptly. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Science is like sex: sometimes http://www.oasis-open.org/docbook/ | something useful comes out, but Chair, DocBook Technical Committee | that is not the reason we are | doing it.--Richard Feynman -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVzdOyltUcwYWjsRArsVAJ9EWFEIFWQ8m/OPchXwsbjs14j8AgCfZGGV Aysi+1DUwMiQsPd99sBoTmA= =qhkd -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Docbook xsl stylesheets and accessibilityrequirements?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / [EMAIL PROTECTED] was heard to say: | A general question for folks. If one is stylesheet agnostic, would DSSSL or | XSL be a better choice for a start toward producing XHTML Strict? I was a | LISP hacker in a previous life, and so find DSSSL appealing. Sigh. The easiest way to get XHTML strict out of the stylesheets is almost certainly to run tidy. I appreciate that people would like to be able to get strict output from the stylesheets for arbitrary DocBook, but it would be very, very hard. However, if you exercise some control in your DocBook sources, it should be fairly easy to get strict XHTML. If you find otherwise, I'd be interested in seeing the examples. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | They that can give up essential http://www.oasis-open.org/docbook/ | liberty to obtain a little Chair, DocBook Technical Committee | temporary safety deserve neither | liberty nor safety.--Benjamin | Franklink -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UV2QOyltUcwYWjsRAgokAJ4kFCwdiAAChXer0QgGO7t5unrfnwCdHALj fuBy3cr/4MlxlZCfU8Hnqo4= =03Me -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Docbook xsl stylesheets and accessibilityrequirements?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Billard, Trish [EMAIL PROTECTED] was heard to say: | Wow, this started quite the thread. | But what I was really looking for is for the HTML (rather than the XHTML), what |things to meet accessibility requirements do Norm's stylesheets already provide? |Examples might be always supporting putting an alt attribute for all images, allowing |resizing of point sizes. That sort of thing. DocBook meets those requirements, I believe. Last time I reviewed the W3C XML Accessibility Guidelines, I thought DocBook passed. Dave Pawson might know better than I. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | There are only 10 types of people http://www.oasis-open.org/docbook/ | in this world: those who Chair, DocBook Technical Committee | understand binary and those who | don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UV3lOyltUcwYWjsRAvtgAJ978XeWNHYsHXAuk8m/kMvNTene1gCbBiIb LsOFGrZjq/qLzlZRHC6xGjI= =MQXV -END PGP SIGNATURE-
DOCBOOK-APPS: Re: XML catalog resolution problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | What is the reason for requiring EntityResolver to always return | fully resolved system IDs in the first place? Why did Norm lose | the argument? I'm not sure I can answer this question in a completely objective way. I think the answer boils down to this: the SAX folks made some decisions about their API in the V1 days and unfortunately no one noticed the places where the decisions they made were going to impact proper functioning of a resolver. Because SAX is very popular, and perhaps because they disagree that their API is broken, they are unwilling to change the public API. So if you're going to use SAX, you're stuck with a broken API. I'm hoping to move away from SAX and start using the Xerces Native Interface myself. XNI exposes all of the events that occur and will allow me to do some quite nice things (like profile at the parser level, normalize namespace prefixes, implement XInclude before DTD validation, etc.). Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | The common excuse of those who http://www.oasis-open.org/docbook/ | bring misfortune on others is that Chair, DocBook Technical Committee | they desire their | good.--Vauvenargues -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OnNROyltUcwYWjsRAqugAJ9BR3af4TrHrgnZxbjSnl4+PhdHIACeMbDQ AFPv47FNp+MT/imRN/svs0A= =9iUM -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Stylesheets 1.60.1 and FOP 0.20.4 or 0.20.5rc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Martin Perina [EMAIL PROTECTED] was heard to say:
| xsl:template match=part
| ...
| fo:flow flow-name=xsl-region-body
| fo:block id={$id}
| xsl:call-template name=part.titlepage/
| /fo:block
That seems perfectly reasonable. Thank you! I should have thought of
that. I've always resisted making the entire flow a single block
because of some issues with the constraints on spanning in FO. But
putting the titlepage, already in a block, in an other block seems
harmless and fixes the FOP issue.
Be seeing you,
norm
- --
Norman Walsh [EMAIL PROTECTED] | If today was a fish, I'd throw it
http://www.oasis-open.org/docbook/ | back in.
Chair, DocBook Technical Committee |
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/
iD8DBQE+OnUsOyltUcwYWjsRAu71AKCw6Q3u75CJOmFZ12iiU3q02e9nfQCgiDHh
/44XCfCeuiWsz560DLIKIAc=
=oKh3
-END PGP SIGNATURE-
DOCBOOK-APPS: DocBook Wiki is back up!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At http://docbook.org/wiki/ Sorry for the interruption in service. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Wisdom is only a comparative http://www.oasis-open.org/docbook/ | quality, it will not bear a single Chair, DocBook Technical Committee | definition.--Marquess of Halifax -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OoQwOyltUcwYWjsRAupRAJ4v4ulga4xVs68BEkKzFKkbkGH9tQCcCmao 9ga1g8xFkgs7rNETKMtg314= =S3YQ -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Citations from different sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Pablo Rodriguez [EMAIL PROTECTED] was heard to say: [...] | I think the easiest way to expose my questions is to write two | references with which I don't know how to tag. If anyone is so kind | to tag them for me (considering both contexts, footnotes and info). | Here they are: | | John Wayne, Understanding Cowboys in The MGM Review, 3/3 (2000), | http://www.mgm.com/3/3/wayneucb.html. | | John Wayne, Understanting Cowboys in John Ford (ed.), Western, MGM | Press, California 2001, pp. 342-435. I really don't know what you mean by in both contexts. I'm not even sure what your question is. | By the way, what happens when a given book has more than one editor? | (Wouldn't be an editorgroup tag very useful in such cases?) You can put multiple editors in an authorgroup. I suppose that tag should really have been named contributorgroup or something. | When handling with reference quotes, I think that one essential tag | is the one that gives the location of the quoted text (such as | pagenumber). Is there a tag for this? It would be very useful when | it could handle volume, section, paragraph, page, column and verse | numbers. Maybe not all appear on a particular reference, but I think | that these are the most important kinds of classes for locating | quotes. Again, I'm a bit confused. Can you provide a more concrete example of what you mean? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Our years, our debts, and our http://www.oasis-open.org/docbook/ | enemies are always more numerous Chair, DocBook Technical Committee | than we imagine.--Charles Nodier -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OoUDOyltUcwYWjsRAhOfAJ90c1RyHYenINYVyIhZaSslRj71MwCeJpWb TUXZ+YYTFs+5YHiux17/PC0= =rqvX -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Using inline.monoseq in FO (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / David Tolpin [EMAIL PROTECTED] was heard to say: | / Norman Walsh [EMAIL PROTECTED] was heard to say: | | Why is it a great problem? The result should be 90% of the paragraph | | size in the first case and 90% of the title size in the second. | | And on further inspection, it just looks awful. Setting the font size | on the basis of ems is just wrong. It really should be based on | relative ex heights and those aren't available. I think I'll abandon | the crude attempt to make monospaced fonts look a little more | aesthetically sized. | | font-size-adjust is just for this purpose, by the way. Assigning it a known | value will make symbols from different fonts look similar in size. Interesting. I'll have to play with that. It's probably the right answer, but it looks like one needs to know the aspect values of the actual fonts used, so it may be more appropriate for a customization layer where specific fonts are chosen. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | [They] say the Earth is flat, but http://www.oasis-open.org/docbook/ | I know that it is round, for I Chair, DocBook Technical Committee | have seen the shadow on the moon, | and I have more faith in a shadow | than in [them].--Ferdinand Magellan -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OoXUOyltUcwYWjsRAqwoAJ9jvZMtEtvrhXKxIT2bMBFlAvEe0QCeN3Dk twGg+bdgM5onkjtjiI/FkDs= =8ROy -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Bold cells in tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Steinar Bang [EMAIL PROTECTED] was heard to say: | But I'm clueless as how to handle getting Header1, Header2 | etc. into bold face. CALS tables don't support a notion of header columns. Your best choice is probably the rather kludgy: entryphrase role=boldHeader1/phrase/entry Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | There is no excellent beauty that http://www.oasis-open.org/docbook/ | hath not some strangeness in the Chair, DocBook Technical Committee | proportion.--Sir Francis Bacon -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OoZJOyltUcwYWjsRAsiOAKCwz5R+nOYoItT6TTAh64guM2EJCwCfZLNQ 5E0FG9wrlmXtrLkxe6eENrk= =DTMo -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Bold cells in tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Steinar Bang [EMAIL PROTECTED] was heard to say: | Steinar Bang [EMAIL PROTECTED]: | | Can the spanning header be done with multible tgroup elements? | Eg. something like this? | | table | tgroup | thead | entrySome text spanning multiple columns/entry | /thead | ... | /tgroup | tgroup | thead | entrySome more text spanning multiple columns/entry | /thead | ... | /tgroup | /table | | This looks like two separate tables stuck close together in HTML. Not | the look I was aiming for. No, but about all that can reasonably be achieved given the semantics of tgroup and HTML tables. (And FO tables for that matter.) Again, you're probably better off with the kludge: entry namest=c1 nameend=c6phrase role=bold.../phrase/entry | Also, the only way I found for both tgroup elements to have the same | value, was to set pgwide=1 on the table. Is there another way? I think there's a PI you can use. Uhm...?dbhtml table-width=...? or ?dbfo table-width=...? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | If you settle for what they're http://www.oasis-open.org/docbook/ | giving you, you deserve what you Chair, DocBook Technical Committee | get. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+Oo1lOyltUcwYWjsRAl/FAKCCOKHiDVkoh9OiOH4NF2Q+4Smh3ACfUtRa 9KxJ2SUdweWfP0IXYHm/C+I= =fNtD -END PGP SIGNATURE-
DOCBOOK-APPS: Re: FOP: margin-left and margin-right = 0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / ABX [EMAIL PROTECTED] was heard to say: | Norman Walsh [EMAIL PROTECTED]: | / ABX [EMAIL PROTECTED] was heard to say: | | xsl:param name=title.margin.left0cm/xsl:param | | | | and all mentioned warnings are no more generated. The problem is: when I added | | unit only for .left side why both sides as margin-left and margin-right | | were influenced ? Is everything fine in that matter ? | | Changing title.margin.left should only effect titles. Did it have | other effects? | | removing cm _only_ from above line causes following block in Fo output: | fo:block font-family=Arial margin-left=0 margin-right=0/ | adding cm back to the same line (no other changes) cause this block to be: | fo:block font-family=Arial margin-left=0cm margin-right=0cm/ | so as I understand setting for some left side affects right parameter in some | blocks. sorry I'm not experienced enough to track reasons in templates. Right you are. It's a bug in header.content.properties and footer.content.properties. Fixed in CVS. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Mankind are always happy for http://www.oasis-open.org/docbook/ | having been happy; so that if you Chair, DocBook Technical Committee | make them happy now, you make them | happy twenty years hence by the | memory of it.--Sydney Smith -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OpCYOyltUcwYWjsRAl7aAKCc/wjLu0PZ51BtAdcY4Tw5dowOXgCfYM59 8eum4Ow3bM8+H3UkWyyMvVc= =SGlz -END PGP SIGNATURE-
DOCBOOK-APPS: Re: XSL 1.60.1 Revisionhistory fix for FOP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Togan Muftuoglu [EMAIL PROTECTED] was heard to say: | Hi | | With the 1.60.1 release of the Docbook XSL Stylesheets FOP works better | with the proportional-column-width() However revhistory is using tables | and fo/block.xsl needs to be changed as well. I have added the necessary | template to the project page | | |http://sourceforge.net/tracker/index.php?func=detailaid=678100group_id=21935atid=373749 | | and the template should look like as follows Fixed in CVS. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | It is necessary to try to surpass http://www.oasis-open.org/docbook/ | oneself always; this occupation Chair, DocBook Technical Committee | ought to last as long as | life.--Christina, Queen of Sweden -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OpLcOyltUcwYWjsRAhgsAKCIp2j36SazAlUVIffivaEuL+VUTQCeNQs8 ztE04qy0NHL42R8do9/av+o= =AXFi -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Did Xalan extensions work with 2.4.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jirka Kosek [EMAIL PROTECTED] was heard to say: | Hi, | | I was playing with Xalan 2.4.1. If I enable usage of extensions | (xalan2.jar) I'm getting following error message: | | (Location of error unknown)XSLT Error | (javax.xml.transform.TransformerException) | : java.lang.RuntimeException: Programmer assertion is incorrect! - Can | not get a | DTM Unless a DTMManager has been set! | | and Xalan stops. Error message is invoked when there is a text insertion | in DocBook document. Is it known bug, or some problem in my setup? Any | hint from Xalan users. Sounds like the Xalan folks have changed their APIs. Sigh. I won't have a chance to investigate until after I get back from vacation. (10 Feb 2003) Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Do not try to live forever. You http://www.oasis-open.org/docbook/ | will not succeed.--George Bernard Chair, DocBook Technical Committee | Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OpMdOyltUcwYWjsRAhsFAJ4rnkB3Ukcx3A8u2goR4s4xApMBjACfddDM 9V896f2+8XLgL2o8BvUEHPU= =6bN+ -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Using inline.monoseq in FO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Norman Walsh [EMAIL PROTECTED] was heard to say: | Why is it a great problem? The result should be 90% of the paragraph | size in the first case and 90% of the title size in the second. And on further inspection, it just looks awful. Setting the font size on the basis of ems is just wrong. It really should be based on relative ex heights and those aren't available. I think I'll abandon the crude attempt to make monospaced fonts look a little more aesthetically sized. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | No man is more than another if he http://www.oasis-open.org/docbook/ | does no more than Chair, DocBook Technical Committee | another.--Cervantes -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+N9ZxOyltUcwYWjsRAuzQAJ4+WptpukG1mT55yzZG2+K1H8uCbQCfUvmK ESqchAqD3z07FGlgxe/XaTY= =HRYu -END PGP SIGNATURE-
DOCBOOK-APPS: Re: FOP: margin-left and margin-right = 0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / ABX [EMAIL PROTECTED] was heard to say: | xsl:param name=title.margin.left0cm/xsl:param | | and all mentioned warnings are no more generated. The problem is: when I added | unit only for .left side why both sides as margin-left and margin-right | were influenced ? Is everything fine in that matter ? Changing title.margin.left should only effect titles. Did it have other effects? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | The Future is something which http://www.oasis-open.org/docbook/ | everyone reaches at the rate of Chair, DocBook Technical Committee | sixty minutes an hour, whatever he | does, whoever he is.--C. S. Lewis -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OAUTOyltUcwYWjsRAmacAJ9qNMo3qE5HhgV/6Bhxce2Lz1+BGQCdH5c9 RYe63G22Xhx8xzr+/L7N43I= =4/CF -END PGP SIGNATURE-
DOCBOOK-APPS: Re: glossdivs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / [EMAIL PROTECTED] was heard to say: | I am using $glossary.collection to import an external glossary, but my | glossdiv titles do not show up either in XHTML or FO. Only the contained | glossentries appear, as if no glossdivs were defined. Is this behaviour | expected? From what I could figure out reading glossary.xsl, they should be | processed just as if they were actually in the document. Am I missing | something? If you want glossdivs in your automatic glossary, put one in your dummy glossary: glossary role=auto glossdivtitlefoo/title glossentryglosstermirrelevant/glossterm glossdefpara//glossdef /glossentry /glossdiv /glossary Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Puritanism--The haunting fear that http://www.oasis-open.org/docbook/ | someone, somewhere may be Chair, DocBook Technical Committee | happy.--H.L. Mencken -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+Nd5qOyltUcwYWjsRAicfAJwNzeBrgoqB2XrnDdc8Ca9joXM2uQCgh9Md 573FTs/HBI3vOGnymG0VejI= =/Ang -END PGP SIGNATURE-
DOCBOOK-APPS: Re: links to automatic glossary entries are broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / [EMAIL PROTECTED] was heard to say: | In the FO stylesheets (up to 1.60.1), glossterms occuring inline point to a | id of the form gl. but when the glossary is generated, the gl. is | missing in the expansion of the corresponding glossentries. At least, when | a $glossary.collection is used. I patched it in my customization layer, but | unless this behaviour is expected, it would nice be good to correct it in | some next release. Fixed. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | The way to get things done is not http://www.oasis-open.org/docbook/ | to mind who gets the credit of Chair, DocBook Technical Committee | doing them.--Benjamin Jowett -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+Nd2JOyltUcwYWjsRAqOPAKCuna3zyTndT63G4DqMeq8kl1HhSgCgm4ik BRq+ZB6JK4qAkeWtPN2mJjM= =sKhp -END PGP SIGNATURE-
DOCBOOK-APPS: Re: DiffMk trouble for DocBook documents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Johann Richard [EMAIL PROTECTED] was heard to say: | I have a problem with it which I couldn't resolve until now: | | I want to do a text diff on some DocBook files. This works fine | but there is one thing I don't like: My root element is doubled | when there was a change in one of it's attributes, i.e. I get | something like | | book revisionflag=added fpi=my_fpibook revisionflag=deleted | [...] | /book/book That's odd. Can you send me (offlist) a sample that demonstrates this? | How can I tell DiffMk to either ignore this change on the root | element *or* to mark it as modified? I tried to better understand | the configuration files, but I don't have a clue where to start. I recently changed the rules for diff to ignore attributes. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | If all mankind were to disappear, http://www.oasis-open.org/docbook/ | the world would regenerate back to Chair, DocBook Technical Committee | the rich state of equilibrium that | existed ten thousand years ago. If | insects were to vanish, the | environment would collapse into | chaos.--Edward O. Wilson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+Np2EOyltUcwYWjsRAiNKAJ0QBPACxOpacqr75//qZOKvCMO1aACbB3aN 7SdUR8BN6l0NKUT9njlC7ko= =BLLH -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Using inline.monoseq in FO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Martin Perina [EMAIL PROTECTED] was heard to say: | But there is a problem: inline.monoseq uses | attribute set monospace.properties, but | it has set font-size attribute to 0.9em. That's | not problem for para, but it's great problem | for title in chapters or sections, for example: Why is it a great problem? The result should be 90% of the paragraph size in the first case and 90% of the title size in the second. Are you getting a different result, or do you not like that result? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Irrationally held truths may be http://www.oasis-open.org/docbook/ | more harmful than reasoned Chair, DocBook Technical Committee | errors.--T. H. Huxley -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+NpxkOyltUcwYWjsRAhdHAKCtTGiWJt3hWT9ibp/ZAYKYvhHXaQCfYAVc JwBuZOIrBSfGLELxIKtIals= =1Pf8 -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Calling all XSL customization layers...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ooops. Slip of the fingers, I accidentally identified this as spam when I was approving it. Sorry about that. I'm forwarding it to the list so that everyone gets to see it. / Eric Baudais [EMAIL PROTECTED] was heard to say: | On Fri, Jan 24, 2003 at 08:05:26AM -0500, Norman Walsh wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | It's obvious that changes in the public API of the stylesheets cause | problems for customization layers. I think it's time to start thinking | about how to address that problem. | | I'm not sure what to do, but I think a good first step would be to | find out what part of the API is actually being used publicly. | | If you're interested in helping, please send me a list of all the | named templates that you call from your customization layer(s). | | At the very least, I think I'll start marking some of them as public | so that I know I'm breaking things when I change them :-/ | | Be seeing you, | norm | | Norm- | | The GNOME Documentation Project has been talking about this very | thing!!! We have made some extensive customizations for the 1.45 | stylesheets and now they do not work with the most recent versions. I | believe the problem is because some of the named templates have | changed their names. | | Currently we distribute the 1.45 stylesheets because they are old and | distributions do not include them. This stems from a decision we made | a while back to not always update our customizations with every | release of your stylesheets. Rather we would just include the | specific version we wanted to support. We felt that updating the | customizations for every release of your stylesheets would be like | chasing a moving target which might or might not break the | customizations. Lately there has been some talk about seeing if you | would create a stable API which will guarantee future releases of your | stylesheets will not break our customizations. If you are willing to | do this it would be great! | | Below is a list of all the named templates our customizations call. | It includes the filename and the name of the template. | | html/admon.xsl:admon.graphic.width | html/admon.xsl:admon.graphic | html/html.xsl:anchor | html/inline.xsl:inline.boldmonoseq | common/common.xsl:person.name | common/l10n.xsl:gentext | common/l10n.xsl:dingbat | common/common.xsl:copyright.years | common/l10n.xsl:gentext.space | html/inline.xsl:inline.boldseq | html/inline.xsl:number.rtf.lines | html/chunk.xsl:href.target | html/component.xsl:component.title | html/titlepage.templates.xsl:book.titlepage.before.recto | html/titlepage.templates.xsl:book.titlepage.recto | html/titlepage.templates.xsl:book.titlepage.before.verso | html/titlepage.templates.xsl:book.titlepage.verso | html/titlepage.templates.xsl:book.titlepage.separator | html/titlepage.templates.xsl:article.titlepage.before.recto | html/titlepage.templates.xsl:article.titlepage.recto | html/titlepage.templates.xsl:article.titlepage.before.verso | html/titlepage.templates.xsl:article.titlpage.verso | html/titlepage.templates.xsl:article.titlepage.separator | html/inline.xsl:inline.monoseq | common/common.xsl:mediaobject.filename | common/common.xsl:select.mediaobject | common/l10n.xsl:gentext.template | html/autotoc.xsl:component.toc | html/autotoc.xsl:division.toc | html/titlepage.templates.xsl:book.titlepage | | I belive the best solution would be to define a list of named | templates whose variables and global behavior will not change in | future versions. This would be the DocBook XSL API and will only | change for major versions of the stylesheets. If you wished to add | features to these templates or to change them you would add an | experimental parameter which would turn on these features/changes. | I think all new named templates should also be controlled by an | experimental parameter which include the new named templates. This | way you can have a stable set of stylesheets while at the same time | allow people to use the latest developmental changes in the stylesheets. | | I am glad you are considering a stable API for the DocBook XSL | stylesheets. | | Eric Baudais Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | A philosophical contempt of life http://www.oasis-open.org/docbook/ | is no guarantee of courage in the Chair, DocBook Technical Committee | face of death.--Gustave Vapereau -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+MqJYOyltUcwYWjsRAuoEAJ90G2eH3SFo3uB37yfuckD8DL+umgCgo/K9 y1NSveUnC4Dwqq+xlHfx8sI= =ytDO -END PGP SIGNATURE-
DOCBOOK-APPS: Announce: DocBook XSL Stylesheets 1.60.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At http://sourceforge.net/projects/docbook/ Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Whatever else we are intended to http://www.oasis-open.org/docbook/ | do, we are not intended to Chair, DocBook Technical Committee | succeed: failure is the fate | allotted.--Robert Louis Stevenson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+MrwTOyltUcwYWjsRAlTZAJ4qeAclx3wGXXQWgpvidRiFNr9mwgCfXQBO zFKpQAV9BhkrDK0CW87O8IQ= =rM0u -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Page references for Glossary terms not created
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Stephan Wiesner [EMAIL PROTECTED] was heard to say: | Hi list, | for the sytle 1.6 and FOP 0.25.RC | the page reference [113] is created for | xref linkend=gloss_MD5 endterm=gloss_MD5A/ | | but not for (only [] is created), as it should be | xref linkend=gloss_MD5G endterm=gloss_MD5A/ Can you send a more complete example, please? A document that demonstrates the error. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | If brute force doesn't work, maybe http://www.oasis-open.org/docbook/ | you're not using enough brute Chair, DocBook Technical Committee | force. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+Ms0POyltUcwYWjsRAq9gAJ4626wmn5gb1qKxrAWT0LtP7ETrOACfUjW3 lXTk3zPDYrLzqevEOESChRE= =GKHw -END PGP SIGNATURE-
DOCBOOK-APPS: Announce: Experimental Slides and Websites releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Slides 3.1.0 and Website 2.4.0 coming to docbook.sourceforge.net this afternoon. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Don't despair, not even over the http://www.oasis-open.org/docbook/ | fact that you don't despair.--Kafka Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+MuBBOyltUcwYWjsRApYFAKCGdw+cSBpWU4OyK47E6uLz8FeOdACfeyIk ii9Nh77huXfHBmjmB6ujv1U= =0WkI -END PGP SIGNATURE-
