Re: [docbook-apps] Multiplatform toolchain for outputting "nice" PDF
Hi, On 20.01.24 16:46, l@tlo wrote: A year and a few months later, here we are, ready for an upgrade. We're moving to a Ubuntu container that has fop 2.9. Now, I'd like to move to DocBook 5.1 but I'd like to know if there is there an online document that summarizes the major differences between DocBook 4.5 and 5.1. If I'm not mistaken, there is no direct summary of changes between DocBook 4.5 and 5.1. However, you can review the changes between 4.5 and DocBook 5.0 here: https://tdg.docbook.org/tdg/5.0/ch01#introduction-whats-new There is another summary that also includes changes between DocBook 5.0 and 5.1 which you can see here: https://tdg.docbook.org/tdg/5.2/ch00-online#changes-in-52 Hope that helps. :) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook xslTNG prerelease 2.0.7
Hi, On 06.02.23 19:48, Tony Graham wrote: On 06/02/2023 15:23, Thomas Schraitle wrote: ... No localization exists for "" or "". Using default "en". Error at xsl:text on line 169 column 19 of functions.xsl: XTMM9000 Processing terminated by xsl:message at line 169 in functions.xsl Do you have any 'xml:lang=""' in your document(s)? No, not that I'm aware of it. All xml:lang are set correctly. But thanks for the suggestion. [...] -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook xslTNG prerelease 2.0.7
the result HTML is zero bytes. :) To help debugging, would it make sense to have an option that the HTML could be still generated? Even if there are some errors? Although the HTML might be broken, it could give some hints where the XML source contains some strange structures. Thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Testing DocBook xslTNG 2.0.2 with a real world example
Hi, On 20.01.23 09:44, Norm Tovey-Walsh wrote: This gave me some errors which I'm not able to interpret. For easier reading, I've uploaded the messages and the XML source code here: Thank you! I love a test case :-) I would have provided one, but I'm not yet familiar with XSpec and XSLT 3.0. ;) All I can for now is to point out some issues. :)) Will report back after I’ve had a chance to investigate. Great, many thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Testing DocBook xslTNG 2.0.2 with a real world example
Hi,
thanks for releasing 2.0.2 of the DocBook xslTNG stylesheets! \o/
I was curious and wanted to play with it on a real-world example. :)
The example that I've chosen is our administration guides written in DocBook 5.
It has already been successfully published with the DocBook XSLT 1.0
stylesheets. The source code contains 50.000 lines of fine DocBook XML. So it's
quite massive. ;)
For convenience reasons, I've added all in one directory. So I've downloaded
the ZIP archive from GitHub, unpacked it, and created the admin book as a
single DocBook XML file. As the images are referenced without any paths, I've
linked all the PNG and SVG files to this (temporary) directory.
This is how the directory looks like:
docbook-xslTNG-2.0.2/
+-- {bin,docker,libs,resources,samples,xslt}/ # all dirs from the project
+-- tmp/
| +-- book-administration.xml # my guide
| +-- *.png
| +-- *.svg
+-- out/ # output should go here
I run it like this:
$ cd docbook-xslTNG-2.0.2/
$ python3 bin/docbook -xsl:xslt/docbook.xsl \
-s:tmp/book-administration.xml \
-o:out.html
This gave me some errors which I'm not able to interpret. For easier reading,
I've uploaded the messages and the XML source code here:
https://gist.github.com/tomschr/01bd34acca30b789456ad5e4ee7b3dab
As a summary, I have these issues:
* Some templates seems not be available and I get this messages:
No titlepage template for: quote
No localization for keycap/keycap in en, using "MISSING"
No localization for keycap/keycap in en, using "MISSING"
* I get errors from the TNG stylesheets itself. For example:
XPTY0004 An empty sequence is not allowed as the first argument of
array:size()
invoked by xsl:iterate at docbook-xslTNG-2.0.2/xslt/modules/objects.xsl#62
There are similar issues.
It seems, some of the issues are coming from the stylesheets, right? Or is it a
problem in my source code? It's hard to believe as I've validated it against
DocBook 5.2 and it's valid. :)
Maybe I did something wrong. How I can solve the issues above? Would it help to
open some GH issues?
Many thanks and keep up the great work!
--
Gruß/Regards
Thomas Schraitle
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] How to migrate DocBook XSLT 1.0 stylesheets to 3.0?
Hi, On 15.12.22 21:03, Thomas Schraitle wrote: [...] I took the liberty to open a new issue: https://github.com/docbook/xslTNG/issues/212 If you have further ideas, suggestions etc. let us know and add it here or in the above issue. Many thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] How to migrate DocBook XSLT 1.0 stylesheets to 3.0?
Hi, the DocBook XSLT 1.0 stylesheets served us very well over the years. However, as more and more features are implemented in DocBook 5, the more difficult becomes it to add them into the XSLT 1.0 code base. As far as I see, the new XSLT 3.0 stylesheets[1] tries to create the foundation for this. Luckily, Norman provided a very detailed documentation[2] how to use them. I'm very grateful for this and it's very helpful. Thank you very much! I played a bit around with them. However, I'm more interested in how to _migrate_ from the older XSLT 1.0 stylesheets to the new ones. If I'm not mistaken, there is no such documentation yet, right? I hope this question could serve as a starting point to collect some ideas and to amend the documentation. Currently, we use an extensive customization layer of the DocBook XSLT 1.0 stylesheets which support HTML and PDF through XSL-FO. We use xsltproc to transform them. We even created a tool chain to help us with profiling etc. This works quite well and we are happy with this. However, as XSLT 1.0 has some limitations and needs workarounds, I'm searching for a way if this code base could be migrated somehow. Therefor I'm looking for some tips and tricks, best practices, or recommendations. How would you proceed with this? I suppose it isn't easy and needs a complete rewrite? Before I start that task, I have some specific questions which hopefully helps me to understand this better: 1. Compatibility mode in Saxon11? As we currently use xsltproc, would it make sense to gradually replace the XSLT processor with Saxon 11 and still using the XSLT 1.0 stylesheets? Just to get some experiences etc. I suppose Saxon 11 has a compatibility mode for XSLT 1.0. However, some extension functions and elements in the XSLT 1.0 stylesheets could be problematic as they don't exist in Saxon 11, right? 2. Speed? When we tried Saxon 6, we measured it is ~3x slower than xsltproc. This is probably not a surprise (Java versus C). We have quite an extensive DocBook code base. To build all product documentation for HTML and PDF takes a long time. If we multiply it by a factor N it takes even longer. So that's an important point for us. I've read somewhere that the slower start up time is due to the Java engine. Once it is started it is more or less comparable with xsltproc. Is it correct? Can we start Saxon 11 in a kind of "background mode" where it waits and listens to some transformation requests? Would that be possible? 3. How to deal with XSL-FO? Currently, the xslTNG stylesheets don't support XSL-FO (yet). Nowadays it's recommended to use some (print) CSS to create PDF. There are commercial offerings for this task, but we are looking for an open source solution. Would a browser engine sufficient too? Or are there any other tools recommendations? The other option would be to implement XSL-FO. However, I think, that would be quite a big task, wouldn't it? Is it planned to implement it? What would you use to provide PDF? 4. Recommendations? Best practices? Are there any recommendation to follow, traps to avoid etc.? Thanks for all your ideas and thoughts! :-) --- References [1] https://github.com/docbook/xslTNG [2] https://xsltng.docbook.org/ -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Multiplatform toolchain for outputting "nice" PDF
Hi, On 14.11.22 19:51, Kevin Dunn wrote: As someone who made a similar update, I can provide some perspective. Much of your tool chain may be old, but it's actually "mature," not "outdated." The most limiting element of your tool chain is likely fop. When I migrated from dsssl and jadeTeX to an xsl tool chain, I considered fop alongside Antenna House Formatter and RenderX XEP. As much as I like and admire free tools like fop, the commercial xsl-fo engines are superior. Each of them is available on multiple platforms, and each has a free demo version for evaluation purposes. FOP has just published version 2.8 a some time ago and I think it has improved a lot. Of course, depending on what features you need, it may or may not be on par with commercial formatters. :) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Transclusion fixup for XSLT 1.0?
Hi, there is a stylesheet for XSLT 2.0 that deals with transclusion attributes: https://github.com/docbook/transclusion-fixup/blob/master/transclusion-fixup.xsl This stylesheet rewrites IDs to avoid "multiple ID errors" when you include the same file with ID more than once. It there a change that this stylesheet can be (re)written into XSLT 1.0? I know it needs certainly extension functions, but I can't use the 2.0 version. Backstory: The assemble/assemble.xsl currently doesn't support rewriting IDs. Especially if you include files more than one, you can run into the above error when validating your realized document. It would be helpful if the assemble stylesheet would support that. Any ideas? Thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Continued page numbering in the frontmatter
Hi Bernhard, On Sonntag, 23. August 2020 22:12:14 CEST Bernhard Kleine wrote: > [...] > > The pagenumbering starts anew for the dedication, the table of contents > and the preface i , i - iv, i ii. > For me this is quite unusual, however, I donot see, where to tackle in > order have the pagenumbering continous from i - x. > [...] Maybe this could help: http://www.sagehill.net/docbookxsl/PrintHeaders.html#PageNumbering Especially the named template "page.number.format". Hope this gives some ideas. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook XSL: The Next Generation
Hi, On Mittwoch, 29. Juli 2020 17:24:24 CEST you wrote: > [...] > > Does the new stylesheets create PDFs through a HTML -> browser -> PDF > > workflow? Or will there be separate XSL-FO stylesheets at some day? > > My current thinking is that HTML+CSS through some tool like AntennaHouse > Formatter or PrinceXML (or other similar tools) is the way forward. Thanks Norm. Yes, that can be an interesting way. I've heard about that, but I'm not so much into this topic ATM. As far as I know, the above tools are commercial. Do you know an open source solution? > If I > had the time, I’d be happy to work on XSL FO stylesheets. But I don’t > want to do the job badly and I don’t have the time to do it well. I can fully understand your position. :) I'm sure it's fun, especially when you come from a XSLT 1.0 background. That's a huge step forward. On the other side, it's also a huge task, I guess. ;) > [...] Thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook XSL: The Next Generation
Hi Norman, On Dienstag, 28. Juli 2020 18:12:03 CEST Norman Tovey-Walsh wrote: > > A few days ago, I released the first version of the DocBook xslTNG > Stylesheets. These are a complete rewrite of DocBook to HTML stylesheets > in XSLT 3.0. This is a huge step forward! Many thanks! > The goal of the stylesheets is to produce clean, semantically rich > HTML(5) that can be beautifully rendered with CSS (and a dash or two of > JavaScript, if you wish) in the browser and in print. [...] Just for clarification: how do we get PDF thesedays? Does the new stylesheets create PDFs through a HTML -> browser -> PDF workflow? Or will there be separate XSL-FO stylesheets at some day? Thanks for clarification! :) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Thumb register
Hi, On Montag, 20. Juli 2020 09:40:33 CEST Norman Tovey-Walsh wrote: > Bernhard Kleine writes: > > I have used a thumb register in a book produced with LaTeX. That was > > fairly straight forward. I wonder whether this is also possible with > > docbook -> PDF. Is there a solution already? > > Pardon my ignorance, but what is a “thumb register”? If I understood Bernhard correctly, it's a "thumb index": https://en.wikipedia.org/wiki/Thumb_index Of course, you cannot cut off a specific parts of a page with XSL FO, but you can "simulate" that by having a colored space at the page margin. Hope that helps. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Merge biblioentry data to citation
Hi Peter, Am Tue, 27 Nov 2018 18:54:04 +0100 schrieb Peter Fleck : > Is there a way to only have a biblioentry once in the bibliography > and then cite the details multiple times? > So for example here in > https://www.chicagomanualofstyle.org/tools_citationguide/citation-guide-1.html > > Something like this? (Though this doesn't work). > > .., > 315-16... > ... > .., > 402... It seems, biblioref would be the appropriate tag for you: https://tdg.docbook.org/tdg/5.1/biblioref.html With biblioref you can add the attributes "begin", "end", and "units" like this: See . If you process it with version 1.79.2 of the stylesheets, you will get this result: See [isbn-9780143111641]. It seems, the attributes above are unsupported. I think this is a bug as I couldn't find any code which uses them. If you want to take them into account, you need to write a customization layer. One final note about citation. You can use it to reference multiple bibliographic entries like this: See , which renders as: See [A, B]. (watch for spaces inside ). -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Combining para role templates
Hi Peter, Am Freitag, 12. Oktober 2018, 16:16:13 CEST schrieb Peter Fleck: > I have a number of templates that add some formatting to xsl:fo, they > are in the format of: > > > > > > > > > > > > > > I want to be able to combine these various templates, something like this: > [...] What about this (untested): red xx-small Apart from the XSLT solution above, your role looks like you've (ab)used it as an admonition element. ;) Have you tried one of the admonition elements like warning, caution etc.? ... Not sure if that can be applied to your document. However, it seems to me, it could simplify your customization even more. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] How to make chemical structure automatically numbered
Hi, Am Freitag, 12. Oktober 2018, 15:46:50 CEST schrieb Bernhard Kleine: > > @Peter: It seems that figure is a valid element, however, the numbering > of figure for structures would conflict with the numbering a normal > figure. As long as there is no possible was to have a "proprietary" > counter for structures (as figures) structures do not have an > independent numbering. I wonder since there are an awful lot of chemical > papers where there is an independent list of structures, that none of > them has been prepared with docbook. Otherwise there would be a solution > already. As I've pointed out in my last mail (coincidentally sent at the same time), you could use . However, I see the following solutions in regards to numbering: 1. Use or Pros: * if the book doesn't contain any normal equation, it's easy to apply * no schema customization * no stylesheet customization needed Cons: * Not sure if you want to label your chemical structure as "Equation" (can be fixed) * More stylesheet customization is needed, if you need to distinguish between numbering of a normal equation and numbering of a chemical structure 2. Use Same as equation, it's just a matter of taste which one do you prefer. The same pros and cons apply. 3. Create your own element (?); creating DocBook RNG customization Pro: * free to design what structure you really need * easy with the help of RELAX NG * independent of any numbering of figure or equation Cons: * not be DocBook compatible anymore; to validate, you need your own schema * you need to write a customization layer for the DocBook XSL stylesheets I hope I haven't misunderstood your ideas. Does that make sense? > @Thomas: since the structures are svg as well as most figure in my book, > I have considered svg. However, than I would lable a contruct of > structures, but not the individual ones. Coming from LaTeX, the > numbering of figures was always a simple use of apropriate macros. I also come from a LaTeX background. ;) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] How to make chemical structure automatically numbered
Hi, Am Freitag, 12. Oktober 2018, 15:19:59 CEST schrieb Peter Desjardins: > I think the table is adding valid semantic structure here. It allows the > figure numbering to exist at the Docbook level, not in SVG. > > Maybe use elements inside an ? You could wrap the > informaltable in an example to give the entire set of diagrams a title. Thanks for your reply Peter. I'm sorry, but I have to disagree. :) If Bernhard tries to display chemical structures, why using an overly complicated structure? KISS (keep it simple, stupid)! ;) I see no benefit in using a table here. Even the opposite: tables on mobile devices (EPUB) can have issues. It's better to avoid them. Even if you go from simple chemical structure to a chemical reaction, there is even no reason to split it into several pieces. A structure---and so a reaction---belongs together IMHO. With the features of SVG, it's possible. As DocBook doesn't provide a element for chemical structures, you need either use figure or equation (as Jirka pointed out). For example: Steran Steran... IMHO, this is totally enough. Put everything in steran.svg what you need: labeling, text, arrows, etc. With the @condition attribute, you can distinguish a chemical structure from a "normal" equation (if you need to). Even if you really have to use subfigures for a chemical structure I would avoid table structures at all costs. For example, if you need to have two subfigures, you could use two mediaobjects: Steran A and B Steran A... Steran B... Of course, you need to delegate the layout to the stylesheet and you need to write a customization layer. For FO it can be rendered indeed as a table and for HTML there are different (CSS) methods to position two objects side by side. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] How to make chemical structure automatically numbered
Hi, Am Freitag, 12. Oktober 2018, 14:12:15 CEST schrieb Bernhard Kleine: > In my second mail to this threat a showed a complex table with > structures, arrows labeling etc. I cannot envisage this without a table > structure. As Dave already pointed out, a table might not be the appropriate way to layout things. Have you considered SVG? With SVG (or any other vector format) you can do all the fancy stuff (arrows, labeling etc.) that you need. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Same font and color for specific titles
Hi Peter, Am Dienstag, 1. Mai 2018, 09:27:41 CEST schrieb Peter Schmelzer: > thank you so much for your detailed response. > > I thought I had to write only one customization file containing all > elements which should be changed. > > I will follow the guideline/your suggestion to apply my customizations. As an addition, not as a replacement, you could also have a look at my Cookbook: http://doccookbook.sf.net/html/en/ It contains some typical topics about manipulating the structure and customizations. Although it is not finished, it may give you some inspirations. Find the sources and the stylesheets on GitHub: https://github.com/tomschr/dbcookbook Have fun! :) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Regarding URLs for NS and non-NS DocBook Stylesheets
Hi Ron, Am Sonntag, 19. November 2017, 16:57:25 CET schrieben Sie: > > At the last chnage you get the namespace aware without the -ns bit. as > i remember you need something like -nons to get the no namespace version > [...] Oh right! :) So the meaning has been switched: in the SF case, the default was the non-NS version and you need the "xsl-ns" to get the NS variant. With the new CDN URL, it's just the opposite: the default is the NS variant and you need the "xsl-nons". That works: http://cdn.docbook.org/release/xsl-nons/ Great, thanks Ron! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Regarding URLs for NS and non-NS DocBook Stylesheets
Hi, I've noticed a change how the DocBook stylesheets are accessed through URLs. Before this change, we had these two URLs: http://docbook.sourceforge.net/release/xsl/ http://docbook.sourceforge.net/release/xsl-ns/ The first URL access the non-namespaced stylesheets whereas the second one is for the namespace aware. So far, so good. :) For the latest release 1.79.2, there is now this URL in place: http://cdn.docbook.org/release/xsl/current/ Probably this change was needed because of the move from Sourceforge to GitHub. To have more general URLs, not bound to SF. If you look into the catalog.xml file in the root directory of the tarball, there is only the previous URL. No Sourceforge URLs anymore. So I assume, this replaces the old one, right? However, there is no equivalent namespace-aware URL. The following URL gives me a 404: http://cdn.docbook.org/release/xsl-ns/current/ I have some questions: 1. Is this a bug? ;-) 2. How am I suppose to access the NS variant of the stylesheets? Is there an "official blessed" URL? 3. Shouldn't be the old URLs still be added to the catalog.xml file? I assume, these former URLs are quite well-known and used in many customization layers. Thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] ulink - oxygen18 - jing
Hi Ron, Am Samstag, 5. November 2016, 10:45:09 schrieb Ron Catterall: > If I put a ulink into an xml document using oxygen18, Jing displays an > error: > element "ulink" not allowed anywhere; expected the element end-tag, text > or element "abbrev", "accel", "acronym", "alt", "anchor", "annotation", > ... etc ... see below The element ulink is not allowed in DocBook 5 anymore. It is only available in version 4. For version 5, it was renamed to . See table 1.1 of renamed elements: http://docbook.org/tdg5/en/html/ch01.html#t.renamed > Despite the error the xml transforms correctly to chunked html output > and the link works OK. Yes, because the stylesheets know both elements and have templates for both link and ulink. > This appears to be a false error message from Jing and/or oxygen? No. See above. Jing is absolutely correct here. > [...] Hope this helps. :)) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Alternatives to entities for referencing small substitutions
Hi Paul, Am Dienstag, 18. Oktober 2016, 20:38:00 schrieb Paul Hoadley: > > What is the state of the art for small text substitutions (basically just > domain-specific terms) that can also be varied via the profiling machinery? > I have an application that can run as more than one “product”, and each > product shows domain-specific variations in labels, for example, in the > user interface. There might be a generic term for some object “Foo”, but > Application A will call this a “Bar”, and Application B calls it a “Baz”. > What I want to be able to do is refer to a “Foo” throughout the source, but > substitute “Bar” for App A’s output, and “Baz” for App B’s. What’s the best > way to achieve this? This sounds like profiling in combination with entities. You could define your foo entity like this: BarBaz"> The element is quite neutral and is allowed where inline elements are also allowed. When you have this "foo" entity, you can refer to it throughout your document as . Of course, you need to set the profiling attribute os accordingly to filter it for application A or B. We use it for different product names and numbers which applies the same approach. It works great. Keep in mind, this approach relies on a "side effect": it depends on phrase being allowed in all contexts. This is not always the case. For example, you cannot use inside attribute values. Or, if you have customized the DocBook schema and you don't allow phrase in, let's say, a title. That won't work as you will get validation errors. Apart from this, I think you will be happy with this approach. ;-)) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Removing newlines between s
Hi Ekaterina, On Wed, 24 Aug 2016 08:03:33 + "Shikareva, Ekaterina" <eshikar...@luxoft.com> wrote: > For me, this empty line appears even before any conversion, I can see > it in XMLMind: see the same file in Notepad++ - > https://i.imgur.com/MmacVZc.png XMLMind DocBook Editor v. 7.0 - > https://i.imgur.com/zTjEdSw.png Also visible in XMLMind 5.3.0. > > And btw, if you create an informaltable with XMLMind, the paras > inside will be saved on the same line, as in the first row. For these > screenshots, I had to manually insert a line break in the second row > to reproduce the problem. I haven't followed the complete thread, but according to the screenshots and what you've wrote, you seem to use XMLMind for your XML editing. Ekaterina, I think, you should distinguish two cases: (1) The rendering in your XML editor (here: XMLMind) (2) The output from the DocBook stylesheets These two are different sets, they don't have much in common. To compare these, you should know the technologies behind it. Usually, thesedays, XML editors use CSS for rendering XML files. XMLMind and oXygen falls into this category. CSS is a language to format the layout of Web pages (and in this case, XML). In its simplest form, it applies layout information (font size, text style, indentation, border etc.) to elements. Nothing more, nothing less. In other words, you can't restructure your XML file with CSS and change the order of elements. That's not its purpose. For an XML editor this is usually enough because it's fast enough and you get a kind of "what you see is what you get" feeling that most people know from Office programs. However, what you see in your XML editor is NOT the final result! If you use the DocBook stylesheet as toolchain, they use XSLT. XSLT is a transformation(!) language. With XSLT you can do all the fancy things that you can't do with CSS. Your XML editor "fools" you to believe some things are "broken" which isn't. A different XML editor (oXygen, FrameMaker, etc.) shows you probably different rendering views of your XML file. If your XML editor shows para elements differently, it's a bug in your XML editor. To make a long story short: The relevant result is the output of the DocBook stylesheets, not how your files are displayed in your XML editor. The rendering in your XML editor can be considered as a hint. The DocBook stylesheets should create the correct HTML or PDF. If not, it's a bug. Hope it helps you to understand the differences better. :-) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Recommended docbook element for a "Problems section"
Hi Eric, On Mon, 11 Jan 2016 00:55:45 +0100 Erik Leunissen <e...@xs4all.nl> wrote: > I'm in the process of writing an educational textbook. The textbook > is a docbook book, containing several chapters. Each chapter contains > several sections with "explained content", a "Problems section" and a > bibliography. Like the sections, the "Problems section" and the > bibliography occur at the same level just below a chapter. > > (B.t.w. the word "section" in "Problems section" is just a matter of > speak, not meant to be a docbook element, not yet anyway) > > [...] > My question relates to the "Problems" section in each chapter. Like > the bibliography it must not have a label, but must occur in the > table of contents. > > I've been looking for a docbook element for such a "Problems > section", and I have difficulty finding an appropriate one: > - I can't make it a docbook section because these are processed to > display a label. I fear, there is no dedicated element for a "problems" section. However, you can try the label attribute and set it to an empty value. It is there to influence the section numbering. Not sure if this is what you want. On the other side, the best approach is probably to use the role attribute, set it to role="problem" and write a XSLT customization layer for further processing. > - a Q set seems inappropriate since there are only questions (which > are not "Frequently asked" anyway; and answers are not supposed to be > provided in the same structural element) Well, as you probably already know, there is the qandaset element for this purpose. It allows you to add one question but you are not forced to provide any answers. Does that help? Of course, you are free to wrap it inside a section. > - I've been thinking about using a section element with a dedicated > role attribute, that triggers customized processing, but that's just > a wild idea for now. I did the same with my cookbook which you can browse here: http://doccookbook.sf.net (will be moved to GitHub in the future) Used a role="problem" and "solution" but ATM, I haven't done any special processing with them. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Chunking options for HTML output
Hi Frank, Am Freitag, 6. November 2015, 16:59:32 schrieb Frank Arensmeier: > > I am wondering. DITA has the attribute "chunk" that gives the user some > control about how a topic/section is treated when it comes to output > chunking. Setting that attribute to "to-content", the topic (including its > children) is "… rendered as a single chunk of content". Is there something > similar in DocBook? I'm not aware of anything similar. DocBook has no attribute that is targetted for this purpose. However, you could (ab?)use some common attributes (maybe condition?) and customize the chunking template. Haven't tried it yet. A possible easier solution would be to use the processing instruction. It's explained in the link below. > I know that I can control the chunking level – but > that’s a different story. I need a more fine-grain control for the chunking > mechanism. Could this be achieved in a customisation? Which "key" > stylesheets in DocBook XSLT would be promising candidates to look at? Would the following link fit your needs? http://www.sagehill.net/docbookxsl/Chunking.html -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook XSL 1.79.0 release is available
Hi, On Thu, 15 Oct 2015 19:25:51 -0400 Stefan Seefeld <ste...@seefeld.name> wrote: > [... GitHub ...] > DocBook as organization Stefan, I fear your claim isn't completely right. :) Technically, DocBook isn't an organisation on GitHub, it's just a normal user named "DocBook". :) Shouldn't this be migrated to an organization instead of having a normal user? According to https://help.github.com/articles/about-organizations/ About organizations Organizations are great for businesses and large open-source projects that need multiple owners and administrators, grouped together with teams that determine affinity and repository permissions. 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. :)) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook XSL 1.79.0 release is available
Hi Bob, On Thu, 15 Oct 2015 15:33:33 -0700 Bob Stayton <b...@sagehill.net> wrote: > I finally finished putting together a new release of the DocBook XSL > stylesheets. I apologize for the long delay. Future releases should > come more frequently as we move over to Github. Thanks a lot Bob for this effort! Great work! One question about contributing: Any bugs should be reported on GitHub now, right? Will the old bugs on SourceForge be migrated to GitHub? How to contribute? Is it ok to send pull-requests or would you prefer other forms? Ok, sorry, that was more than one question. ;)) Thanks! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Profiling NOT condition
Hi Matteo, On Tue, 6 Oct 2015 15:36:53 +0200 Matteo Regazzo <matteo.rega...@cmz.it> wrote: > [...] > Does the DocBook include something like a "NOT" conditionfor the > profiling? Unfortunately, the profiling stylesheet doesn't support a NOT condition. It would be very convenient to have one. What you can do is to list all possible profiling attributes except the one which you want to exclude (that's your "not condition"). You can translate the "not condition" into this set of relationships: not Cond2 = Cond1 not Cond1 = Cond2 If you allow more than two values in your profiling attribute, you have to list *all* your possible values, except the excluded one: not Cond1 = Cond2;Cond3;Cond4;... Hope this helps. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Index of People (5.1)
Hi, On Tue, 25 Aug 2015 12:08:30 -0230 Pc Thoms <pcth...@gmail.com> wrote: > PeterFleck > Fleck, > Peter > > The above should work fine. Avoid whitespace. That works, but it's cumbersome. ;-) You can create indexterms (semi)automatically: http://doccookbook.sf.net/html/en/dbc.structure.adding-indexterms.html I used this approach and it helps to create consistent index entries. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Moving the DocBook wiki
Hi, On Thu, 01 Oct 2015 21:16:16 -0500 Norman Walsh <n...@nwalsh.com> wrote: > 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. Great work, Norm! Thanks a lot! I'm interested and it would be nice if you could add me. My ID/account name is "tomschr". Thanks! -- Gruß/Regards, Thomas Schraitle pgpx7KWeVYJyu.pgp Description: OpenPGP digital signature
Re: [docbook-apps] Show off what you've done with Docbook
On Sun, 13 Sep 2015 21:25:45 -0600 (MDT) Warren Block <wbl...@wonkity.com> wrote: > [...] > Examples, even trivial ones, are hugely useful. Just having two or > three would be useful for reference when implementing a custom look. > Being able to use an existing style and override some elements like > annotation icons and colors and fonts would be useful to many. > > Granted, doing that could be difficult for a number of reasons. But > it is something that would make DocBook easier to use. If you like examples, you may be interested in my cookbook: http://doccookbook.sf.net/html/en/index.html Although it deals more with specific questions, it could be useful to some degree. If you use it like Lego bricks and cherry pick what you need, it could end up with something that is close what you've anticipated. Have fun! :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Show off what you've done with Docbook
Hi, Am Freitag, 11. September 2015, 23:45:25 schrieb Warren Block: > [...] > > For me, DocBook is powerful but a pain to write. AsciiDoc is simple to > write, but does not have the semantic markup power of DocBook. That is the essential part. I hear from all sites that DocBook is a bit overwhelming for non-technical people. They would love to contribute but don't want to install and work with a complex toolchain just for fixing a simple typo. For this reason, AsciiDoc would be a good start. Unfortunately, I have to agree what Warren said about the lack of "semantic power". Funny sidenote, AsciiDoc was based on DocBook. ;) By the way, DocBook5 is based on a RELAX NG schema. It can be written in a compact version (RNC) or in a XML syntax (RNG). Both are interchangeable without loss of information. It would be great if AsciiDoc would fill this gap, so both XML experts and non-technical inclined people could be satisfied. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Show off what you've done with Docbook
ing teams, I assume, they discussed the pros and cons and at some point they came to a decision. If their needs meet DocBook's portfolio why shouldn't they take the challenge? In most cases the problem solver is money: hire a dedicated XSLT engineer and you have it. ;) > Does anybody sell a commercial Docbook customization layer? If this was > Joomla, or Wordpress, or MediaWiki there would be a whole marketplace of > free and commercial presentation layers. Never heard. > Is Docbook really that obscure? Not really. Actually, I think, it's quite logical. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Show off what you've done with Docbook
Hi Gerhard, Am Samstag, 12. September 2015, 11:35:11 schrieb Gerard Nicol: > I'm surprised nobody has put together a Linux VM image with Git and Docbook > etc. Shouldn't be too difficult. ;) > I'd happily pay a few thousand a year for a subscription to a hosted or > packaged Docbook environment if the results looked as good as some of the > better examples provided. You can look at some of our examples which we created by our DAPS toolchain, here PDF: * http://opensuse.github.io/daps/doc/pdf/art.daps.quick_color_en.pdf * https://www.suse.com/documentation/sles-12/pdfdoc/book_sle_admin/book_sle_admin.pdf Of course, it is a customization layer on top of the original DocBook XSL stylesheets. :-) Meanwhile they are quite complicated now. The stylesheets are released in GitHub: https://github.com/openSUSE/suse-xsl -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Time for new DocBook Stylesheet Release?
Hi Frank, On Tue, 30 Jun 2015 22:18:23 +0200 Frank Arensmeier farensme...@gmail.com wrote: I'd be interested to know what to expect from these updates to come too – besides bug fixes I mean. For me, it's mostly bugfixes. Or in other words: don't know of any revolutionary commits, but more evolutionary. ;) Are there any plans to implement some new and exciting output targets? I follow the commits and mailing lists closely and I'm not aware of any new exciting output targets. Maybe there are projects going on behind the curtain or from the Google Summer of Code. For me, I'm pretty satisfied with the variety of available output formats, although I'd love to see more bugfixes for EPUB3. It looks still quite buggy. We have been building a CCMS system with Docbook as its backbone. So for my company it would be very important to know if Docbook is still alive and kicking. Well, thanks Frank for confirming my theory. :) In my last mail, I said we should release our stylesheets more often to avoid sending the wrong signal. :) I don't think it's dead; from my impression it's moving slowly. At least, in my department, we still use it and invested lots of man power and efforts (see the DAPS announcement last week). -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Time for new DocBook Stylesheet Release?
Hi Bob (and others), On Tue, 30 Jun 2015 10:11:22 -0700 Bob Stayton b...@sagehill.net wrote: Has it really been two years?! According to the Files section on SourceForge, it says in the Modified column 2013-03-18. ;-) That's a little bit more than two years. :)) I'll start the process to produce a new DocBook XSL release, and then work with the other developers to carry out the transition of the build to Ant, hopefully simplifying the rather arcane process. That would be great! Thanks for the efforts! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Docbook XSL and FOP 2.0
Hi Radu, On Tue, 30 Jun 2015 09:23:03 +0300 Radu Coravu radu_cor...@sync.ro wrote: I think the problem with most open source software is that there is no specialized Quality Assurance team. We, the public who uses the product are the QA team. That's probably true, but with the help of test driven development, continuous integration (Travis, Jenkins, ...), etc. things progress slowly. [...] I think that a relatively bug-free open source product needs to have three things: 1) Automated tests which are run every night and should detect regression problems. 2) Shorter release cycles. 3) Large user based. Probably Apache FOP only has (3), at least in this particular case. I also tried to compile FOP for openSUSE, but I failed too. :-( However, I see it is difficult to implement a dedicate complete test suite from scratch. I suppose, the FOP developers try to invest their spare time in more important things. For example, when my trainee and I implemented our docmanager[1] script we've used test driven development. Now we have a test suite which comprises of 163 test cases. This test suite is checked by Travis[2] on every commit or pull request. This makes development very easy and fun. However, I suppose, it wouldn't be fun if you must write a test suite from scratch. I would love to see a dedicated test suite for FOP, but also for the DocBook stylesheets. At the moment, this is not the case. IMHO, this is the reason, why we don't see lots of releases in the past (see my other mail about this topic). -- [1] https://github.com/openSUSE/docmanager/ [2] https://travis-ci.org/openSUSE/docmanager -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Time for new DocBook Stylesheet Release?
Hi, in the last years I've observed a trend, that the DocBook stylesheets don't publish new releases very often. The last release of the stylesheets is from 2013 which is two years old! Am I'm the only one who need and wait desperately for a new release? ;)) I know, you are all busy with other things. However, I fear, this makes the wrong impression that this project is dead. I hope this is not. After two years I would love to see a new release. Maybe with a release cycle which counts in months and not years? Any plans? Thoughts? :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Problem customizing appendix title (for PDF)
Hi Erik, On Sun, 08 Mar 2015 22:29:12 +0100 Erik Leunissen e...@xs4all.nl wrote: I want the label of an appendix in an article to show up in a final PDF as follows: Bijlage 1. SomeDutchTitle [...] # Docbook XML source ?xml version=1.0 encoding=UTF-8? article version=5.0 xmlns=http://docbook.org/ns/docbook; xmlns:xlink=http://www.w3.org/1999/xlink; xmlns:xi=http://www.w3.org/2001/XInclude; xmlns:svg=http://www.w3.org/2000/svg; xmlns:m=http://www.w3.org/1998/Math/MathML; xmlns:html=http://www.w3.org/1999/xhtml; xmlns:db=http://docbook.org/ns/docbook; You are missing the important xml:lang attribute in your root element. Without that attribute, all generated texts are created in English by default. Add the line xml:lang=nl into your article without using any customization layer at all. Rebuild your document and check it. :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Using custom fonts
Hi Alan, Am Freitag, 6. März 2015, 14:13:40 schrieb Alan Oehler: I created a fop config file to register Trebuchet as my basic body font and Consolas as my monotype font. Worked beautifully – except it seems like all the places where I'd used emphasis.../emphasis are no longer italicized, and where I'd used emphasis role=bold.../emphasis are no longer bolded (emboldened?). I added all four variants of both fonts (normal, italic, bold and bold italic). Is there some other detail I'm missing? Register Trebuchet? Which version of FOP do you use? As far as I know, registering a font is not needed anymore for 1.0. You only have to insert your base directory of all your fonts and FOP does the rest. See [1] of an example of FOP's configuration file. If you use an older version than 1.0, I would strongly suggest to upgrade to the latest version. [1] https://xmlgraphics.apache.org/fop/1.1/configuration.html#general-elements -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Using custom fonts
Hi Alan, Am Freitag, 6. März 2015, 23:28:56 schrieb Thomas Schraitle: I created a fop config file to register Trebuchet as my basic body font and Consolas as my monotype font. [...] I added all four variants of both fonts (normal, italic, bold and bold italic). Is there some other detail I'm missing? Register Trebuchet? Which version of FOP do you use? As far as I know, registering a font is not needed anymore for 1.0. I forgot to add my example. Here is an excerpt of the PDF renderer: renderers renderer mime=application/pdf fonts !-- register all the fonts found in a directory use recursive=true to also include subdirectories -- directory/usr/share/fonts/truetype//directory !-- automatically detect operating system installed fonts -- auto-detect/ /fonts /renderer /renderers -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] glossterm bold
Hi Sascha, On Wed, 25 Feb 2015 15:55:16 +0100 Sascha Manns sascha.ma...@xcom.de wrote: how does a valid prefix looks like? Declare the namespace it in your root element: xsl:template version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:d=http://docbook.org/ns/docbook; Add the prefix d before your element as in d:glossterm. Remember, you can choose whatever prefix you like (d, db, docbook, ...). Usually it more convenient to have a short one. What you can't change is the namespace URI. Here is a complete example: http://doccookbook.sf.net/html/en/dbc.structure.section-to-sectX.html -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] glossterm bold
Hi Sascha, On Wed, 25 Feb 2015 15:47:26 +0100 Sascha Manns sascha.ma...@xcom.de wrote: actual i'm trying to make (for fo output) all glossterms in glossary/glossentry/glossterm in bold. I tried out: xsl:template match=glossterm [...] But it looks like it doesn't matches while rendering. Maybe i miss anything? Do you use a DocBook 5 document? Probably you miss the prefix in front of glossterm. :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Strategies for Migrating DocBook Customization in a Mixed DB4/5 Environment?
Hi DocBook users, currently, I'm trying to migrate our old DocBook 4 sources to version 5. This is pretty straightforward and can be done with some XSLT magic. The markup side is also well covered in the DocBook 5.0 Transition Guide[1]. However, during this transition, some documents will be kept in DocBook 4. So we end up with a mixed setup for both versions. (Of course, I could feed my new DocBook 5 sources into my existing XSL customizations. This works, but it takes too much time because of the internal convertion of DocBook 5 to DocBook 4.) As such, it would be nice to have a clear separation: use the normal, non-namespace variant for version 4 and the namespace-aware for version 5. However, we have some some hefty DocBook XSL customizations; a DocBook XSL Transition Guide would be helpful. :) How would you deal with such migration of old DocBook 4 XSL customization layers? Any thoughts are highly appreciated! Thanks! :-) [1] http://docbook.org/docs/howto/ -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Tests Framework for DocBook Stylesheets Customizations?
Hi, sorry for the delay. On Thu, 16 Oct 2014 16:04:53 +0200 Jirka Kosek ji...@kosek.cz wrote: On 16.10.2014 10:56, Thomas Schraitle wrote: I'm not sure how easily could this be adapted to our current XSLT 1 base. Are there other (better?) solutions? If you will not use extensions, it should be possible to run DocBook XSLT stylesheets in XSLT 2.0 processor, hence use XSpec. Yes, I've tried it and most of the time it works. :) Unfortunately, if you really depend on extension functions (like the omnipresent exsl:node-set()) you can't avoid it. Have anybody tried a different approach? Python? Ruby? Something else? Thanks anyway! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Tests Framework for DocBook Stylesheets Customizations?
Hi, when developing customizations for the DocBook stylesheets I have always the feeling I forget something important and work without any safey net. ;) As such, it would be great to have a test framework which could automatically check the transformation results with the expected behaviour. I know of XSpec from Jeni Tennison which goes in this direction. However, as far as I know, this is for XSLT 2, not XSLT 1. It's used for developing and testing the upcoming XSLT 2 DocBook stylesheets. I'm not sure how easily could this be adapted to our current XSLT 1 base. Are there other (better?) solutions? How do *you* develop and test your stylesheets? Has anybody used such frameworks? Any help is greatly appreciated. :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Tests Framework for DocBook Stylesheets Customizations?
Hi Dave, thanks for your reply! :) On Thu, 16 Oct 2014 12:25:40 +0100 davep da...@dpawson.co.uk wrote: [...] How do *you* develop and test your stylesheets? Has anybody used such frameworks? Any help is greatly appreciated. :) xspec is for the general case. Question: Is docbook sufficiently 'firm' to allow a specific solution? As Norman used XSpec for the DocBook XSLT2 stylesheets, I would say it is sufficiently firm. ;) I.e. for any given input at the document level, we should be able to specify the 'required' / expected output? That would allow a diff of two files, albeit an XML diff (deep-equals?) which would make for easier testing of the (x)html output. For fo, would the xsl-fo be sufficient? I'd guess so. Hence a similar solution would be adequate. An XML diff came also to my mind. However, as most XML diffs are commercial, I wouldn't recommend it as solution in a purely open source environment. Another reason why I didn't investigate more such power isn't really necessary. I think, in most cases we are only interested in answers of the question is attribute X there?, does attribute X has the value Z?, is this parent-child relationship correct?, or does the expected text show up? If whitespace doesn't matter (in most cases it won't), the XML output could be either a) investigated with an XPath expression, or b) normalized and a normal diff applied. I guess it would be a lot faster than any XML diffs. ;) Apart from this technical implementations, I'm more interested in the overall structure. What would be a good test environment for stylesheet customizations? Or even the DocBook stylesheets itself? It seems to me, the XSLT 1 stylesheets are used a lot and they won't be replaced soon by the XSLT 2 incarnations. If useful and technical possible, why not define/recommend/add some test environment to help contributors and developers? :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Multiple Languages in one DocBook Document
Hi, ok, lets assume, we have an article. Its main language is in English. Furthermore, our document needs some paragraphs in a different language. The natural way would be to use the lang attribute like in the following excerpt (DocBook 4.5): - article lang=en titleLanguage Test/title para lang=deDies ist ein deutscher Absatz./para para lang=arهذه هي الفقرة العربية./para /article - Transforming* the above document into XSL-FO leads to the following fo:block structures: fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2emDies ist ein deutsches Zitat/fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2em هذه هي الفقرة العربية./fo:block I would have expected to see a language attribute (and perhaps a writing-mode as well). Unfortunately, it's not there. As such, in the German and Arabic paragraph English hyphenation rules are applied. This is obviously not correct. :) I tried a sect1 element with a lang attribute with the same result. Looking into the FO stylesheets, I identified some spots which I would consider it as fishy: 1. fo/param.xsl, parameter writing.mode Its default value is taken from the language file by using the gentext template. However, the lang argument is set to /*[1] which is valid for a document with one main language. Unfortunately, this value does not help when using multiple languages. 2. fo/block.xsl, template match=para The para template does not contain any code which would add the missing language or writing-mode attributes. I tried it also with the latest snapshot release (28-Sep-2014 17:02, r9945) but the results are the same. Could someone confirm or extend my analysis? Does someone know what goes wrong here? :) * Used 1.78.1 of the DocBook XSL stylesheets libxml2: 2.9.1 libxslt: 1.1.28 -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Multiple Languages in one DocBook Document
Hi Bob, Am Dienstag, 14. Oktober 2014, 08:35:44 schrieb Bob Stayton: While there is code in the HTML stylesheets to handle @lang down the element level, no such code was ever added to the fo stylesheets. The lang attribute and writing-mode are only used at the document level in fo. Thanks for confirming my observation. :) At this point I would consider this to be a bug, so please go ahead and file a bug report on the DocBook SourceForge site. I don't see an easy fix for it, though, because a lot of templates for elements will have to be modified. Find my bug report here: https://sourceforge.net/p/docbook/bugs/1345/ It would be nice if we could fix that. I could easily change the para template. However, as you've indicated, it would be much more work for other elements to correct it. Thanks for your answer! :-) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] support for xpointer
Hi Stefan,
On Fri, 19 Sep 2014 09:53:33 -0400
Stefan Seefeld ste...@seefeld.name wrote:
[...]
Ideally I would like to be able to encode the query in an attribute,
much as I would have preferred with xpointer, such as
listitem my:ref=*[@xml:id='foo']//d:listitem /
However, I can't manage to extract the above ref into a variable and
concatenate that into a valid xpath expression inside a custom
stylesheet:
xsl:template match=*[@my:ref]
xsl:variable name=ref select=@my:ref /
xsl:variable name=content select=document('dict.xml')//$ref /
...
/xsl:template
It seems I'm misunderstanding something, as no matter how I spell the
above, I get XPath errors from xsltproc.
Yes, as you try to dynamically evaluate a string as an XPath
expression. This is not possible with standard XSLT 1.0 and 2.0.
However, you could look into the dyn:evaluate() extension functions from
the EXSLT initiative:
http://exslt.org/dyn/functions/evaluate/index.html
You may try this, although I haven't tested it:
xsl:template match=*[@my:ref] xmlns:dyn=http://exslt.org/dynamic;
xsl:variable name=ref select=dyn:evaluate(@my:ref) /
xsl:variable name=content select=document('dict.xml')//$ref /
...
/xsl:template
Unfortunately, very few XSLT 1.0 processors implement dyn:evaluate().
It works in xsltproc, but it's unlikely it will work for Saxon.
[...]
--
Gruß/Regards,
Thomas Schraitle
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Fwd: Thanks!
Hi Frank, On Fri, 5 Sep 2014 08:58:54 + Wegmann, Frank frank.wegm...@softwareag.com wrote: [...] We use them for producing PDF files in large volumes, deploying DocBook as an intermediate format generated from our in-house XML dialect. Now we want to step up and replace our HTML offering with WebHelp. As far as I understand it and tested it, the WebHelp stylesheet works well for a single DocBook file. But here’s the catch: our documentation sets often consist of many “modules” resulting in as many DocBook files (and as many PDF files), but to produce a single WebHelp for all of them it seems the only way is to wrap all DocBook files into a single set. Is that correct? Because I feel this is not really an option, since some sets comprise several thousand pages and we might run into serious performance trouble. Alternatively I thought about enriching our current HTML production by pointing the webhelpindexer to a completely pre-generated HTML set. This way also has some considerable drawbacks: we would have to make many changes to our stylesheets to make this WebHelp feature fit for HTML (and there’s the navigation help as well). On the other hand, we forego producing DocBook, but, as said, we do so for getting PDF out of the door anyway... Maybe DocBook's olink feature is an option for you, see here: http://sagehill.net/docbookxsl/Olinking.html »When writing technical documentation, it is often necessary to cross reference to other information. When that other information is in the current document, then DocBook provides support with the xref and link elements. But if the information is in another document, you cannot use those elements [...] The olink element is the equivalent for linking outside the current document. It has an attribute for specifying a document identifier (targetdoc) as well as the id of the target element (targetptr). The combination of those two attributes provides a unique identifier to locate cross references. These attributes on olink are available starting with the DocBook XML DTD version 4.2.« With olinks you don't need a set necessarily and performance issues are also not important. I guess Webhelp does support olinks too as it is derived from the HTML stylesheets. However, I'm not sure, so you better try it out. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Using topic and assembly - starting from article?
Hi Phillip, On Tue, 19 Aug 2014 21:31:44 +0100 Phillip Kent phillip.k...@gmail.com wrote: Dear Thomas, thanks for the summary. The functionality is even better than I thought. I will try it out and will be pleased to feed back any insights to the list... You may add this to your research project too: http://doccookbook.sf.net/html/en/dbc.structure.assemble-topics.html :)) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Using topic and assembly - starting from article?
Hi Phillip, On Tue, 19 Aug 2014 11:01:24 +0100 Phillip Kent phillip.k...@gmail.com wrote: can someone give me a steer about this... I currently have a collection of standalone documents, each is a DocBook article . I want to organise these into a more structured form, particularly so that I can get them all to come out in a single PDF document (grouped into super-topic chapters/sections...). The topic and assembly elements in DocBook 5.1 look ideal for that purpose. Is that correct? If you want to use assemblies, then yes, the assembly element is correct. Your standalone resources does not necessarily need to be topic elements. Basically, it can be any DocBook element. However, there may be other restrictions, not technical ones, that impose a certain element (styleguide, structural, etc.) If yes, how can I move from article to topic? I want one article to become one topic, I don't need to chunk them into smaller parts. Could I simply replace article by topic in each xml file and nearly everything will work without further editing? Well, this could be one solution, but a very impractical one. ;) However, with assemblies this is not necessary anymore. You can keep your documents as standalone articles, but at the same time render them as topics (or chapters, or whatever you want them). First, you need to identify all your resources. Add them to the resources element and define an unique xml:id for this. For example: resources xml:base=tutorial/ resource xml:id=tut1 href=tut1.xml/ resource xml:id=tut2 href=tut2.xml/ resource xml:id=tut3 href=tut3.xml/ /resources Let's assume, each of the above resources are standalone articles. It's the same situation that you face currently. Second, let's further assume you want to create a book from your articles, but don't want to change them. In that case, a valid book consists of chapters so you can rewrite+1 your articles into chapters. This is done by the output element: structure xml:id=user-guide output renderas=book/ module resourceref=full-toc/ module resourceref=tut1 output renderas=chapter/ /module module resourceref=tut2 output renderas=chapter/ /module module resourceref=task1/ module resourceref=tut3 output renderas=chapter/ /module module resourceref=task4/ module resourceref=index/ /structure (The other resources like full-toc, task1, etc. are not relevant for this discussion.) To create the real structure (The Definitive Guide named it realized structure) apply the assembly stylesheet. The above example is an excerpt from the original DocBook 5.1 TDG, see http://www.docbook.org/tdg51/en/html/ch06.html Hope that helps and I wasn't too wrong about this topic. :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Bug: Missing profile-chunk-code.xsl for XHTML?
Hi Bob, Am Donnerstag, 22. Mai 2014, 11:05:17 schrieb Bob Stayton: This looks like a bug to me. It isn't just the snapshots, it is the same in 1.78.1/xhtml. It must happen when the xhtml is generated during the build. Can you please file a bug report so this can get cleared up? Sure, find it here: https://sourceforge.net/p/docbook/bugs/1335/ BTW, you said: The profile-chunk-code.xsl is missing in profile-chunk.xsl! However, in SVN the corresponding line is there. But the SVN directory for xhtml does not have profile-chunk.xsl because it is generated during the build. That directly has only three files in it in SVN. Can you clarify? My bad. You are right, I forgot the XHTML is generated. It was a problem in my SVN working directory. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB: dbtimestamp PI in pubdate or date
Hi, On Mon, 19 May 2014 19:14:01 +0200 Jirka Kosek ji...@kosek.cz wrote: Using profiling just to avoid a conceptual issue in the stylesheet(s) is not the cure, but adds additional burden. :) You will just import different base stylesheet. I know, but... :) Well, currently we don't have an official blessed profile-chunk.xsl for EPUB, neither version 2 nor 3, do we? If you think it is useful, it should be added to the EPUB stylesheets to be consistent with the other formats. :) However, coming back to my original point: From my understanding, profiling is used to create other variants from a single source. Variants are text which covers different target groups (beginners, experts), different operating systems (Linux, Mac, Windows), or something else text related. To get it right, you say, an output format is just another variant of the document, right? For me it's a different thing and I try to avoid variants which belongs to output formats. I think you stretch the paradigm of the stylesheets a bit too much by saying use profiling for generating EPUBs. Profiling is not required to build all the other formats, be it HTML, FO, or manpage (and others as well). Only EPUB is different in this list. Doesn't it tell us something? If you deviate the generation of EPUBs, the handling will be inconsistent to all the other formats. From my perspective, this is not very userfriendly. In my opinion, there are some things that I don't like: * Our users has to know not to use chunk.xsl but profile-chunk.xsl (which doesn't exists ATM by the way) Do they remember all the time the correct stylesheet? * Markup needs to contain the right attributes and structures to do the right thing. Does it have an official blessing? Where is it documented? * Customization is made a little bit harder as you have to take profiling into account too You wouldn't recommend to use profiling for just selecting the right image, would you? ;) If you use different images for HTML and EPUB I probably would. Why? There is no need for that: You can use the mediaobject and put a role=html or role=epub in imageobject: mediaobject imageobject role=html imagedata fileref=foo.png/ /imageobject imageobject role=epub imagedata fileref=bar.png/ /imageobject /mediaobject No profiling needed; different images for different output formats. :) What cases do you have in mind? If there are more use cases, maybe this is an indication that we really need a best practise. In EPUB you have different ISBN then in printed version of your book, some other parts of content has to be adjusted -- for example colophon. Well, not necessarily. We use *single source* for a reason! :) Actually we don't write specific things for a specific output format. Don't think a colophon or a simple ISBN number qualifies it to use profiling. For example, I have a customer and it is usually a good idea to include *all* ISBN numbers into the product, regardless if it is EPUB or a printed version. A colophon can be written that it can be used for every format, not only for one specific. Which *could* be a better way of advertising all the different output formats, but that's a different story. Sure, everybody has to decide which one is better for his use case. However, as most users have a customization layer anyway, it could be appropriate to do small things in it (like selecting the right ISBN for EPUB from a set of different ISBNs). By the way: DocBook 5.1 contains the nice outputformat attribute for such purpose. It is not included (yet?) in DocBook 4. ;) [...] Well, then easiest solution is to provide template for populating EPUB field. By default it can put current date into an EPUB file and user can override it to use different date or populate date dynamically from source and format it into xs:date format. Can we the populating EPUB field task done in our EPUB stylesheets? :) What about the following solution? date ?dbtimestamp format=Y, m? ?dbtimestamp format=Y-m-d output=epub? ?dbtimestamp format=m (Y) output=fo? /date That's messy and hard to process as PI's pseudo-attributes are not easily accessible in XPath. Well, messiness is in the eye of the beholder, I would say. ;) As with the PI's pseudo-attribute: yes, XPath can't access it nicely. However, I've played around a bit and it seems possible. Then your life and requirements are easy :-) Sometimes. :) We should keep it simple and do the magic in our stylesheets, without any profiling involved or required for this issue. Profiling is also magic hidden in the stylesheets. Yes, it's hidden. And magic. ;) See above. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Permalinks resources
Hi Scott, On Tue, 20 May 2014 10:16:58 +0300 Scott Rifenbark srifenb...@gmail.com wrote: [...] I put that use.id.as.filename in my customization layer as follows: ?xml version='1.0'? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns= http://www.w3.org/1999/xhtml; xmlns:fo=http://www.w3.org/1999/XSL/Format; version=1.0 xsl:import href= http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl; / [...] I tried making the document using 'select=1' as well as 'select=0'. I it had no effect on my generated HTML. Sorry, my bad, I had to be clearer with my text. You used the docbook.xsl stylesheet. This generates always *one* file, regardless of the use.id.as.filename parameter. Use chunk.xsl instead of docbook.xsl and you will see the effect. If you need more information how to influence such chunks, I kindly recommend Bob's book to you: http://www.sagehill.net/docbookxsl/Chunking.html Granted, I don't know if I am using this parameter correctly or not. I am by means an XSL person. No problem. :) We are here to help each other. I don't know if this will help you when you are looking at your stylesheet but here are two (hand-formatted) snippets of the HTML showing when I try to implement the permalinks and when I do not. In the top one, which attempts to implement them, my a tag is basically blank with no value for the id, which I consistently use in my .XML source files for all section tags. The actual text title is also being dropped. Thanks for the feedback, I will look into this issue. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Bug: Missing profile-chunk-code.xsl for XHTML?
Hi, it seems I found a bug. I've downloaded the latest archive of the DocBook stylesheets from http://snapshots.docbook.org/ (file docbook-xsl-snapshot.tar.bz2, 15-May-2014 17:02). Compare the output of html and xhtml: $ cd html $ diff -u chunk.xsl profile-chunk.xsl [...] -xsl:include href=chunk-code.xsl/ +xsl:include href=profile-chunk-code.xsl/ Ok, this makes sense. Now compare it to xhtml: $ cd ../xhtml $ diff -u chunk.xsl profile-chunk.xsl [... unimportant stuff deleted ...] The profile-chunk-code.xsl is missing in profile-chunk.xsl! However, in SVN the corresponding line is there. Interestingly, the other XHTML stylesheets (xhtml-1_1 and xhtml5) contain this line! I guess this has something to do how xhtml is generated from html. Could someone confirm or reject my analysis? Any ideas? -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB: dbtimestamp PI in pubdate or date
Hi Jirka, Am Samstag, 17. Mai 2014, 20:14:31 schrieb Jirka Kosek: [...] I think that instead of using . we should call apply-templates, so ?dbtimestamp? is processed. Something like: xsl:template match=date|pubdate mode=opf.metadata xsl:variable name=content xsl:apply-templates/ /xsl:variable xsl:variable name=date xsl:call-template name=format.meta.date xsl:with-param name=string select=normalize-space($content)/ /xsl:call-template /xsl:variable Thanks Jirka for your idea. However, I think this is only one part of the solution. :) We have a conceptual issue here IMHO. Lets consider this use case: someone wants that the date on his titlepage should appear as May 2014. Perfectly fine. I would say! He can insert it directly inside a date or pubdate if it should be a fixed date. Or he could use the dbtimestamp PI and let the current date calculated through the stylesheets. With the above change, both ways work. Whenever our user creates HTML or FO/PDF, all is fine. No warnings, everything as expected. However, if he creates an EPUB, suddenly the date or pubdate falls apart with the known warning message. What can our now unhappy user do? He can withdraw his own date format and is forced to use a format that he never wanted, just to be consistent with the EPUB spec. Or he can change date or pubdate whenever he creates an EPUB, also forced by switching back and forth. Both options are not very nice IMHO. It contradicts our use *one* source, create multiple formats paradigm. My hope would be that the user can use whatever format or string he wants in date or pubdate and *all* formats work. This is currently not the case and I think it's a deficiency. After thinking a bit about this issue, I see the following possible solutions: 1. Use pubdate or date for titlepage, use a separate format for EPUB Internally, the correct format is used. However, it gets always the current date. Maybe it is not what the user wanted. 2. Use heuristic approach to detect format and assemble it for metadata I guess, it needs a clever approach to detect what is a year, month and day. Can also have localization issues. Probably works only in certain cases. 3. Detect an additional pubdate or date with role=epub This could solve the issue as both formats can live happily together. We used this approach also for imagedata which belongs to certain output formats. However, we need to define what to do when no 2nd pubdate or date is available. 4. Extend dbtimestamp PI with an additional output=epub Only one pubdate or date is used, but inside there are two (or more) PIs with refers to a certain output format. The stylesheet could pick the correct PI for a specific output. 5. Anything else...? I think options (3) and (4) are the best approaches at the moment. What do you prefer? Thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB: dbtimestamp PI in pubdate or date
Hi Jirka, Am Sonntag, 18. Mai 2014, 18:19:51 schrieb Jirka Kosek: On 18.5.2014 14:42, Thomas Schraitle wrote: 3. Detect an additional pubdate or date with role=epub This could solve the issue as both formats can live happily together. We used this approach also for imagedata which belongs to certain output formats. However, we need to define what to do when no 2nd pubdate or date is available. You can achieve this today with profiling, I'm not sure whether there is any need to standardize this behaviour. Yes, I thought about profiling too, but didn't add it to the list. In my opinion, it's a bit too much: Using profiling just to avoid a conceptual issue in the stylesheet(s) is not the cure, but adds additional burden. :) This issue is exactly the same than selecting the right image format in the mediaobject/imageobject elements by using a role attribute. No profiling is involved and the stylesheets just select the respective image format correctly. You wouldn't recommend to use profiling for just selecting the right image, would you? ;) In my opinion, date formats and image formats are very similar concepts in how the correct result is selected. For image formats, there is a best practise for years, it's stable, well documented, and all stylesheets support it. This is not the case for date formats in EPUB. At least I'm not aware of it. Maybe not all users create EPUBs and run into this problem. I do. EPUB validation always fails due to this issue. The EPUB stylesheet doesn't work out of the box. For that reason, I would really vote for a best practise, standardization or recommendation, similar to what we have for imageobjects. There are dozen of similar cases and there is no direct support for them as well. What cases do you have in mind? If there are more use cases, maybe this is an indication that we really need a best practise. I think that for EPUB we can just document the following best practice: date condition=noepub?dbtimestamp?/date date condition=epub?dbtimestamp format=Y-m-d?/date Well, maybe, maybe not. Whatever we prefer, I think we have to distinguish two cases in EPUB: 1. The date, probably somehow/somewhere definied by the user, which appears on a titlepage. 2. The date inside any meta information, usually hidden for the user. This is required by the EPUB specification. For (1) the user can choose whatever he likes. There is no restriction. However, for (2) the EPUB demands a YEAR-MONTH-DAY format. Either the user defines it manually or he lets the stylesheet(s) do the correct output. Unfortunately, usually (1) is different than (2). In my opinion, it's the task of the stylesheets to do the right thing. :) If the user did the wrong thing (whatever it will be), the stylesheet should warn the user and give a hint. The hint should contain the preferred markup. I'm not sure if two (or more) dates are a good solution. After thinking a bit more, I would prefer _one_ date without any profiling attributes. The reason for this is, no profiling attributes mean no conflicts with user semantics. I would avoid such things and better leave this detail to PIs. What about the following solution? date ?dbtimestamp format=Y, m? ?dbtimestamp format=Y-m-d output=epub? ?dbtimestamp format=m (Y) output=fo? /date No profiling attribute is needed, the user can still add a condition attribute if he needs it. When the EPUB stylesheet needs a date, we prefer the 2nd line for both titlepages and meta information. Another idea could be we use the 2nd PI for meta information and the 1st PI for the titlepage. Whatever it will be, we should clearly define it. Profiling adds just another layer of complexity which I would prefer to avoid. Anyway, if you are producing EPUB and other targets it is very likely that you are already using profiling. Hope you didn't mind, but I have to friendly disagree. :) No, I don't use profiling when I create my EPUBs. ;) Nor for other formats. Building EPUBs and other formats doesn't involve necessarily a profiling step. By no means it should be required. Remember, profiling is an _optional_ step! It's an additional feature: sure, in some cases you need it, in other you don't. We should keep it simple and do the magic in our stylesheets, without any profiling involved or required for this issue. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] EPUB: dbtimestamp PI in pubdate or date
Hi,
currently, I'm investigating EPUB(3) and dates in pubdate.
It's not unusual to have the following pubdate inside an info, using the
default date format:
pubdate?dbtimestamp?/pubdate
This works for HTML, FO, etc. except for EPUB. For EPUB, you get:
WARNING: wrong metadata date format: '' in element bookinfo/pubdate. It must
be in one of these forms: , -MM, or -MM-DD.
Well, I think the message is correct as there is really no text. It doesn't
help to add a format pseudo attribute here:
pubdate?dbtimestamp format=Y, m d?/pubdate
This would lead to the same message.
Digging deeper into the EPUB3 stylesheets, I assume the dbtimestamp PI isn't
supported at all. The pubdate is used as OPF metadata in the following
template:
xsl:template match=date|pubdate mode=opf.metadata
xsl:variable name=date
xsl:call-template name=format.meta.date
xsl:with-param name=string select=normalize-space(.)/
/xsl:call-template
/xsl:variable
!-- ... ---
/xsl:template
However, format.meta.data just checks if the given text is in the right
format. If not, it displays the above warning message.
Now I'm wondering if this is the right approach. 8-) Shouldn't we distinguish
between two cases:
1. date or pubdate contains only text
We need to check, if the text is a valid date in the format needed by EPUB
2. date or pubdate contains no text, but ?dbtimestamp?
We ignore any format pseudo attribute and return a date in the format
Y-m-d
I would propose the following change:
xsl:template match=date|pubdate mode=opf.metadata
xsl:variable name=date
xsl:choose
xsl:when test=processing-instruction('dbtimestamp')
xsl:call-template name=pi.dbtimestamp
xsl:with-param name=formatY-m-d/xsl:with-param
/xsl:call-template
/xsl:when
xsl:otherwise
xsl:call-template name=format.meta.date
xsl:with-param name=string select=normalize-space(.)/
/xsl:call-template
/xsl:otherwise
/xsl:choose
/xsl:variable
!-- ... ---
/xsl:template
Unfortunately, this won't work. The pi.dbtimestamp template doesn't allow a
parameter format. Looking into the template xsl:variable is used.
Could we change pi.dbtimestamp and use xsl:param instead of
xsl:variable? Or is there another solution that I can't see?
What do you think?
--
Gruß/Regards
Thomas Schraitle
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] How to set the odd and even page into different layout
Hi, On Tue, 11 Feb 2014 16:33:33 +0800 Mona Qi qizilan.scut...@gmail.com wrote: I'm trying to modify the page layout of my pdf. My attempt is letting the whole content in odd page (including header and footer) keep right, and let the content in even page keep left, so when i bound the pdf into a book, the content is more easier to read. I think this may related to the page master and page margin, but i don't know how to select the odd/even page and set the attribute correctly. It's easier than you think. :) Do you know the parameter double.sided? Set it to the value of 1 and it gives you exactly what you want: an odd and even page with mirrored headers, footers, and margins. For more details, see the reference page of double.sided: http://docbook.sf.net/release/xsl/current/doc/fo/double.sided.html If you need more information that goes beyond the above parameter, look into Bob's book, chapter 8 Printed output options: http://sagehill.net/docbookxsl/PrintOutput.html#PageLayout -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] db4-upgrade.xsl dropping
Hi Dick, Am Sonntag, 3. November 2013, 19:26:36 schrieb XML Press: I could be wrong (I'm away from my desk and writing this on my phone), but I think the reason is that parameter may not be legal inside term in 5.0. I've checked the reference of parameter[1]: term allows the parameter element (version 4 and 5). [1] http://www.docbook.org/tdg5/en/html/parameter.html -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] db4-upgrade.xsl dropping
Hi Jon, Am Sonntag, 3. November 2013, 01:34:03 schrieb Jon Leech: [...] If I try your document with version 9783 it works. Thank you. That does help with this particular problem but introduces a new one: varlistentry elements containing e.g. termparameterx/parameter/term in the DB4 source are converted to termx/term I can confirm your analysis. The changes between the revs 7660 and 9783 of db4-upgrade.xsl were large and it's not easy to figure out why this behavior change occurred, given my limited understanding of XSL. I suspect I'll be better off accepting the issues from one or the other version and fixing them up after the translation. The DocBook schema allows these elements inside term. So if the stylesheet doesn't handle these elements correctly, it's a bug. Could you add the following 3 lines into the latest db4-upgrade.xsl stylesheet and try it again? - xsl:template match=* mode=clean-terms xsl:apply-templates select=. mode=copy/ /xsl:template - (You can add it below the xsl:template match=glossterm|term template rule). The above template rule just copies any element inside term unless it is a classsynopsis, cmdsynopsis, or any other special element. These are handled differently. If it works for you, I can update the stylesheet in the SVN repository. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] db4-upgrade.xsl dropping
Hi Jon, Am Sonntag, 3. November 2013, 13:11:25 schrieb Jon Leech: [...] If it works for you, I can update the stylesheet in the SVN repository. Thank you, Thomas! That lets through the various legal elements within term and so seems to solve all the issues I've encountered to date with the conversion. I did ask the Debian docbook5-xml package maintainers to sync up with the Docbook top-of-trunk release, so hopefully the prepackaged version will eventually get up to date as well. Ok, thanks for your test. I've committed the patch[1] to the DocBook SVN repository now, it's in revision 9828. [1] http://sourceforge.net/p/docbook/code/9828 -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] db4-upgrade.xsl dropping
Hi Jon, Am Samstag, 2. November 2013, 03:08:33 schrieb Jon Leech: [...] the resulting Docbook 5 file drops the title element from the refsynopsisdiv section (but not from the converted refsect1 section). [...] # Release: $Id: db4-upgrade.xsl 7660 2008-02-06 13:48:36Z nwalsh $ This is a very old version. The current version is: # Release: $Id: db4-upgrade.xsl 9783 2013-08-21 21:40:54Z rlhamilton $ If I try your document with version 9783 it works. I would recommend to download the stylesheet directly from the SVN repository and try it again. You can find the file here: https://svn.code.sf.net/p/docbook/code/trunk/docbook/relaxng/tools/db4-upgrade.xsl -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Alt text not appearing in inlinemediaobject
Hi David, Am Dienstag, 29. Oktober 2013, 11:52:20 schrieb David Goss: I have the the following docbook 5 markup: paraClick the guibuttoninlinemediaobjectaltExecute/altimageobjectimagedata fileref=img/ldms/ldms_button_execute.png depth=1em//imageobject/inlinemediaobject button./guibutton/para It is outputting the following HTML : pClick the span class=guibuttonspan class=inlinemediaobjectimg src=img/ldms/ldms_button_execute.png height=13/span/span button./p I'm not sure why the alt text is not carrying over. Am I using the alt tag incorrectly or is this a bug? I'm using webhelp docbook-xsl-ns-1.78.1 . Your DocBook markup is perfectly correct. But it seems, there is a deficiancy about the handling of inlinemediaobject in the DocBook stylesheets. I suspect the html/graphics.xsl file in the imagedata template (lines 1250 - 1331). In this template rule, the process.image template is called and the alt parameter is passed. However, it is not checked against an inlinemediaobject with a possible alt element. I would propose this change: xsl:call-template name=process.image xsl:with-param name=alt xsl:choose xsl:when test=ancestor::mediaobject/alt xsl:apply-templates select=ancestor::mediaobject/alt/ /xsl:when xsl:when test=ancestor::inlinemediaobject/alt xsl:apply-templates select=ancestor::inlinemediaobject/alt/ /xsl:when xsl:otherwise xsl:apply-templates select=$phrases[not(@role) or @role!='tex'][1]/ /xsl:otherwise /xsl:choose /xsl:with-param xsl:with-param name=longdesc xsl:call-template name=write.longdesc xsl:with-param name=mediaobject select=ancestor::imageobject/parent::*/ /xsl:call-template /xsl:with-param /xsl:call-template If you would like to give it a try, do the following: 1. Create a customization layer if you haven't done yet. If you don't know how, read one of the following URLs: http://www.sagehill.net/docbookxsl/CustomMethods.html#CustomizationLayer http://doccookbook.sf.net/html/en/dbc.common.dbcustomize.html 2. Copy the imagedata template from the original html/graphics.xsl template into your customization layer. 3. Search for the xsl:call-template line and apply the above patch (add the 2nd xsl:when test). 4. Transform your DocBook document and use your customization layer. I did see this page in the XSL Guide: http://www.sagehill.net/docbookxsl/AltText.html But it looks to be for Docbook4. You can use this also in DocBook 5 as long as it is valid. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Alt text not appearing in inlinemediaobject
Hi David, Am Dienstag, 29. Oktober 2013, 14:20:29 schrieb David Goss: It looks like xsl/graphics.xsl was also missing this: xsl:template match=d:inlinemediaobject/d:alt xsl:apply-templates/ /xsl:template Adding this, along with Thomas's suggestion fixed this problem. Thanks again for your help! [...] Thanks for adding this bug to our database. I've added the patch to revision 9827. If Bob or others can confirm it, the bug can be closed. :) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Bug and Patch for broken soelim stub/ROFF links
Hi,
some of my collegues found a strange (or better unexpected behaviour)
of the manpage output.
Between 1.75.2 and 1.76.1 the following change was added:
--- /tmp/docbook-xsl-1.75.2/manpages/other.xsl 2009-02-19
19:26:36.0 +0100
+++ /tmp/docbook-xsl-1.76.1/manpages/other.xsl 2013-10-21
09:53:07.719215407 +0200
@@ -595,10 +606,11 @@
xsl:with-param name=message-prologNote: /xsl:with-param
xsl:with-param name=message-epilog (soelim
stub)/xsl:with-param
xsl:with-param name=content
-xsl:value-of select=concat('.so man', $section, '/')/
+xsl:value-of select='.so '/
This now leads to broken soelim/ROFF links. For example, if you have a
manpage foo(8) and transform your refentry document without further
parameters and customization, this leads to the following output:
.so foo.8
However, I was told this is wrong and would raise several problems
(security is one of them). The correct path should be:
.so man8/foo.8
After searching a bit, I've found a bug[2] entry in your DocBook
tracker. It seems quite similar.
I've played around and I could get the last output by setting the
parameters man.output.in.separate.dir to 1 and man.output.base.dir to
. Not sure why this is not the default. Any reasons?
Well, after more searching, I've found a patch in the Fedora stylesheet
package[2] which seems to be from the year 2011. I don't know why it is
not included. This patch does the right thing and outputs always the
correct path fragment.
Can we include this patch? Any further background information?
-- References
[1] https://sourceforge.net/p/docbook/bugs/1313/
[2]
http://pkgs.fedoraproject.org/cgit/docbook-style-xsl.git/tree/docbook-xsl-mandir.patch
--
Gruß/Regards,
Thomas Schraitle
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] xmpp.xsl file?
Hi Jen, On Wed, 9 Oct 2013 13:45:55 +0300 Jen jen...@gmail.com wrote: Thanks for the clarifications and the quick replies. The inline.xsl,component.xsl and titlepage.xsl that are being imported are (very) different versions of the standard files. I *am* planning use DocBook 5 and the namespace version of the stylesheets, so your tips are very useful. I'll try to adapt all the custom stylesheets we have right now and see if the transformation still works... fingers crossed. If you need some inspirations or ideas about how to write customization layers, you may find this information probably helpful: http://doccookbook.sf.net/html/en/dbc.common.dbcustomize.html http://www.sagehill.net/docbookxsl/CustomMethods.html#CustomizationLayer Good luck! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Questions about IDs defined on some Docbook elements
Hi Radu, Am Donnerstag, 3. Oktober 2013, 14:29:41 schrieb Radu Coravu: Let's say in a Docbook 5 document I have a chapter title someplace like this: title xml:id=titleChapter3 - Chapter Title - Missing ID/title I cannot recommend that. Better place the xml:id on your parent chapter element. Another problem with your title: don't include any numbers (like 3, Chapter 3 etc.) as the number and the Chapter text are generated automatically. and in some other place of the document I use a link to it: link xlink:href=#titleParttitlePart/link Is there a reason why you don't use xref linkend=.../? :) In almost all cases, xref/ is the right element to create links (or better, cross references). Just invent an ID, insert it into xml:id and the linkend attributes, and the DocBook stylesheets do the rest. Pretty simple. Maybe it helps, if you get familiar with the differences between cross references and links: http://doccookbook.sf.net/html/en/dbc.markup.xref-vs-link.html If you want to customize your cross reference, here are other links: http://doccookbook.sf.net/html/en/dbc.markup.xref.html http://www.sagehill.net/docbookxsl/CustomXrefs.html From what I tested the XHTML-based outputs will never create an anchor for the titleChapter ID. I haven't tested it. Perhaps it has something to do with your misplaced xml:id. Try it as suggested above and see what happens. [...] Hope this helps. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] attribute sets -- what possible attributes can I use?
Hi Robert, Am Samstag, 14. September 2013, 10:25:53 schrieb Robert Nagle: [...] But I don't understand is what possible named attributes can be added to a single attribute set. You can add all attributes from the FO specification as long as they make sense or are allowed for a specific FO element. [...] 1. Am I correct in assuming that it's possible to add other attributes here which are not mentioned? Sure. For example, you could change the text color, background color, borders, indentation etc. As said, everything from the FO specification. 2. Where can I find a list of possible values which can be used for each (or all) attribute sets? As a starter, you could look into the FO specification itself: http://www.w3.org/TR/xsl/#pr-section Skip the Common Aural Properties as they usually doesn't make sense (and are also not supported in most FO formatters). Keep in mind, not all FO formatters support every FO attribute. I know it has something to do with xsl-fo, and actually I have a copy of Dave Pawson's XSL-FO book lying around, but other than that, I don't really have a clue where to start. As the XSL-FO specification is based on CSS, you will find lots of overlap between FO attributes and CSS rules. This is intentional and you can use that to look into the CSS specification, tutorials, and other examples. Of course, not all CSS rules are applicable to FO, but the details are shown in the FO spec. Apart from that, most FO formatters have also tutorials or other useful information. Here is a short, but not exhaustive list: http://wiki.apache.org/xmlgraphics-fop/FrontPage http://www.renderx.com/tutorial.html http://antennahouse.com/XSLsample/XSLsample.htm Good luck! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Appending image after xref (TOC vs. xref-to-suffix mode)
Hi, On Thu, 12 Sep 2013 10:00:48 -0700 Bob Stayton b...@sagehill.net wrote: [...] I think you are understanding it correctly, and this seems to be a deficiency. I agree that the xref-to-suffix and xref-to-prefix modes should get the referrer element as a param, as well as xrefstyle like xref-to does. Ok, I've submitted the change to r9805. Now, the xref-to-suffix and xref-to-prefix modes have the same signature than xref-to. I think, this should solve the referrer issue. Please check if this is correct. :) However, the problem with the TOC still persists. Can this be avoided somehow? Thanks! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Bibliography vs. olinks
Hi Alexey, On Thu, 12 Sep 2013 09:28:28 -0700 Alexey Neyman sti...@att.net wrote: Yes, I've tried jing too and it worked, although I am a little bit concerned that it didn't have any development activity since, I believe, 2008. Yes, it's looks a bit outdated. Don't know if this is really the case. And, being a Java tool, it was considerably slower than xmllint - I wanted to avoid adding another Java tool in our toolchain unless absolutely necessary. Hmn, probably yes, but I didn't recognize any speed issues with Jing. Even if I validate an extensive book it's incredibly fast. But RNG validation was not the only issue we've faced with DB5 and libxml2: we also actively use entities, and libxml2 currently loses namespace declarations when it goes from parsing the main document into parsing an entity. [...] Urgs. Seems to be a blocker to me. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Appending image after xref (TOC vs. xref-to-suffix mode)
Hi, I'm struggeling about the xref-to-suffix mode and how to use it correctly. Let's assume I would like to append some image for all xref/s. One solution could be to customize the xref template and insert the image there. Depending on what you need and where, this could be more work than it need to be, so I would like to avoid this. Another solution could be to to write a template for the xref-to-suffix mode (which does nothing by default): xsl:template match=* mode=xref-to-suffix !-- Add an image here -- /xsl:template This works and would be exactly what I need. However, the image appears also in the TOC. How can I avoid this? I would like to have the image only inline inside paras. Another issue: If I understand it correctly, when I'm inside the xref-to-suffix mode the current node is the target node (the element being referenced). This confirms the following snippet from the xref/ template: xsl:when test=$target xsl:if test=not(parent::citation) xsl:apply-templates select=$target mode=xref-to-prefix/ /xsl:if xsl:apply-templates select=$target mode=xref-to xsl:with-param name=referrer select=./ xsl:with-param name=xrefstyle select=$xrefstyle/ /xsl:apply-templates xsl:if test=not(parent::citation) xsl:apply-templates select=$target mode=xref-to-suffix/ /xsl:if /xsl:when So, if I need the @linkend from the xref for some reason, I have no chance to get it, right? It seems, the xref-to-prefix and xref-to-suffix modes need a referrer parameter as well as the xref-to mode. Or do I miss something? Thanks! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Bibliography vs. olinks
Hi Alexey, On Mon, 9 Sep 2013 10:47:42 -0700 Alexey Neyman sti...@att.net wrote: Yes, we are using DocBook 4 at this time; we've tried to move to DB5 but decided against it for now - primarily because of libxslt's issues with RelaxNG validation and namespace handling issues. You mean probably libxml2/xmllint (the XML parser) which have issues, not libxslt/xsltproc (the XSLT processor). :) I know some problems with xmllint's RNG validation -- it never worked for me. For this reason, I use Jing which gives you far better validation results. Try Jing instead of xmllint. :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook 5 samples for tests
Hi Camille, Am Mittwoch, 21. August 2013, 18:42:28 schrieb Camille Bégnis: there is an extensive set of samples in DB4, but I cannot find a DB5 version, does it exist? I don't think so there are DB5 samples in the DocBook SVN. I'm looking for it to stress test our Calenco CMS (http://www.calenco.com) You could use Norman's DB5 files from his XSLT 2.0 stylesheets: https://github.com/docbook/xslt20-stylesheets If you are looking for more real world examples, use the sources from my cookbook: http://sourceforge.net/projects/doccookbook/ Good luck! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Status of the XSLT2 DocBook Stylesheets?
Hi, if I'm not mistaken, the XSLT2 DocBook stylesheets are maintained on Github[1]. There is another page[2] where it's mentioned a date of November 2011. Are they still maintained? Thanks! [1] https://github.com/docbook/docbook.github.com [2] http://docbook.github.io/ -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Status of the XSLT2 DocBook Stylesheets?
Hi, On Fri, 26 Jul 2013 10:23:38 +0200 Jirka Kosek ji...@kosek.cz wrote: [...] I think you are looking for: https://github.com/docbook/xslt20-stylesheets Ahh, right. With all the forks here and there it's sometimes confusing. ;) Thanks Jirka! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Assemblies in DocBook 5.1: generating multiple structure outputs using assemble.xml
Hi Graeme, On Wed, 22 May 2013 14:45:44 +0100 gra...@heliocentrik.net wrote: [...] When I run assemble.xml (version v 1.10 2012-04-10 07:56:58 from the latest stylesheets), I'm invoking it like this: xsltproc ~/docbook-xsl/assembly/assemble.xsl assembly-file.xml In the output, I get the article element for 'article1', but 'book1' and 'book2' are ignored. Have you tried the parameter structure.id? The assemble.xsl stylesheet contains the following comment: May be used to select one structure among several to process Perhaps you should try the structure.id parameter like this: xsltproc --stringparam structure.id book1 \ ~/docbook-xsl/assembly/assemble.xsl assembly-file.xml Hope that helps. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook XSL snapshots are back
Hi, On Tue, 7 May 2013 12:23:24 -0700 Bob Stayton b...@sagehill.net wrote: The DocBook XSL snapshot builds are working and available again: http://snapshots.docbook.org/ Thanks to David Cramer for fixing the filesystem problem on the snapshot build machine. Great work, thank you all for your efforts! :) I don't want to sound like I'm splitting hairs, but I have noticed a few minor things: * The for revision , text is missing a revision number * In former times, the Latest Changes part contained the contents of the LatestChanges file. Just to let you know. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] dbtoepub is broken on latest docbook-xsl-ns-snapshot
Hi Shlomi, On Wed, 8 May 2013 14:08:59 +0300 Shlomi Fish shlo...@shlomifish.org wrote: This still happens with the latest snapshot: 1. $ tar -tvf ~/docbook-xsl-ns-snapshot.tar.bz2 | grep xhtml-1 | wc -l 0 2. sha256sum gives me: f6ab45400273992f0dc2d5bf769abc1f77315a941b73d069562d182075041faf /home/shlomif/docbook-xsl-ns-snapshot.tar.bz2 3. Dated from 8-May: You've used the namespace aware version. Have you tried the non-namespaced version? Download the docbook-xsl-snapshot.tar.bz2 and try again, please. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] DocBook snapshot SVN problem
Hi Bob, Am Freitag, 3. Mai 2013, 09:25:43 schrieb Bob Stayton: svn: Write-lock stolen in 'contrib/tools/pawson' I get this error only on the snapshot machine, not my home machine. So I think it is a problem with the snapshot machine's working copy. Anyone know how to fix this? I could probably check out a new working copy, but that takes awhile and I would rather fix it with some kind of unlock command. Maybe a corrupted filesystem? Not sure what system you use, but I found this: http://svn.haxx.se/users/archive-2004-06/0001.shtml Try running a check program. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] EPUB2-Bugfixing
Hi, if I'm not mistaken, the EPUB2 stylesheet isn't really maintained anymore. Although there is EPUB3 available, I think there is still a place for a good and stable EPUB2 solution. Especially if some publishers still require the older version. To cut a long story short: I would be happy to add/submit some bugfixes and implement some missing features (like support for admonitions). However, I don't want to create any conflicts or problems so I hope nobody objects if I do so. :) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB2-Bugfixing
Hi, On Tue, 30 Apr 2013 08:56:16 +0200 Thomas Schraitle tom_s...@web.de wrote: [...] However, I don't want to create any conflicts or problems so I hope nobody objects if I do so. :) Seems it's a bit early this morning. Sounds ambiguous. Read it more like ... hope nobody objects if I submit some patches. :-) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] JFYI: Observations on snapshots.docbook.org and SVN Commits
Hi Bob, On Mon, 29 Apr 2013 09:17:45 -0700 Bob Stayton b...@sagehill.net wrote: Something is definitely going wrong with the snapshot builds, but I haven't had time to investigate. It may be related to the changes to SVN that SourceForge is making. Ok, thanks for your efforts. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] JFYI: Observations on snapshots.docbook.org and SVN Commits
Hi, not sure if the project owners know this already (or are fully aware), but I've noticed that the archives on snapshots.docbook.org don't contain the latest version (again). :) Another issue: In former times, the latest change were printed below the list of archive. This isn't shown anymore. It seems, any commit doesn't create a new snapshot (or is running late). Furthermore, I've observed that each commit prints a warning message from the SVN post-commit hook. I can't remember its message, but if I remember correctly, it has something to do with the migration to SourceForge's new Allura system. Just to let you know. Thanks! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB3: how to use base.dir ?
Hi Carlos, Am Samstag, 20. April 2013, 18:16:42 schrieb Carlos Araya: After updating to the latest snapshot I'm getting validation errors that I don't know if they are epubcheck issues or if they are being caused by the change in base.dir behavior: According to the snapshots.docbook.org page, the last version is built on April 17. This looks not as the latest snapshot release. ;-) However, I've tried to transform my cookbook project into EPUB3 and received validation errors too (but they are different). But this is another story. [...] Realized earlier that I had OEBPS as the base.dir and changed it to book/ Right, that's correct now. With that change made I'm getting epubcheck validation errors that were not there before: Tip: You don't need to create the ZIP archive and pass it to epubcheck. You can start the validation process right after xsltproc wrote the directories without creating the ZIP archive. For example, if you've used foo/ as base.dir, invoke epubcheck with this option after the transformation step: $ epubcheck foo/ -mode exp It is even possible to validate only parts of the EPUB (directory), also with the -mode option: mo= Media overlays nav = Navigation document opf = package document svg = SVG content xhtml = XHTML content The -version option specifies with EPUB version to validate (the values can be either 2.0 or 3.0). epub-check: [java] ERROR: docbook-howto.epub: Length of the first filename in archive must be 8, but was 13 [java] Epubcheck Version 3.0 [java] [java] ERROR: docbook-howto.epub: Required META-INF/container.xml resource is missing [java] [java] Check finished with warnings or errors [java] I got the validations errors with both epubcheck 3.0 B5 and 3.0 final. I'm trying to determine if the errors are caused by the update to the base.dir parameter or if it's a new quirk of epubcheck that I hadn't seen before. This indeed looks strange. However, I didn't get such validation errors. I've used the last public stable release (1.78.1) and the snapshot from docbook- xsl-snapshot.tar.bz2 file, both with success. Do you use a customization layer? -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB2 vs. EPUB3: Making base.dir consistent?
Hi Am Mittwoch, 17. April 2013, 08:33:27 schrieb Thomas Schraitle: I would like to ask if it would be useful to add the same change to the EPUB2 stylesheets. As far as I can see, it would be compatible with the existing implementation, but would be a huge benefit for stylesheet writers and developers. I believe, it should be consistent between the two EPUB implementations. I took the liberty to backport Bob's changes regarding base.dir from the EPUB3 stylesheet(s) to the EPUB2 stylesheet. :) This is committed to revision 9749. It should still be compatible with the old behaviour: If you don't change base.dir, it will save all the files in the current directory. However, if you specify the parameter base.dir then all files will be written to that directory. I've tested both behaviours with epubcheck 3.0 and it hasn't complained so far. :) Would be nice, if someone could test that. Thanks! -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB2 vs. EPUB3: Making base.dir consistent?
Hi Mike, Am Samstag, 20. April 2013, 11:32:44 schrieb Mike Cook: I can't get either EPUB 2 or 3 working. I've done a fresh checkout; This will not work; if you look into the xhtml-1_1 then you will see an almost empty directory. The different XHTML stylesheets need to be generated first. That's the reason for your errors, regardless of the EPUB version. I would recommend to use the snapshot releases from http://snapshots.docbook.org. However, it takes some time to create a new snapshot release after a commit. I don't know when the next will be generated, but the last one was from 17. April. So it's a little bit old. :-] In your case, you could try the following: 1. Download the latest snapshot release from http://snapshots.docbook.org 2. Unpack the archive, let's say to /tmp. This will create the folder docbook-xsl-snapshot. 3. Copy the epub/docbook.xsl from your fresh checkout into the /tmp/docbook-xsl-snapshot/epub directory. 4. Optionally copy the epub3/ directory in the same way. 5. Test again. :) [...] Hope that helps. :) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB2 vs. EPUB3: Making base.dir consistent?
Hi Mike, Am Samstag, 20. April 2013, 13:39:41 schrieb Mike Cook: Thanks Thomas, I've merged the two together and those errors are now gone. However, I think I need to wait for the next snapshot to be generated as I'm now getting other errors. Probably, you are right. I think, the next snapshot release will fix some of the issues. EPUB3: setting base.dir to /path/book, puts all files in that book directory, but I'm getting an epubcheck3 error; Better append a / to your base.dir. ERROR: ../test.epub/OEBPS/toc.ncx(9,10): element navMap incomplete; missing required element navPoint The NCX has an empty navMap/ I think this bug was fixed already, but I'm not sure. EPUB2: is even worse: base.dir is the same as above but the folder structure is messed up; ./book ./bookMETA-INF ./bookOEBPS That's because you haven't appended / to your base.dir. The meta/config files are written, but non of the book files (chapters, titlepage, etc); they are just printed to the terminal. Maybe the correct base.dir should handle this. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] EPUB2 vs. EPUB3: Making base.dir consistent?
Hi, thanks to Bob's changes for the EPUB3 stylesheets, the parameter base.dir makes more sense. Many thanks! :) I would like to ask if it would be useful to add the same change to the EPUB2 stylesheets. As far as I can see, it would be compatible with the existing implementation, but would be a huge benefit for stylesheet writers and developers. I believe, it should be consistent between the two EPUB implementations. Opinions, thoughts? -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] using xpointer with modular DocBook
Hi Stefan, On Sun, 14 Apr 2013 20:06:45 -0400 Stefan Seefeld ste...@seefeld.name wrote: On 04/14/2013 03:24 PM, Thomas Schraitle wrote: If your variablelist has the ID foo and you want to refer to the first varlistentry you can write: xmlns(db=http://docbook.org/ns/docbook)xpointer(id(foo)/db:varlistentry[1]) Right, but that doesn't solve my problem of having to repeat the namespace declaration. :-) That's true. :-) I had mainly speed and simplification in mind than solving the namespace declaration. It could be slightly faster than using the descendant axis with //db:variablelist -- if supported by your favorite XML parser. [...] I don't think there is a general solution where you define somewhere the namespace and just refer to it. It seems, you need to add the namespace xmlns() scheme every time. That's unfortunate. I was hoping there was a mechanism such as xmlns-local() to export the namespaces from the current document into the xpointer context. I could be wrong, but I haven't seen that. As some of the XPointer specification never reached recommendation status, I would doubt there is something like a xmlns-local(). Maybe you add the xmlns() XPointer scheme before passing it to your XML parser. You could (theoretically) apply an XSLT transformation step and add the xmlns() scheme. That way you could avoid entities, however, you add an additional step (which may not be useful). I wouldn't mind the additional step, but I don't like the idea that the unprocessed document isn't valid any longer. Right, that's unfortunate. Anyway, that reminds me of DocBook assemblies: http://docbook.org/tdg51/en/html/ch06.html It is a pretty new method of splitting your document into modules and referring to with a map file (named assembly). It may not help to solve your current situation, but it would be something for the future. As DocBook 5 is (or should be) the future, I think, this would be an interesting topic. However, it seems, the current implementation doesn't support XML fragments like referring to a certain element inside a XML file or using an XPath to select specific elements. It might be worth to bring this to the DocBook committee what they recommend in this case. I've opened a new thread on the docbook mailinglist (subject: DocBook 5 Assemblies and XML Fragments). This is something I would like to know too. :)) -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB3: how to use base.dir ?
Hi, Am Donnerstag, 11. April 2013, 15:27:14 schrieb Bob Stayton: I figured out a better way to handle this. The HTML stylesheets already have an internal variable named 'chunk.base.dir' that actually used for chunking. It originally ensured that the base.dir value had a trailing slash. I've modified it for epub3 to append the value of $epub.oebps.dir, which is 'OEBPS' by default. So in the next release you can set base.dir has you usually do, and the OEBPS is automatically added for the files that need it. For those transitioning from the current version, the process will fail with an explanatory message if your $base.dir includes the OEBPS part. Then you can reset your $base.dir to omit the OEBPS part. This is great news! Thanks! I would like to suggest an additional idea: Currently, the DocBook XSL Stylesheets: Reference Documentation[1] contains all the parameters for HTML, FO, manpages, etc. Wouldn't it make sense to include the EPUB2/3 parameters too? Most of the parameters are already documented (refering to HTML). However, there are some parameters which are specific to EPUB. It would be helpful if users know what can be adapted. [1] http://docbook.sf.net/release/xsl/current/doc/index.html -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] using xpointer with modular DocBook
Hello Stefan, Am Sonntag, 14. April 2013, 14:08:03 schrieb Stefan Seefeld: [...] variablelist xi:include href=../vsip/signal.xml xpointer=xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:varlistentry[ @xml:id='foo'])/ ... /variablelist If I'm not mistaken, you can simplify the above xpointer expression as xpointer(id(foo)) Not sure if this scheme is supported, but it maybe worth a try. Maybe you need quotes for id(...) so try both notations. This works well, but introduces a lot of redundancy as for each chunk I'd like to include I have to redefine the namespace used in the xpath expression. Is there a way to avoid that, by making this the default in some way ? If I just leave out the xmlns() I get an error as the xpointer can't be resolved. (I'm using xsltproc to process the DB documents.) I don't think you can avoid the namespace. Have you tried entities? You could define a entity (let's say dbxmlns) inside the internal subset of the DTD: !DOCTYPE chapter [ !ENTITY dbxmlns xmlns(db=http://docbook.org/ns/docbook) ] and use it like this: xi:include href=../vsip/signal.xml xpointer=dbxmlns;xpointer(id(foo))/ Entites are resolved before any xinclude processing is done. If this works, I think this should be compact enough. ;) -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] using xpointer with modular DocBook
Hi Stefan, Am Sonntag, 14. April 2013, 15:09:07 schrieb Stefan Seefeld: [...] If I'm not mistaken, you can simplify the above xpointer expression as xpointer(id(foo)) Not sure if this scheme is supported, but it maybe worth a try. Maybe you need quotes for id(...) so try both notations. Yes, that works indeed. Unfortunately my real references are a little more complex, as they don't have (explicit) ids. So I typically need to refer to things such as the first varlistentry child of the node with id ID. I think that's also possible by just appending an XPath expression. If your variablelist has the ID foo and you want to refer to the first varlistentry you can write: xmlns(db=http://docbook.org/ns/docbook)xpointer(id(foo)/db:varlistentry[1]) [... using entities ...] Indeed, that works. Thanks for the tip ! However, I'd rather prefer to avoid entities. The document will be edited with XML editors such as XMLMind's XXE, which would discard (substitute) the entities. That's true. (Of course, if everyone used such editors it wouldn't matter, but since some use normal text-based editors, I'm looking for a solution that works everywhere. I don't think there is a general solution where you define somewhere the namespace and just refer to it. It seems, you need to add the namespace xmlns() scheme every time. Maybe you add the xmlns() XPointer scheme before passing it to your XML parser. You could (theoretically) apply an XSLT transformation step and add the xmlns() scheme. That way you could avoid entities, however, you add an additional step (which may not be useful). -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB3: how to use base.dir ?
Hi Bob, Am Mittwoch, 10. April 2013, 10:53:17 schrieb Bob Stayton: Or, maybe invent some new variable and name it epub.base.dir which serves as the base directory for everything. Thanks for the feedback. I think maintaining a confusing base.dir setup is worse than any backwards compatibility issues for the next release, so I'll fix this. Since the base.dir param is already used in many places in the html stylesheets, changing its behavior would be difficult. I like the idea of a new epub.base.dir param, and the stylesheet would set the default base.dir value to concat($epub.base.dir, '/', $epub.oebps.dir) Great!! Thanks a million! Regarding those params, only these are hardwired constants and should be xsl:variables: epub.metainf.dir='META-INF/' epub.mimetype.filename='mimetype' epub.mimetype.value='application/epub+zip' Right, sounds reasonable. These can be changed by the user: epub.oebps.dir='OEBPS' epub.ncx.filename='toc.ncx' epub.container.filename='container.xml' epub.package.filename='package.opf' I'm not sure why you would change them, but they can be changed and still have a valid epub file. Ok, I'm fine with that. :) Thanks for all your efforts. -- Gruß/Regards Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Conceptual Questions and Customizations Regarding EPUB2 Stylesheets
Hi, currently, I'm trying to understand some design decisions around the EPUB2 stylesheets: 1. base.dir HTML files are generated relative to base.dir, but the OEBPS and META-INF directories are _not_ created relative to base.dir but rather relative to the current working directory (if using the default). The paths have to explicitly be specified with epub.oebps.dir and epub.metainf.dir. This behaviour is unexpected and does not make sense. Solution: Paths specified with epub.oebps.dir and epub.metainf.dir should be treated as being relative to base.dir: Wrong (current behavior): base.dir /tmp/my_epub epub.oebps.dir /tmp/my_epub/OEBPS epub.metainf.dir /tmp/my_epub/META-INF Correct (expected behavior): base.dir /tmp/my_epub epub.oebps.dir OEBPS (= /tmp/my_epub/OEBPS) epub.metainf.dir META-INF (= /tmp/my_epub/META-INF) Furthermore, if you set epub.oebps.dir to an absolute path, this path will be used as a value for rootfile full-path=PATH element in META-INF/container.xml, creating an invalid EPUB archive. 2. No admonition graphics see https://sourceforge.net/tracker/?func=detailaid=2849681group_id=21935atid=373747 3. Complicated zip file generation (manifest wanted) The easiest way to create the EPUB zip-file would be to write a zip-readable manifest file. The stylesheets already know the complete filelist - it is written to OEBPS/content.opf anyway. Writing a manifest file (when generate.manifest is set to 1) to use with zip is much more effective than parsing content.opf or trying to determine which files to put into the archive by other means. Such a manifest would also help to solve a problem with the callout-graphics. Callout-graphics are _only_ listed in OEBPS/content.opf if they are referenced in the HTML (that is, of the profiled XML contains co or calloutlist elements and callout.graphics is set to 1). If the XML sources do not contain co/calloutlist they are not referenced in OEBPS/content.opf. The EPUB zip file must only contain files that are referenced in OEBPS/content.opf, otherwise it will not validate. As a consequence, a check for callouts need to be performed before creating the zip archive. In addition to this, callout.graphics.number.limit and callout.graphics.extension need to be checked as well in order to get a list with the needed callout graphics. (The ruby script to generate the EPUBs does all this). The same would apply to admonition graphics if they would be supported by the EPUB stylesheets. This creates a massive overhead for the EPUB post processing step (aka copying the files and creating the archive) which could totally be avoided by creating a manifest. 4. Modularisation Probably a minor issue, but a stylesheet with more than 1700 lines should be split into separate files. :) 5. xsl:element vs. literal Maybe this is a matter of taste, but the EPUB2 stylesheet contains sometimes a lot of verbose structures, for example: xsl:element namespace=http://www.idpf.org/2007/opf; name=package This could be expressed more compact as: package xmlns=http://www.idpf.org/2007/opf; Is there a reason why to use xsl:element instead of the literal element? What do you think? -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Conceptual Questions and Customizations Regarding EPUB2 Stylesheets
Hi Carlos, On Tue, 9 Apr 2013 05:10:52 -0700 Carlos Araya carlos.ar...@gmail.com wrote: Is there any reason why not to use the epub3 stylesheets? Thanks for your answer Carlos. Well, I'm not sure if EPUB3 is that widespread than EPUB2. Older EPUB readers does probably not support EPUB3, so I was a bit concerned about compatibility. As far as I can tell epub2 stylesheets are not being actively maintained. Bob has done an awesome job with epub3 and thy should be readable by older devices out of the box. Probably I should move to EPUB3 anyway. :) Thanks! -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Conceptual Questions and Customizations Regarding EPUB2 Stylesheets
Hi, On Tue, 9 Apr 2013 13:37:23 +0200 Thomas Schraitle tom_s...@web.de wrote: currently, I'm trying to understand some design decisions around the EPUB2 stylesheets: [...] By the way, I've started to improve/fix some of the issues that annoys me. :) It's not finished yet, but you can find the code here: https://svn.code.sf.net/p/daps/svn/branches/hackweek9/epub Feel free to try it out. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
