Re: [docbook-apps] EPUB3: missing some meta data
Hi, I'm not trying to be evasive about these questions, I just want to be careful about pointing to the spec itself rather than asserting my own (possibly false) opinions. On Tue, Sep 27, 2011 at 12:25 AM, Bob Stayton b...@sagehill.net wrote: I was also wondering about backwards compatibility of the epub 3 files. That is, would an epub3 file work with an epub2 reader? Yes, that is my personal understanding. The Working Group often discussed this goal, and the spec has been modified to facilitate EPUB 3 documents working _at a very basic level_ in an EPUB 2 Reading System. Are there other things that can be done to the epub3 files to make that experience more satisfying? Right, so I think we're currently in a transitional phase, where we want to emit the most EPUB 2-friendly EPUB 3 documents. That said, I'd encourage the stylesheets to parameterize any of these things for future versions (when EPUB 2 is super obsolete). The critical items we know EPUB 2 Reading Systems *really* need: * NCX * Basic metadata (title, identifier, language) EPUB 2 Reading Systems like: * Extended metadata * OPF guide, etc Keith - 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: missing some meta data
Hi, You can include the (somewhat deprecated) DCMES versions as well: http://idpf.org/epub/30/spec/epub30-publications.html#sec-opf-dcmes-optional This (duplication) will help older EPUB 2 reading systems (and should probably be controlled with a parameter). Regards, Keith On Sun, Sep 25, 2011 at 1:33 PM, Bob Stayton b...@sagehill.net wrote: Hi Michael, I guess I need some clarification on what you mean by missing. When I process your bookinfo element with the epub3 stylesheets, the package.opf file does contain the following metadata: meta property=dcterms:rightsCopyright © 2001 - 2011 John Doe/meta meta property=dcterms:rightsHolderJohn Doe/meta meta property=dcterms:publisherPrivate person/meta meta property=dcterms:subjectNon fiction/meta meta property=dcterms:subjectTechnical article/meta So I'm not sure what's missing. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Michael Wiedmann m...@miwie.in-berlin.de To: DocBook Apps ML docbook-apps@lists.oasis-open.org Cc: Bob Stayton b...@sagehill.net Sent: Sunday, September 25, 2011 2:28 AM Subject: [docbook-apps] EPUB3: missing some meta data Hi Bob, working with the latest Beta2 of the EPUB3 extensions I'm missing some metadata in the resulting EPUB file (which are present if working with the original EPUB2 XSL stylesheets): bookinfo id=bookinfo titleSome Title/title subtitleSubtitle/subtitle author firstnameFirstname/firstnamesurnameSurname/surname /author revhistory revision revnumber0.0.1/revnumber date2011-09-25/date revremarkRemark/revremark /revision /revhistory !-- MISSING -- copyright year2001 dash; 2011/year holderJohn Doe/holder /copyright !-- MISSING -- publisherpublishernamePrivate person/publishername/publisher !-- MISSING -- subjectset subject subjecttermNon fiction/subjectterm /subject subject subjecttermTechnical article/subjectterm /subject /subjectset /bookinfo Michael - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - 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 HTML TOC from epub
Hi, On Thu, Sep 22, 2011 at 11:30 PM, davep da...@dpawson.co.uk wrote: Since the toc is never needed (the ncx supplants a toc), would it make sense to delete the call to generate it such that annoyance is removed? Many publishers deliberately include an HTML TOC in their EPUB documents. An HTML TOC can offer more nuanced layout and text than an NCX TOC and is appropriate for some titles. Regards, Keith - 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: can you suppress html TOC?
Try xsl:param name=generate.toc select=''/ - 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] re:New docbook-xsl-ns snapshots
Hi, On Thu, Apr 21, 2011 at 8:38 AM, Robert Nagle idiotprogram...@gmail.com wrote: Is this information just not current? Yes, it's totally incorrect. If I actually used subversion to pull things to my machine, would I get substantially more up-to-date stylesheets? You can browse the changes to SVN here: http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/ This was the last one that changed the behavior of DocBook-XSL: http://docbook.svn.sourceforge.net/viewvc/docbook?view=revisionrevision=8993 Alternately, you can see the changes as a graph: http://sourceforge.net/project/stats/detail.php?group_id=21935ugn=docbooktype=svnmode=12months Keith - 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] re:New docbook-xsl-ns snapshots
Hi, On Thu, Apr 21, 2011 at 8:54 AM, Bob Stayton b...@sagehill.net wrote: Using subversion would get you the latest files, but they would require processing into the distribution form before you could use them. To do this you would follow the instructions in Part 0 and Part 1 of this: https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/README.BUILD Keith - 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] Re: New docbook-xsl-ns snapshots
On Wed, Apr 20, 2011 at 1:45 AM, Shlomi Fish shlo...@gmail.com wrote: I've been waiting for a response for the EPUB one for a few weeks now. Unfortunately, the DocBook-XSL EPUB stylesheets are not being actively maintained at this time. Best, Keith - 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: how to set linear = 0
On Sun, Apr 10, 2011 at 1:39 AM, Robert Nagle idiotprogram...@gmail.com wrote: I would assume that for epub.cover.linear, if the value is 0, then linear is supposed to be no. But by default it seems to show a yes value in my output. If I change the parameter to xsl:param name=epub.cover.linear select=1 / I get the exact same result. Is this a bug? Yes, try xsl:choose xsl:when test=$epub.cover.linear != 0 xsl:textyes/xsl:text /xsl:when xsl:otherwiseno/xsl:otherwise /xsl:choose - 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/chunking : why h1 tags for sections instead of H2?
Have you reviewed this template in epub/docbook.xsl? !-- Change section.heading to improve SEO on generated HTML by doing heading levels correctly. SEO rules are sometimes silly silly, but this does actually create a semantic improvement. Note: This template needs to be manually maintained outside of the html/sections.xsl code, so make sure important changes get reintegrated. -- xsl:template name=section.heading Keith - 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/chunking : why h1 tags for sections instead of H2? (solved)
Hi, On Tue, Mar 15, 2011 at 9:51 AM, Robert Nagle idiotprogram...@gmail.com wrote: In epub/docbook.xsl I made this one line revision inside the section.heading template to add +1 to the level. By the way, perhaps this is a bug and should have always been +1? I think it'll depend on how you chunk the content. For SEO purposes, one and only one h1 per HTML file is desirable. This is tested in the suite: should include one and only one h1 in each HTML file in rendered ePub files for books ...but as you say, there may be other contexts where different heading levels are desirable. Keith - 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 for mobipocket: image dimensions?
On Mon, Jan 3, 2011 at 8:10 PM, Robert Nagle idiotprogram...@gmail.com wrote: If you wanted to output an image HTML element that contains these attributes, what do they think would be the easiest way to get these attributes? My guess is that the easiest way is with @contentwidth and @contentdepth attributes, following http://www.docbook.org/tdg/en/html/imagedata.html and http://www.sagehill.net/docbookxsl/ImageSizing.html Keith - 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] Modifying content of epub mimetype file
Hi, On Sun, Dec 26, 2010 at 9:23 PM, redlettucemail redlettucem...@mailscan.acenet.net.au wrote: When transforming Docbook 5 files to epub using Saxon 6.5.5, one of the output files, which is supposed to be the mimetype file, contains: ?xml version=1.0 encoding=UTF-8? Would you please clarify which version of the DocBook-XSL stylesheets you're using what tool you're using to invoke Saxon? Thanks, Keith - 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] Modifying content of epub mimetype file
On Wed, Dec 29, 2010 at 12:37 PM, redlettucemail redlettucem...@mailscan.acenet.net.au wrote: I'm using v 1.76 of the stylesheets and invoking Saxon 6.5.5 with oXygen Editor v12. Thank you for clarifying. The XSLT itself does not produce the mimetype file. It is produced by the larger program that invokes the XSLT and bundles the results into a valid EPUB (oXygen, in this case). Because of this, I think you'll have the best luck researching this issue in the oXygen support/forums/whatever. I have not heard of this issue from others creating EPUBs using oXygen, but haven't tested version 12 recently myself. Regards, Keith - 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] HTML/XHTML: a:name vs. a:id?
On Sun, Dec 12, 2010 at 4:12 PM, Robert Nagle idiotprogram...@gmail.com wrote: that html uses a name = while xhtml output uses a id / A different solution would be to change the way the anchor.attribute is called to actually create h2 id=sect2Blah/h2 rather than the a id=sect2/. This is a fairly major customization if your input is heterogenous. Keith - 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 ns vs. vanilla docbook? (epub) when to use?
On Thu, Dec 2, 2010 at 10:42 AM, Robert Nagle idiotprogram...@gmail.com wrote: In a separate thread (I don't remember where) Keith F. mentioned that for the epub stylesheets, I should use the vanilla docbook xsl. There are a number of tradeoffs for the -NS versions for DocBook 5.0 documents, but I strongly recommend avoiding any DocBook-XSL-NS release if you're creating EPUB documents. The stylesheets have not been tested for the -NS release and suffer a number of bugs. I'm not aware of any reason to avoid -NS for other outputs. Keith - 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] diff marking
On Sat, Nov 13, 2010 at 5:26 PM, Mike Maxwell maxw...@umiacs.umd.edu wrote: Is there any program out there which, given two versions of a DocBook v5 file, finds the differences and outputs a marked-up version *using the revisionflag attributes*? oXygen's XML Diff (http://www.oxygenxml.com/xml_diff_and_merge.html) and DeltaXML (http://www.deltaxml.com/) are the two commercial differencing products I'm aware of. I believe that DeltaXML does generate the revisionflag-marked output documents. Keith - 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] diff marking
On Sat, Nov 13, 2010 at 6:59 PM, Mike Maxwell maxw...@umiacs.umd.edu wrote: But what a price :-( Understood. I haven't used either tool in a production environment, so I'm unable to give any endorsement. That said, I would not expect a feature-complete open source alternative in the short term: (schema-aware-) XML differencing is a seriously hard problem. Keith - 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] Re: DocBook-XSL 1.76.1-RC2 for preliminary testing
Hi, On Wed, Oct 13, 2010 at 4:07 PM, Keith Fahlgren abdela...@gmail.com wrote: The second release candidate for DocBook-XSL 1.76.1 is ready for your testing at: https://sourceforge.net/projects/docbook/files/ This is an unstable release and MUST NOT be used in production environments. If no bugs are reported, the stable 1.76.1 release should follow this one soon. Should the release of 1.76.1 be held up on this bug http://sourceforge.net/tracker/?func=detailaid=3087359group_id=21935atid=373747 ? There have been some other issues reported, but I believe many of them are long-standing issues rather than regressions in the 1.76 release. Thanks, Keith - 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] Re: DocBook-XSL 1.76.1-RC2 for preliminary testing
Hi Bob, On Wed, Oct 27, 2010 at 1:00 PM, Bob Stayton b...@sagehill.net wrote: This is apparently a long-standing issue, just now brought to light. Fixing it may require touching several templates, so I would recommend not introducing that risk at this stage of the 1.76 release. We'll fix it for the release after that. Thank you for clarifying. I'll release r8930 as 1.76.1 (that's what RC2 was based on) for some time in the next week (probably next Tuesday or Wednesday). Keith - 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] DocBook-XSL 1.76.1-RC2 for preliminary testing
Hi, The second release candidate for DocBook-XSL 1.76.1 is ready for your testing at: https://sourceforge.net/projects/docbook/files/ This is an unstable release and MUST NOT be used in production environments. If no bugs are reported, the stable 1.76.1 release should follow this one soon. If you're reported a bug against 1.76.0 or the RC-1: thank you. If we've said that it's been fixed, please verify that it has been in the Release Candidate and let us know in the original bug ticket. If you spot a new bug, please report it here: https://sourceforge.net/tracker/?group_id=21935atid=373747 Keith - 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.76.1-RC1 for preliminary testing
On Thu, Oct 7, 2010 at 2:55 AM, Robert Nagle idiotprogram...@gmail.com wrote: Ok, I removed the -ns stylesheet and used the regular ones. And guess what, epubcheck validates ok. I now believe that there are significant problems introduced into the EPUB stylesheets by the transform that creates the -NS distribution code, so thank you for reporting a bug with a good test case. At this point I would recommend against using the -NS distribution for EPUB work. Keith - 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] Re: DocBook-XSL 1.76.1 release schedule
[j2seproject1:jar] Building jar: /Users/abdelazer/repos/docbook.svn.sourceforge.net/trunk/xsl-webhelpindexer/webhelpindexer.jar BUILD SUCCESSFUL Total time: 4 seconds ...so I guess that's good. Keith - 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] DocBook-XSL 1.76.1-RC1 for preliminary testing
Hi, The first release candidate for DocBook-XSL 1.76.1 is ready for your testing at: https://sourceforge.net/projects/docbook/files/ This is an unstable release and MUST NOT be used in production environments. If no bugs are reported, the stable 1.76.1 release should follow this one soon. If you're reported a bug against 1.76.0: thank you. If we've said that it's been fixed, please verify that it has been in the Release Candidate and let us know in the original bug ticket. If you spot a new bug, please report it here: https://sourceforge.net/tracker/?group_id=21935atid=373747 - 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.76.1-RC1 for preliminary testing
Are you using DocBook 5 and the -NS stylesheets? If so, please try the regular ones. On Wednesday, October 6, 2010, Robert Nagle idiotprogram...@gmail.com wrote: ok, here's a regression bug for epub output. https://sourceforge.net/tracker/?func=detailaid=3082618group_id=21935atid=373747 as best as I can tell, it affects all epub output. From: Keith Fahlgren abdela...@gmail.com To: DocBook Apps ML docbook-apps@lists.oasis-open.org Date: Wed, 6 Oct 2010 12:22:40 -0700 Subject: DocBook-XSL 1.76.1-RC1 for preliminary testing Hi, The first release candidate for DocBook-XSL 1.76.1 is ready for your testing at: https://sourceforge.net/projects/docbook/files/ This is an unstable release and MUST NOT be used in production environments. If no bugs are reported, the stable 1.76.1 release should follow this one soon. If you're reported a bug against 1.76.0: thank you. If we've said that it's been fixed, please verify that it has been in the Release Candidate and let us know in the original bug ticket. If you spot a new bug, please report it here: -- Robert Nagle 12777 Ashford Point Dr #1417 Houston, Texas 77082 713 893 3424 htpt://www.robertnagle.info - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - 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] Re: DocBook-XSL 1.76.1 release schedule
1.76.1, that is. On Mon, Oct 4, 2010 at 8:29 PM, DeanNelson deannel...@aol.com wrote: Keith, Huh? 1.61.1 ? You're just checking to see if we are awake ;-) ? Dean Nelson In a message dated 10/04/10 19:54:27 Pacific Daylight Time, abdela...@gmail.com writes: Hi, I'll be preparing the 1.61.1 Release Candidate Wednesday 6 Oct 2010. Please have your submissions checked in by the end of tomorrow, 5 Oct 2010. Keith - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - 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] Re: DocBook-XSL 1.76.1 release schedule
Hi, I'll be preparing the 1.61.1 Release Candidate Wednesday 6 Oct 2010. Please have your submissions checked in by the end of tomorrow, 5 Oct 2010. Keith - 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] Lists on Kindle
Hi, The solutions to this problem that I'm aware of all involve a customization layer on top of the EPUB stylesheets rather than a post-processing step. Other customizations include: * Keeping the XHTML TOC (required by Kindle but typically a mistake for EPUB) * Changing the toc.list*.types to match Amazon's guidelines * Distinguishing sidebars with hrs * Adding mbp:pagebreak in various places Keith - 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] Lists on Kindle
On Thu, Sep 23, 2010 at 5:33 PM, Dick Hamilton rlhamil...@frii.com wrote: This seems to happen because the DocBook transforms generate the following html for a list item, and I suspect the p forces a break: lipThe line that /p/li That's correct. I'm about to dive in and do a little xsl programming to clean this up, but it seemed like a common enough problem that someone might have already fixed this, and would be willing to share the solution. The solution you're approaching is the one that has been used by other folks, although others have gotten Calibre to do the same alterations. While the DocBook-XSL EPUB output is designed to create EPUBs that can be consumed by kindlegen, there are a number of simplifications, modifications, and degradations that are useful for EPUBs destined for kindlegen and Mobi that don't have any utility elsewhere. Keith - 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] DocBook-XSL 1.76.1 release schedule
Hi, There have been a number of issues raised against 1.76.0, but 1.76.1 should be released soon. When should we plan on having the critical bugs closed so we can send out a release candidate for testing (assuming snapshots are still broken)? Thanks, Keith - 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 xsl - Admonition Graphics?
Hi Michael, On Wed, Sep 15, 2010 at 6:42 AM, michael.ur...@jpl.nasa.gov wrote: How hard would it be to have the epub stylesheet add the admonition graphics file information to the document manifest (so that a suitable script can include them when wrapping up the book)? Here's the bug report related to that request: https://sourceforge.net/tracker/?func=detailaid=2849681group_id=21935atid=373747 Keith - 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] Issues with 1.76.0
Hi Dean, Was this confirmed? Did you file a bug report? Keith - 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] DocBook-XSL 1.76.0 released
missing namespace declarations. Closes bug #2890069.
Mauritz Jeanson: footnote.xsl
Updated the template for footnote paras to use the
'paragraph' template. Closes bug #2803739.
Keith Fahlgren: inline.xsl; lists.xsl
Remove b and i elements discouraged in favor of style
sheets from
XHTML, XHTML 1.1 (and therefore EPUB) outputs by changing html2xhtml.xsl.
Fixes bug #2873153: No b and i tags in XHTML/EPUB
Added regression to EPUB specs:
Mauritz Jeanson: inline.xsl
Fixed bug #2844916 (don't output @target if ulink.target is empty).
Keith Fahlgren: autoidx.xsl
Fix a bug when using index.on.type: an 'index symbols'
section was created
even if that typed index didn't include any symbols (they were in the
other types).
Manpages
The following changes have been made to the manpages code since the
1.75.2 release.
Mauritz Jeanson: other.xsl
Modified the write.stubs template so that the section
directory name is not output twice. Should fix bug #2831602.
Also ensured that $lang is added to the .so path (when
man.output.lang.in.name.enabled=1).
Mauritz Jeanson: docbook.xsl; other.xsl
Fixed bug #2412738 (apostrophe escaping) by applying the
submitted patch.
Norman Walsh: block.xsl; endnotes.xsl
Fix bug where simpara in footnote didn't work. Patch by
Jonathan Nieder, jrnie...@gmail.com
dleidert: lists.xsl
Fix two indentation issues: In the first case there is no
corresponding .RS
macro (Debian #519438, sf.net 2793873). In the second case an .RS instead of
the probably intended .sp leads to an indentation bug (Debian #527309,
sf.net #2642139).
Epub
The following changes have been made to the epub code since the 1.75.2 release.
Keith Fahlgren: bin/spec/examples/AMasqueOfDays.epub; docbook.xsl;
bin/spec/epub_spec.rb
Resolve some actual regressions in date output spotted by
more recent versions of epubcheck
Keith Fahlgren: docbook.xsl
Updated mediaobject selection code that better uses roles
(when available); based on contributons by Glenn McDonald
Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl
Ensure that NCX documents are always outputted with a
default namespace
to prevent problems with the kindlegen machinery
Keith Fahlgren: bin/spec/epub_regressions_spec.rb;
bin/spec/files/partintro.xml; docbook.x⋯
Adding support for partintros with sect2s, 3s, etc
Keith Fahlgren: docbook.xsl
Adding param to workaround horrific ADE bug with the
inability to process br
Keith Fahlgren: docbook.xsl
Add support for authorgroup/author in OPF metadata (via
Michael Wiedmann)
Keith Fahlgren: bin/spec/epub_regressions_spec.rb
Remove b and i elements discouraged in favor of style
sheets from
XHTML, XHTML 1.1 (and therefore EPUB) outputs by changing html2xhtml.xsl.
Fixes bug #2873153: No b and i tags in XHTML/EPUB
Added regression to EPUB specs:
Keith Fahlgren: bin/lib/docbook.rb;
bin/spec/files/DejaVuSerif-Italic.otf; docbook.xsl; bi⋯
This resolves bug #2873142, Please add support for
multiple embedded fonts
If you navigate to a checkout of DocBook-XSL and go to:
xsl/epub/bin/spec/files
You can now run the following command:
../../dbtoepub -f DejaVuSerif.otf -f DejaVuSerif-Italic.otf -c test.css
-s test_cust.xsl orm.book.001.xml
In dbtoepub, the following option can be used more than once:
-f, --font [OTF FILE] Embed OTF FILE in .epub.
The underlying stylesheet now accepts a comma-separated list of font file
names rather than just one as the RENAMED epub.embedded.fonts ('s' added).
The runnable EPUB spec now includes:
- should be valid .epub after including more than one embedded font
Keith Fahlgren: docbook.xsl
Improve the selection of cover images when working in
DocBook 4.x land (work in progress)
Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl
Improve the quality of the OPF spine regression by
ensuring that the spine
elements for deeply nested refentries are in order and adjacent to their
opening wrapper XHTML chunk.
Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl;
bin/spec/files/orm.book.00⋯
Add more careful handling of refentries to ensure that
they always appear in the opf:spine.
This was only a problem when refentries were pushed deep into the
hierarchy (like inside
a sect2), but presented navigational problems for many reading systems
(despite the
correct NCX references). This may *not* be the best solution, but
attacking a better
chunking strategy for refentries was too big a nut to crack at this time.
Eclipse
The following changes have been made to the eclipse code since the
1.75.2 release.
Mauritz Jeanson: eclipse3.xsl
Added a stylesheet module that generates plug-ins
conforming to the standard (OSGi-based) Eclipse 3.x
architecture. The main difference to the older format is that metadata
is stored
[docbook-apps] Re: DocBook-XSL 1.76.0 released
The release notes should have included this major new feature: Webhelp A new browser-based, cross-platform help format with full-text search and other features typically found in help systems. See webhelp/docs/content/ch01.html for more information and a demo. Sorry for the omission. Keith - 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] The next formal DocBook-XSL release
On Mon, Aug 30, 2010 at 2:08 PM, Daniel Leidert daniel.leidert.s...@gmx.net wrote: Sorry for not answering earlier. I contributed a few bug-fixes (8895,8898-8900) from the Debian project during the last days and I would like to see them too in the next release (if possible). I was going to base the release on r8891, but I will pull these revisions and base 1.76.0 off of r8900. Thanks, Keith - 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] DocBook-XSL 1.76.0-RC1 for preliminary testing
: footnote.xsl
Updated the template for footnote paras to use the
'paragraph' template. Closes bug #2803739.
Keith Fahlgren: inline.xsl; lists.xsl
Remove b and i elements discouraged in favor of style
sheets from
XHTML, XHTML 1.1 (and therefore EPUB) outputs by changing html2xhtml.xsl.
Fixes bug #2873153: No b and i tags in XHTML/EPUB
Added regression to EPUB specs:
Mauritz Jeanson: inline.xsl
Fixed bug #2844916 (don't output @target if ulink.target is empty).
Keith Fahlgren: autoidx.xsl
Fix a bug when using index.on.type: an 'index symbols'
section was created
even if that typed index didn't include any symbols (they were in the
other types).
Manpages
The following changes have been made to the manpages code since the
1.75.2 release.
Mauritz Jeanson: other.xsl
Modified the write.stubs template so that the section
directory name is not output twice. Should fix bug #2831602.
Also ensured that $lang is added to the .so path (when
man.output.lang.in.name.enabled=1).
Mauritz Jeanson: docbook.xsl; other.xsl
Fixed bug #2412738 (apostrophe escaping) by applying the
submitted patch.
Norman Walsh: block.xsl; endnotes.xsl
Fix bug where simpara in footnote didn't work. Patch by
Jonathan Nieder, jrnie...@gmail.com
dleidert: lists.xsl
Fix two indentation issues: In the first case there is no
corresponding .RS
macro (Debian #519438, sf.net 2793873). In the second case an .RS instead of
the probably intended .sp leads to an indentation bug (Debian #527309,
sf.net #2642139).
Epub
The following changes have been made to the epub code since the 1.75.2 release.
Keith Fahlgren: bin/spec/examples/AMasqueOfDays.epub; docbook.xsl;
bin/spec/epub_spec.rb
Resolve some actual regressions in date output spotted by
more recent versions of epubcheck
Keith Fahlgren: docbook.xsl
Updated mediaobject selection code that better uses roles
(when available); based on contributons by Glenn McDonald
Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl
Ensure that NCX documents are always outputted with a
default namespace
to prevent problems with the kindlegen machinery
Keith Fahlgren: bin/spec/epub_regressions_spec.rb;
bin/spec/files/partintro.xml; docbook.x⋯
Adding support for partintros with sect2s, 3s, etc
Keith Fahlgren: docbook.xsl
Adding param to workaround horrific ADE bug with the
inability to process br
Keith Fahlgren: docbook.xsl
Add support for authorgroup/author in OPF metadata (via
Michael Wiedmann)
Keith Fahlgren: bin/spec/epub_regressions_spec.rb
Remove b and i elements discouraged in favor of style
sheets from
XHTML, XHTML 1.1 (and therefore EPUB) outputs by changing html2xhtml.xsl.
Fixes bug #2873153: No b and i tags in XHTML/EPUB
Added regression to EPUB specs:
Keith Fahlgren: bin/lib/docbook.rb;
bin/spec/files/DejaVuSerif-Italic.otf; docbook.xsl; bi⋯
This resolves bug #2873142, Please add support for
multiple embedded fonts
If you navigate to a checkout of DocBook-XSL and go to:
xsl/epub/bin/spec/files
You can now run the following command:
../../dbtoepub -f DejaVuSerif.otf -f DejaVuSerif-Italic.otf -c test.css
-s test_cust.xsl orm.book.001.xml
In dbtoepub, the following option can be used more than once:
-f, --font [OTF FILE] Embed OTF FILE in .epub.
The underlying stylesheet now accepts a comma-separated list of font file
names rather than just one as the RENAMED epub.embedded.fonts ('s' added).
The runnable EPUB spec now includes:
- should be valid .epub after including more than one embedded font
Keith Fahlgren: docbook.xsl
Improve the selection of cover images when working in
DocBook 4.x land (work in progress)
Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl
Improve the quality of the OPF spine regression by
ensuring that the spine
elements for deeply nested refentries are in order and adjacent to their
opening wrapper XHTML chunk.
Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl;
bin/spec/files/orm.book.00⋯
Add more careful handling of refentries to ensure that
they always appear in the opf:spine.
This was only a problem when refentries were pushed deep into the
hierarchy (like inside
a sect2), but presented navigational problems for many reading systems
(despite the
correct NCX references). This may *not* be the best solution, but
attacking a better
chunking strategy for refentries was too big a nut to crack at this time.
Eclipse
The following changes have been made to the eclipse code since the
1.75.2 release.
Mauritz Jeanson: eclipse3.xsl
Added a stylesheet module that generates plug-ins
conforming to the standard (OSGi-based) Eclipse 3.x
architecture. The main difference to the older format is that metadata
is stored in a separate
manifest file. The module imports and extends the existing
[docbook-apps] Re: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing
Ok. I'll ad something to look for that in the notes. Would you please provide the text? -- Typed with thumbs On Aug 31, 2010, at 6:07 AM, Cramer, David W (David) dcra...@motive.com wrote: Hi Keith, Please also mention the addition of webhelp as a newly supported output format in the release notes :-) Thanks, David -Original Message- From: Keith Fahlgren [mailto:abdela...@gmail.com] Sent: Tuesday, August 31, 2010 2:56 AM To: docbook-developers Cc: Docbook Apps Subject: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing Hi, A release candidate for DocBook-XSL 1.76.0 is ready for you to test. Please review the release notes (below) and give it a whirl and let me know if we should release it on Friday, 3 Sept 2010. Files: http://kfahlgren.com/docbook-xsl/ Reminder: titleAbout dot-zero releases/title paraDocBook Project “dot zero” releases should be considered emphasisexperimental/emphasis and are always followed by stable “dot one plus” releases, usually within two or three weeks. Please help to ensure the stability of “dot one plus” releases by carefully testing each “dot zero” release and reporting back about any problems you find. /para paraIt is not recommended that you use a “dot zero” release in a production system. Instead, you should wait for the “dot one” or greater versions./para Release Notes: 1.76.0 This release includes important bug fixes and adds the following significant feature changes: Gentext Many updates and additions to translation/locales thanks to Red Hat, the Fedora Project, and other contributors. Common Faster localization support, as language files are loaded on demand. FO Support for SVG content in imagedata added. HTML Output improved when using 'make.clean.html' and a stock CSS file is now provided. EPUB A number of improvements to NCX, cover and image selection, and XHTML 1.1 element choices The following is a list of changes that have been made since the 1.75.2 release. Gentext The following changes have been made to the gentext code since the 1.75.2 release. rlandmann: locale/fa.xml Update to Persian translation from the Fedora Project rlandmann: locale/nds.xml Locale for Low German Mauritz Jeanson: locale/ka.xml; Makefile Added support for Georgian based on patch #2917147. rlandmann: locale/nl.xml; locale/ja.xml Updated translations from Red Hat and the Fedora Project rlandmann: locale/bs.xml; locale/ru.xml; locale/hr.xml Updated locales from Red Hat and the Fedora Project rlandmann: locale/pt.xml; locale/cs.xml; locale/es.xml; locale/bg.xml; locale/nl.xml; loca⋯ Updated translations from Red Hat and the Fedora Project rlandmann: locale/as.xml; locale/bn_IN.xml; locale/ast.xml; locale/ml.xml; locale/te.xml; ⋯ New translations from Red Hat and the Fedora Project rlandmann: locale/pt.xml; locale/ca.xml; locale/da.xml; locale/sr.xml; locale/ru.xml; loca⋯ Updated translations from Red Hat and the Fedora Project Common The following changes have been made to the common code since the 1.75.2 release. Mauritz Jeanson: common.xsl Fixed bug in output-orderedlist-starting-number template (@startingnumber did not work for FO). Mauritz Jeanson: gentext.xsl Added fix to catch ID also of descendants of listitem. Closes bug #2955077. Jirka Kosek: l10n.xsl Stripped down, faster version of gentext.template is used when there is no localization customization. Mauritz Jeanson: stripns.xsl Added fix that preserves link/@role (makes links in the reference documentation with @role=tcg work). Mauritz Jeanson: l10n.xsl Fixed bugs related to manpages and L10n. Jirka Kosek: entities.ent; autoidx-kosek.xsl Upgraded to use common entities. Fixed bug when some code used @sortas and some not for grouping/sorting of indexterms. Jirka Kosek: l10n.xsl; l10n.dtd; l10n.xml; autoidx-kosek.xsl Refactored localization support. Language files are loaded on demand. Speedup is about 30%. Jirka Kosek: l10n.xsl Added xsl:keys for improved performance of localization texts look up. Performance gain around 15%. Mauritz Jeanson: titles.xsl Fixed bug #2912677 (error with xref in title). Robert Stayton: olink.xsl Fix bug in xrefstyle title handling introduced with the 'insert.targetdb.data' template. Robert Stayton: gentext.xsl Fix bug in xref to equation without title to use context=xref-number instead of xref-number-and-title. Robert Stayton: labels.xsl Number all equations in one sequence, with or without title. Robert Stayton: entities.ent Fix bug #2896909 where duplicate @sortas on indexterms caused some indexterms to drop out of index. Robert Stayton: stripns.xsl Expand the Stripping namespace ... message to advise users to use the namespaced
[docbook-apps] Including b and i in XHTML stylesheets
On Tue, Aug 31, 2010 at 1:36 PM, Bob Stayton b...@sagehill.net wrote: You are entitled to your opinion on b and i for XHTML, but they are valid elements in XHTML Strict 1.0. We can't just turn them off from the xhtml stylesheet set unless some alternative is put in place, because it would break existing applications. Go ahead and do it for xhtml-1_1 since that set is used for epub and must have them off, but we should not do it for xhtml without further discussion. My understanding was that strong and em were the alternative, no? As I've mentioned before, I believe that b and i are inappropriate in both xhtml/ and xhtml-1_1/ for any markup of db.titles (blockquote-title, for example). Transforming other instances into strong and em seems appropriate, but will be tricky in the html2xhtml.xsl. The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets. http://www.w3.org/TR/html401/present/graphics.html#h-15.2 Are you aware of existing applications that will break other than the highlighting module? Perhaps that should be a special case. If you feel that the stylesheets should be changed, please do so for 1.76.1 and clarify the change for this bug reporter https://sourceforge.net/tracker/?func=detailaid=2873153group_id=21935atid=373747 Keith - 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] Re: Including b and i in XHTML stylesheets
Leaving aside the issue of the highlighting stylesheets, here are the uses of i in the html/ stylesheets: biblio-iso690.xsl:3 biblio.xsl:3 component.xsl:1 division.xsl:1 synop.xsl:1 xref.xsl:1 simlarly, b: autotoc.xsl:2 block.xsl:10 ebnf.xsl:1 formal.xsl:1 lists.xsl:1 qandaset.xsl:3 refentry.xsl:1 titlepage.xsl:2 Looking at every single instance above, I don't see a single one that should remain a b or i instead of being either removed or changed to strong or em. Does anyone want to argue why b and i should be preserved for 1.76.1? Thanks, Keith - 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] Re: Including b and i in XHTML stylesheets
As you've argued in the past, we don't have HTML5 stylsheets at this time. As for b i, their use is discouraged in favor of style sheets. We already use strong and em for emphasis, so the remaining font elements are purely presentational and make it more difficult to style DocBook (X)HTML output using CSS. -- Typed with thumbs On Aug 31, 2010, at 3:00 PM, Jirka Kosek ji...@kosek.cz wrote: Keith Fahlgren wrote: Looking at every single instance above, I don't see a single one that should remain a b or i instead of being either removed or changed to strong or em. Does anyone want to argue why b and i should be preserved for 1.76.1? Maybe I have missed some previous discussion, but what's the reason for changing b/i into strong/em? Also please note that HTML5 is not so antagonistic about b and i as HTML4: http://dev.w3.org/html5/spec/text-level-semantics.html#the-i-element Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [docbook-apps] The next formal DocBook-XSL release
Hi, I haven't received responses beyond David Rudi's for the questions outlined below, so my intention is to build 1.76.0 off of the SVN trunk as it stands at 5pm Pacific today, 27 August 2010. These were the questions: On Sun, Aug 22, 2010 at 10:33 PM, Keith Fahlgren abdela...@gmail.com wrote: Open questions: * Have the Summer of Code contributes been merged back into trunk? * Are there open bugs that must be resolved before 1.76.0 is released? * Are there significant contributions that people were planning on making before the end of August that should temporarily delay 1.76.0? Please let me know if you think 1.76.0 should be delayed. Thanks, Keith - 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] The next formal DocBook-XSL release
Hi, On Sun, Aug 1, 2010 at 6:43 PM, Cramer, David W (David) dcra...@motive.com wrote: I'm confident Kasun will have things ready to go by pencils down (August 16), but I don't know what we need to do to be integrated into the build. Let me figure that out and get back to you on when we'll be ready. We're approaching the deadlines for our tentative 1.76.0 release schedule and I'd like to know if we should shift things around. Our previous timeline was: * 27 August 2010: All changes in SVN (code freeze) * 31 August 2010: 1.76.0 released * 1 Sept-24 Sept 2010: 1.76.0 bugfixes (only) * 28 Sept 2010: 1.76.1 released I'm not able to contribute more than a naive release the current SVN trunk at the agreed-upon time (sadly the process still consumes many hours), assuming I can get all of the new outputs to build. Open questions: * Have the Summer of Code contributes been merged back into trunk? * Are there open bugs that must be resolved before 1.76.0 is released? * Are there significant contributions that people were planning on making before the end of August that should temporarily delay 1.76.0? Thanks, Keith - 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] Re: html 5, as a target
On Sun, Aug 15, 2010 at 11:58 PM, Dave Pawson da...@dpawson.co.uk wrote: Anyway those elements doesn't bring any new user experience. But they do bring better semantics? I think the rejection of a DocBook-XSL patch adding a distinct HTML5 output (perhaps in the http://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax) would be *extremely* unlikely. That said, at this time I'm not aware of anyone developing that patch. How long will [IE6] remain the oldest target? This is a question of even greater weight today, as there is renewed interest in cleaning up the HTML (and XHTML, XHTML 1.1, EPUB...) outputs to be more aligned with modern web browsers and web development techniques. Part of what makes the current HTML stylesheets rather baroque is the extensive support for aging browsers. Keith - 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] The next formal DocBook-XSL release
Hi, It has been an extremely long time since the last release. I think that users of DocBook-XSL are underserved by the rarity of releases. Should we plan on consolidating the Google SoC work and other bugfixes some time late this month? If so, what are the 5 most critical open bugs that we should be sure to resolve? I'd say we get all the changes in by the 27th, release 1.76.0 the following week, do three weeks of bugfixes, then 1.76.1 in mid-Sept. Thanks, Keith -- Typed with thumbs - 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] The next formal DocBook-XSL release
What do you think would be the best time for that release? Should we wait and combine? -- Typed with thumbs On Aug 1, 2010, at 5:09 PM, Cramer, David W (David) dcra...@motive.com wrote: We should also plan for a post-GSOC release that incorporates the work of our students this summer. David -Original Message- From: Bob Stayton [mailto:b...@sagehill.net] Sent: Sunday, August 01, 2010 5:33 PM To: Keith Fahlgren; Docbook Apps Subject: Re: [docbook-apps] The next formal DocBook-XSL release Hi Keith, I agree it has been too long, and we should do a release per your schedule. I'll take a look at the bug list. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Keith Fahlgren abdela...@gmail.com To: Docbook Apps docbook-apps@lists.oasis-open.org Sent: Sunday, August 01, 2010 11:48 AM Subject: [docbook-apps] The next formal DocBook-XSL release Hi, It has been an extremely long time since the last release. I think that users of DocBook-XSL are underserved by the rarity of releases. Should we plan on consolidating the Google SoC work and other bugfixes some time late this month? If so, what are the 5 most critical open bugs that we should be sure to resolve? I'd say we get all the changes in by the 27th, release 1.76.0 the following week, do three weeks of bugfixes, then 1.76.1 in mid-Sept. Thanks, Keith -- Typed with thumbs - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis- open.org - 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 with xhtml-1_1 produce invalid xhtml11?
Hi, On Wed, Jul 21, 2010 at 11:38 AM, Giuseppe Bonelli peppo.bone...@gmail.com wrote: The above html is not valid as per !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; because caption does not allow p children and p does not allow div children. My guess is that captions for HTML tables in DocBook 4.5 were not intended to include paras (compare with http://docbook.org/tdg5/en/html/html.caption.html), although you're right that they don't expressly forbid them. Similarly, I think the above would be improved if the (otherwise empty) para wrapper was removed from the td. In either case, both are probably bugs in the stylesheets, so please report them http://sourceforge.net/tracker/?group_id=21935atid=373747 You may have better luck with the CALS table model if you're aiming for valid XHTML 1.1 output (I'm honestly not sure). Is this the expected behaviour starting from a valid docbook file or I am missing something? May I ask why you've chosen to use the XHTML 1.1 stylesheets rather than the XHTML 1.0 stylesheets? Keith - 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] Admonitions in .epub documents?
On Tue, Jul 13, 2010 at 4:20 PM, Glenn McDonald gmcdon...@vividas.com wrote: The html files that are generated for .epub have no links to the images themselves. Sorry, would you please clarify what DocBook is producing that HTML and what version of the DocBook-XSL stylesheets your using? (I'm not able to duplicate it with the current SVN trunk a guess at the markup.) Thanks, Keith - 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] Admonitions in .epub documents?
On Wed, Jul 14, 2010 at 9:21 PM, Glenn McDonald gmcdon...@vividas.com wrote: I am using the epub/docbook.xsl from the package docbook-xsl-ns-1.75.2.zip Are you using a customization layer that sets the admon.graphics parameter to 1? The OPF manifest does not link to any admonition images: Yes, that's a known bug: http://sourceforge.net/tracker/?func=detailaid=2849681group_id=21935atid=373747 Keith - 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] OPF file for EPUB is linking to images with different roles
On Wed, Jul 14, 2010 at 9:33 PM, Glenn McDonald gmcdon...@vividas.com wrote: I am not sure if it's 100% correct, but below is my modified custom template for handling mediaobject: Thanks for attempting this. I've added similar generic code based on your customization to the docbook.xsl in SVN trunk and am running the test suite now, so this may be fixed upstream in future releases. Keith - 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] Admonitions in .epub documents?
On Wed, Jul 14, 2010 at 10:25 PM, Glenn McDonald gmcdon...@vividas.com wrote: The epub reader (Adobe Digital Editions in my case) is displaying the admonition graphic indented (as expected) but the admonition text is centered in the page. It should be next to the admonition graphic. Interesting. EPUB requires strict conformance to XHTML 1.1, which makes table-based layouts (inherited from DocBook-XSL's aging html/ output) like the above unattractive or invalid. In particular, I suspect an EPUB validator would complain about your @align attributes. I suspect it's this that's causing ADE the problems, but who knows (that rendering engine is known to be eccentric). Keith - 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] Admonitions in .epub documents?
On Mon, Jul 12, 2010 at 11:15 PM, Glenn McDonald gmcdon...@vividas.com wrote: I've been trying to get admonitions working in Docbook 5 / epub output files without any success. All that I get in .epub files is a blank space where the admonition should be. What is an example of some of the markup that's being dropped? Keith - 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 and InDesign
On Tue, Jun 15, 2010 at 6:18 AM, Giuseppe Bonelli peppo.bone...@gmail.com wrote: Based on your experience , can you please briefly elaborate on the main problems you may anticipate in developing a DB-ICML roundtrip scenario? My concern is a generic one about the idea of roundtripping in general rather than a specific concern about ICML. any modification made in inDesign during the fine tuning of the typography (trimmed paragraph, change in the body text due to layout contraints and the like). You're right that changes in the text would be desirable to reintegrate, but doing DocBook-ICML-InDesign should leverage InDesign's InCopy functionality. This might make it easier to change the DocBook source and do a quick InCopy update. Keith - 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 and InDesign
Hi, I was asked to contribute to some work for transforming XHTML into IDML and was pleased with the results (given the circumstances). From that background, I agree with Jirka's assessment about transforming a subset of DocBook and think this would be a relatively straightforward XSLT. I would not try to roundtrip. The project is open source and available at (from memory): http://code.google.com/p/ickmull/ Regards, Keith -- Typed with thumbs On Jun 15, 2010, at 6:34 AM, Jirka Kosek ji...@kosek.cz wrote: Giuseppe Bonelli wrote: I don't think that mapping DB tags to ID styles is the best approach to import docbook files in InDesign. The DB DTD is simply to complex to be managed efficently by InDesign. Typical DocBook document uses 20-30 elements, you don't have to cover full DocBook in custom solution. I think the solution is an XSLT from DB to IDML. But such transformation will require you to define formatting during this transformation. Isn't there already conversion from FO into IDML? This should be less effort. There are several tools for producing DOCX and ODT from FO, but it would be nice to have ability to use InDesign as FO engine. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member -- - 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] footnote missing in xhtml, ns1.75.1
On Wed, Jun 9, 2010 at 9:01 AM, Tim Arnold tim.arn...@sas.com wrote: Is there a way to just get the updated *.xsl files from the svn repository? I'd suggest trying out the DocBook-XSL snapshot release: http://docbook.sourceforge.net/snapshots/ Keith - 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] footnote missing in xhtml, ns1.75.1
Hi, On Tue, Jun 8, 2010 at 11:45 AM, Tim Arnold tim.arn...@sas.com wrote: Can someone confirm that this is a bug? Formally, 1.75.2 is the latest release of the stylesheets. That said, I do not believe the bugfixes between .1 and .2 are relevant in this case. I confirmed the bug using the test included in 1.75.2's xhtml/onechunk.xsl, but it has been resolved in the current SVN trunk. In fact, here is the bug report: http://sourceforge.net/tracker/?func=detailaid=2825842group_id=21935atid=373747 HTH, Keith - 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] Rethinking XSLT 2.0 design
Hi Norm, On Thu, May 27, 2010 at 4:59 AM, Norman Walsh n...@nwalsh.com wrote: I'm going to be turning my hands to the XSLT 2.0 stylesheets for DocBook again soon, partly with an eye towards making them more production ready, partly to try a few experiments. Thanks for clarifying that you'll be working on these stylesheets again, especially in light of Jirka's Google Summer of Code project. I think your ideas about dropping normalization, segmenting the stylesheets into discrete processing chunks rather than always creating a massive, unified stylesheet, and potentially not seamlessly handling DB4 are all prudent and justified. What I'd like to understand is your current thinking on the top three goals of the XSLT2 reimplementation itself. What are they? Thanks, Keith - 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] New Branch: website5
On Mon, May 17, 2010 at 5:24 PM, Sina K. Heshmati s...@khakbaz.com wrote: I just forked the trunk and created a new branch, where I can work on the website re-implementation. Sounds good. BTW, how can receive checkin notifications? Well, I saw your commit in my feed reader: http://cia.vc/stats/project/docbook/.message/255fb0 Here is the feed: http://cia.vc/stats/project/docbook/.rss I'll especially need to keep up with Jirka's commits to the XSLT2 stylesheets. Oh, that's under active development again!? How did I miss that? Keith - 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 from dbook
On Fri, Apr 30, 2010 at 4:11 AM, Compagnon Christopher christopher.compagnon.a...@axa-groupsolutions.com wrote: You can also create ePub from docbook with a shell motorized transformation : http://www.christopher.compagnon.name/sitewww/docbook-epub.html Thank you for providing this. One refinement: ePub requires that the mimetype file be the first archive in the ZIP and uncompressed, so your invocation of zip -r ./ should be broken into two phases: zip -q0X [zipfile] mimetype zip -qXr9D [zipfile] ./ More: http://blog.threepress.org/2009/11/06/3-scripts-for-epub-creation/ Regards, Keith - 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] cals table to xhtml1_1 border issue
Hi, On Fri, Mar 19, 2010 at 10:03 AM, Robert Moody robert.e.mo...@gmail.com wrote: I have been processing cals tables to xhtml table using the docbook xsl and it has been working great in most cases, but I ran into an unusual sitch. Do you have a particular requirement for XHTML 1.1? As far as I know, the only major use of XHTML 1.1 rather than XHTML 1.0 are ePub documents. Do you have better results with the normal XHTML output? Keith - 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] Public/System doctype IDs misbehaving in Eclipse output (1.73)
On Wed, Mar 17, 2010 at 6:27 PM, David Cramer dcra...@motive.com wrote:
I was never able to get around that (but I don't think it occurred to me
to ask here). I ended up post-processing the plugin.xml and toc.xml
files to remove the doctype.
I'll be interested in hearing if there's a right way. I have a vague
idea/memory that this is a saxon thing.
I ran into the same problem with the ePub stylesheets. Under the hood,
this uses the template named write.chunk. From a quick look at the
SVN trunk, I think you'd want to add two paramaters to the call to
write.chunk that generates these files and overrides the doctype
you're setting elsewhere:
Index: eclipse.xsl
===
--- eclipse.xsl (revision 8582)
+++ eclipse.xsl (working copy)
@@ -114,6 +114,8 @@
xsl:with-param name=encoding select='utf-8'/
xsl:with-param name=indent select='yes'/
xsl:with-param name=quiet select=$chunk.quietly/
+xsl:with-param name=doctype-public select=''/ !--
intentionally blank --
+xsl:with-param name=doctype-system select=''/ !--
intentionally blank --
xsl:with-param name=content
xsl:choose
@@ -207,6 +209,8 @@
xsl:with-param name=encoding select='utf-8'/
xsl:with-param name=indent select='yes'/
xsl:with-param name=quiet select=$chunk.quietly/
+xsl:with-param name=doctype-public select=''/ !--
intentionally blank --
+xsl:with-param name=doctype-system select=''/ !--
intentionally blank --
xsl:with-param name=content
plugin name={$eclipse.plugin.name}
id={$eclipse.plugin.id}
...that said, I've never used the Eclipse output, so this is just a
guess based on what is in SVN...
Keith
-
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] saxon: docbookV4.5/docbookx.dtd (No such file or directory)
On Wed, Mar 17, 2010 at 9:30 AM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: I cannot make it work using saxon 6.5.5 on a debian machine. It fails with: java -cp /etc/xml/resolver:/usr/share/java/xml-commons-resolver-1.1.jar:/usr/share/java/docbook-xsl-saxon.jar:/usr/share/java/saxon.jar com.icl.saxon.StyleSheet -x org.apache.xml.resolver.tools.ResolvingXMLReader -y org.apache.xml.resolver.tools.ResolvingXMLReader -r org.apache.xml.resolver.tools.CatalogResolver -u -o toto in2.xml /usr/share/xml/docbook/stylesheet/docbook-xsl/fo/docbook.xsl Do you have a CatalogManager.properties file in your CLASSPATH that points to your XML Catalog? IIRC, xsltproc always checks /etc/xml/catalog by default, but Saxon needs to have it specified. More in Bob Stayton's book: http://www.sagehill.net/docbookxsl/UseCatalog.html#UsingCatalogsSaxon Keith - 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] error for docbook to ePub stylesheet
On Thu, Feb 11, 2010 at 1:48 AM, Compagnon Christopher christopher.compagnon.a...@axa-groupsolutions.com wrote: I’ve been running the epub conversion XSLT (docbook-xsl 1.75.2/ saxon 9) and I obtained this error : The DocBook-XSL stylesheets are XSLT 1.0 stylesheets. Saxon 9 is an XSLT 2.0 processor and is not supported. I was able to use the 1.72.2 ePub stylesheets to transform your document using both xsltproc and Saxon 6, an XSLT 1.0 processor. Keith - 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] error for docbook to ePub stylesheet
On Thu, Feb 11, 2010 at 1:48 AM, Compagnon Christopher christopher.compagnon.a...@axa-groupsolutions.com wrote: I’ve been running the epub conversion XSLT (docbook-xsl 1.75.2/ saxon 9) and I obtained this error : Error at xsl:template on line 1298 column 30 of docbook.xsl: Are you able to provide a small sample DocBook document that triggers this error? Keith - 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] Re: [docbook] DocBook and Google Summer of Code ?
On Wed, Jan 27, 2010 at 9:05 AM, Camille Bégnis cami...@neodoc.biz wrote: I have always dreamed of a graphical application that would allow someone without a CS degree to customize the XSL-FO stylesheets. I'm sure this was just a figure of speech, but of the four people that developed (and maintain) O'Reilly's *gigantic*, successful customization of the XSL-FO stylesheets, only one has a CS degree. I have a history degree, for example. Keith - 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] inlinemediaobject + caption for epubs?
On Tue, Jan 26, 2010 at 3:59 AM, Robert Nagle idiotprogram...@gmail.com wrote: I don't want images to interrupt the flow of the page when it's in epub. Instead I want text to wrap around a right-aligned image. OK, that sounds like presentation. It looks like inlinemedia is the best element for that; ...but that sounds like semantics. however, by default inlinemedia doesn't allow captions -- only textobjects which don't render in chunked html output (only as alt text). I need the equivalent of captions for inlinemedia elements. ...but inlinemedia elements are, by definition, untitled/captioned. A caption is an extended description of a mediaobject or figure or other formal or informal element. The problem here is that mediaobjects are block elements (which make sense for html and fo output, but not for epub). When dealing with smaller sized screens, using the extra space to separate an image block element is wasteful and inefficient. Any ideas for how to solve this problem? Why not solve the problem in the CSS in the ePub? You'll already need to be adding CSS customizations (for wrapping and alignment) to try to get the desired behavior (although a reading system may choose to ignore your requests), so adding more instructions to control the display behavior (block, inline, etc) would make sense. Keith - 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] Re: [docbook] ePub: Title page missing and ToC in spine?
[Back to DocBook-Apps] On Tue, Jan 26, 2010 at 2:00 PM, Boris Schäling bo...@highscore.de wrote: While this all works with the book I'm experimenting with I don't know if there are use cases where the predicates applied to the book node make sense? Simply removing them might have side effects? Setting root.is.a.chunk always to 1 might have side effects, too? But there is someone who wrote this code and should know? :-) Most of the XSLT for the ePub output was developed in a test-first style, so it's unlikely but possible that I just added code that has no impact. If you'd like to understand the impact of changes to the XSLT on a larger set of inputs, I'd suggest running the test suite and smoketests for the ePub output that are (briefly) described here: https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/epub/bin/spec/README I've added the output of the test suite from my machine on the current SVN trunk to the end of this email to clarify what you should see. I'm also able to get 211 of the 224 smoketests (94%) to pass, which is normal. If the above helps clarify some of the design decisions and expose areas for fixes and improvements, I'd be delighted to see bug reports with test documents attached, failing test cases, and/or patches with new test cases fixes. That said, the continued refinement of the ePub stylesheets is not a high priority for me at this time[1], so I'm eager to help others make contributions to improve the quality of the code, documentation, and output. Regards, Keith 1. Although I won't rule out the idea that it could be again with the right motivation. http://threepress.org spec/epub_spec.rb DocBook::Epub - should be able to be created - should fail on a nonexistent file - should be able to render to a file - should create a file after rendering - should have the correct mimetype after rendering - should be valid .epub after rendering an article - should be valid .epub after rendering an article without sections - should be valid .epub after rendering a book - should be valid .epub after rendering a book even if it has one graphic - should be valid .epub after rendering a book even if it has many graphics - should be valid .epub after rendering a book even if it has many duplicated graphics - should report an empty file as invalid - should confirm that a valid .epub file is valid - should include at least one dc:identifier - should include an ISBN as URN for dc:identifier if an ISBN was in the metadata - should include an ISSN as URN for dc:identifier if an ISSN was in the metadata - should include an biblioid as a dc:identifier if an biblioid was in the metadata - should include a URN for a biblioid with @class attribute as a dc:identifier if an biblioid was in the metadata - should not include PDFs in rendered epub files as valid image inclusions - should include a CSS link in HTML files when a CSS file has been provided - should include CSS file in .epub when a CSS file has been provided - should include a reference in the OPF manifest to the provided CSS file - should include a reference in the OPF manifest to the embedded font - should include the embedded font file in the bundle - should be valid .epub after including more than one embedded font - should include one and only one h1 in each HTML file in rendered ePub files for books - should include one and only one h1 in each HTML file in rendered ePub files for books even if they do not have section markup - should include a TOC link in rendered epub files for books - should allow for the stylesheets to be overridden by a customization layer Finished in 64.169372 seconds 29 examples, 0 failures == spec/epub_realbook_spec.rb DocBook::Epub - should be able to render a valid .epub for the 'Real Book' test document - should include the large cover image in each rendered epub of a 'Real Book' test document like - should mark the HTML cover as not linear for the 'Real Book' test document - should use the cover image @id for the opf/me...@name='cover'] for the 'Real Book' test document - should reference the cover in the OPF guide for the 'Real Book' test document - should use the isbn as dc:identifier for the 'Real Book' test document - should use the copyright as dc:rights for the 'Real Book' test document - should use the publishername as dc:publisher for the 'Real Book' test document - should use the abstract as dc:description for the 'Real Book' test document - should use the date as dc:date for the 'Real Book' test document - should use the subjectset as dc:subject for the 'Real Book' test document Finished in 23.976278 seconds 11 examples, 0 failures == DocBook::Epub - should not include two itemrefs to the contents of parts in the OPF file - should preserve content from dedication elements - should use the correct mimetype for CSS files - should not include an XHTML DOCTYPE in the OPF file - should reference a cover in the OPF guide for a DocBook 5.0 test document - should allow pre elements
Re: [docbook-apps] Breaking docbook into multiple files
On Mon, Jan 25, 2010 at 8:47 AM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: I have another simple question. What is the recommended way of splitting a large docbook document into multiple other ? Bob Stayton has a nice section covering modular DocBook in his book: http://www.sagehill.net/docbookxsl/ModularDoc.html I prefer XIncludes, although they tend to be a little slower to process. Keith - 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] Apostrophe in docbook document
On Mon, Jan 25, 2010 at 4:53 PM, Ron Catterall r...@catterall.net wrote: We have (at least) three logical symbols: 1. a singular possessive - this is Ron' book 2. a plral posessive - these the are mens' books 3. a missing word ain't (or old English an't) Missing some: * Slang: What ya mean, 'unting rabbits? * Quotes in quotes: I can't believe you'd quote her saying, this is totally 'bogus'. * Numbers: '99 ...also make sure you don't do anything in programlisting, code, etc... - 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 titlepages
On Thu, Dec 3, 2009 at 12:19 PM, John Green jmg7...@rogers.com wrote: Hello, I am working on creating book-level titlepages for output to epub. So far I have not been able to output anything, even the title page (book info metadata elements) that chunked HTML output creates at the beginning of the TOC chunk. Are you able to output your desired files using the XHTML stylesheets? Keith - 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 titlepages
On Thu, Dec 3, 2009 at 1:38 PM, John Green jmg7...@rogers.com wrote: - Keith Fahlgren abdela...@gmail.com replied: Are you able to output your desired files using the XHTML stylesheets? The XHTML stylesheets output metadata to a title page at the beginning of the chunk that contains the TOC. There is a horizontal line between this data and the TOC. I'd like to output roughly the same metadata to separate chunks for epub output. OK. I'd suggest developing the customization against the XHTML stylesheets (because they have better documentation and are easier to test) and then moving it to the EPUB output. I've never done (X)HTML title page customization, but I would probably start looking in Bob's book: http://www.sagehill.net/docbookxsl/HTMLTitlePage.html#HtmlTitlepageSpecs Keith - 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] improve DocBook's HTML output
On Wed, Dec 2, 2009 at 1:12 PM, Mauritz Jeanson m...@johanneberg.com wrote: | -Original Message- | From: Bob Stayton | | I have had a long standing goal to modernize the HTML output | from the | DocBook XSL stylesheets. We have too many instances of | hardcoded styles like | b and other transgressions of modern HTML practice. One important point is to ensure that 100% valid and conformant output can be generated (both HTML and XHTML). Sometimes that is harder than it should be. I don't think that generating valid HTML needs to be a short-term goal. My suggestion would be to focus first on clean valid XHTML output, then decide how much more work (if any) it would take to create valid HTML. And perhaps someone has an opinion on the claim that the current (X)HTML output suffers from div-itis (excessive use of div elements). See http://backtobase.wordpress.com/2007/06/20/docbook-is-not-making-my-life-eas ier/. I don't find this a very concerning opinion at this time. Keith - 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] sample docbook5 files to stress test XSL processors?
On Tue, Nov 24, 2009 at 7:16 AM, Tony Graham tony.gra...@menteithconsulting.com wrote: I use the tests for testing the xmlroff XSL formatter, which is why I know about them. These test documents are also used to smoketest the EPUB output (I get all but [a known] 13 to generate valid EPUBs, IIRC). HTH, Keith - 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: rudimentary support for authorgroup in opf.metadata
On Fri, Oct 23, 2009 at 1:14 AM, Michael Wiedmann m...@miwie.in-berlin.de wrote: I'd like to see at least rudimentary support for bookinfo|articleinfo authorgroup author ... /author /authorgroup in OPF metadata of epub output. This could be accomplished e.g. like Done. Thanks, Keith - 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] why do user templates generate empty xmlns attributes?
On Thu, Oct 15, 2009 at 9:35 AM, Bob Stayton b...@sagehill.net wrote: The epub/docbook.xsl stylesheet hardcodes the namespace for each output element it generates, so strictly speaking it does not need the default namespace declaration. It wouldn't hurt, though. Some EPUB processors are very limited in their namespace support, so I've needed to do some tricky hoop-jumping to create output that works as input for some of these tools. This may be why some of my choices in the code look stupid or illogical. On the other hand, I may have (and certainly have in the past) made stupid choices, so please let me know if you think there are better techniques. Keith - 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] Graphic formats for screenshots
On Thu, Aug 6, 2009 at 10:10 AM, deannel...@aol.com wrote: It really depends on the content of your images. That's right. At O'Reilly, we store a web and print version of every single image that appears in our content. The print version is fairly easy: a black white PDF at 300dpi. The web version is more complex, and isn't actually itself suitable for the web. Instead, it is a file that can be transformed into an image suitable for the web (changes size and format, typically). For technical illustrations, SVG is an attractive choice for a format, but we currently don't have any expertise in storing rendering these, so we haven't. Instead, we use a mix of PNGs (for illustrations, drawings) and JPGs (for photos), both stored at very big sizes and in full color (when available). When it comes time to actually deliver content, we use these PNG or JPG masters to make a smaller (less than 1000 pixels high or wide, say) versions that we actually deliver to customers. Speaking very generically, JPGs _tend_ to be better at photographs and PNGs _tend_ to be better at the rest, but that can bite you. Use SVG if you can also _tends_ to be good advice, but SVG has real ramp-up costs. PDF is great for sending things to an offset printer. HTH, Keith - 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] Re: ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.2 released
On Fri, Jul 24, 2009 at 9:11 AM, Ron Catterallr...@catterall.net wrote: The latest namespace aware 1.75.2 stylesheet is not listed at https://sourceforge.net/projects/docbook/files/ (or http:// of course) Where is it? Sourceforge has been changing their UI. 1. Visit https://sourceforge.net/projects/docbook/files/ 2. Click docbook-xsl-ns 3. Click 1.75.2 4. Select a file Keith - 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] Re: ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.2 released
On Wed, Jul 22, 2009 at 12:35 PM, Daniel Leidertdaniel.leidert.s...@gmx.net wrote: Sorry to be the one telling you the bad news :), but the reference PDF file in docbook-xsl-doc is empty (0 byte). Thanks for the report. I've confirmed this and will see if the packages can be updated. Keith - 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] Re: ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.2 released
On Wed, Jul 22, 2009 at 1:51 PM, Keith Fahlgrenabdela...@gmail.com wrote: On Wed, Jul 22, 2009 at 12:35 PM, Daniel Leidertdaniel.leidert.s...@gmx.net wrote: Sorry to be the one telling you the bad news :), but the reference PDF file in docbook-xsl-doc is empty (0 byte). Thanks for the report. I've confirmed this and will see if the packages can be updated. Deliciously, it seems that Sourceforge has updated their release management interface. I hope that I just uploaded new docbook-xsl-doc packages Keith - 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] ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.2 released
On Tue, Jul 21, 2009 at 6:40 AM, Keith Fahlgrenabdela...@gmail.com wrote: On Tue, Jul 21, 2009 at 1:54 AM, Daniel Leidertdaniel.leidert.s...@gmx.net wrote: All these fixes are missing in 1.75.2. The locale files in common/ are the same as in release 1.75.1. Ah, how delightful. Release management for this project is so rewarding. So, this was a bug in the release manager. I've added a step to the README.BUILD to hopefully prevent a regression in the future and will re-bundle the distribution and replace the files at Sourceforge. This should take about 2 hours. I'll let you know when I've finished. Keith - 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] ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.2 released
On Tue, Jul 21, 2009 at 7:05 AM, Barton Wrightbarton.wri...@streambase.com wrote: Consider another step for the README.build while you're there: double-check that the Release Notes are updated with the correct version number. (1.75.2 Rel Notes still say 1.75.1 throughout.) I don't see this. Release Notes: 1.75.2 The following is a list of changes that have been made since the 1.75.1 release. Gentext The following changes have been made to the gentext code since the 1.75.1 release. * dleidert: locale/ja.xml Improved Japanese translation for Note(s). Closes bug #2823965. * dleidert: locale/pl.xml Polish alphabet contains O with acute accent, not with grave accent. Closes bug #2823964. * Robert Stayton: locale/ja.xml Fix translation of index, per bug report 2796064. * Robert Stayton: locale/is.xml New Icelandic locale file. Common The following changes have been made to the common code since the 1.75.1 release. ... - 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] ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.2 released
Version 1.75.1 of the DocBook XSL XSL-NS Stylesheets, for processing DocBook 4 and namespaced (DocBook 5) documents, is now available: https://sourceforge.net/projects/docbook/files/ The release notes are included below, and also available online. The reference docs are available as a separate package, and online. The following is a list of changes that have been made since the 1.75.1 release. Gentext The following changes have been made to the gentext code since the 1.75.1 release. ● dleidert: locale/ja.xml Improved Japanese translation for Note(s). Closes bug #2823965. ● dleidert: locale/pl.xml Polish alphabet contains O with acute accent, not with grave accent. Closes bug #2823964. ● Robert Stayton: locale/ja.xml Fix translation of index, per bug report 2796064. ● Robert Stayton: locale/is.xml New Icelandic locale file. Common The following changes have been made to the common code since the 1.75.1 release. ● Norman Walsh: stripns.xsl Support more downconvert cases ● Robert Stayton: titles.xsl Make sure title inside info is used if no other title. FO The following changes have been made to the fo code since the 1.75.1 release. ● Robert Stayton: pi.xsl Turn off dbfo-need for fop1.extensions also, per bug #2816141. HTML The following changes have been made to the html code since the 1.75.1 release. ● Mauritz Jeanson: titlepage.xsl Output Copyright heading in XHTML too. ● Mauritz Jeanson: titlepage.xsl Added stylesheet.result.type test for copyright. Closes bug #2813289. ● Norman Walsh: htmltbl.xsl Remove ambiguity wrt @span, @rowspan, and @colspan Manpages The following changes have been made to the manpages code since the 1.75.1 release. ● Mauritz Jeanson: endnotes.xsl Added normalize-space() for ulink content. Closes bug #2793877. ● Mauritz Jeanson: docbook.xsl Added stylesheet.result.type test for copyright. Closes bug #2813289. Epub The following changes have been made to the epub code since the 1.75.1 release. ● Keith Fahlgren: bin/dbtoepub; bin/lib/docbook.rb Corrected bugs caused by path and file assumptions were not met ● Keith Fahlgren: bin/lib/docbook.rb; docbook.xsl Cleaning up hardcoded values into parameters and fixing Ruby library to pass them properly; all thanks to patch from Liza Daly Params The following changes have been made to the params code since the 1.75.1 release. ● Mauritz Jeanson: highlight.source.xml Fixed typo. Profiling The following changes have been made to the profiling code since the 1.75.1 release. ● Robert Stayton: profile.xsl Fix bug 2815493 missing exsl.node.set.available parameter. XSL-Saxon The following changes have been made to the xsl-saxon code since the 1.75.1 release. ● Mauritz Jeanson: src/com/nwalsh/saxon/ColumnUpdateEmitter.java; src/com/ nwalsh/saxon/Colum⋯ Added fixes so that colgroups in the XHTML namespace are processed properly. XSL-Xalan The following changes have been made to the xsl-xalan code since the 1.75.1 release. ● Mauritz Jeanson: nbproject/project.xml Added missing NetBeans configuration. - 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] HTML Column Width Trouble
1.75.2 is scheduled to release on Monday, and it should include this update. On Mon, Jul 13, 2009 at 3:08 PM, Mauritz Jeansonm...@johanneberg.com wrote: | -Original Message- | From: Bob Stayton | | The real solution is for Norm or another Java programmer to | update the Java source for the tablecolumns.extension | function to work with elements in the XHTML namespace as | well as the null namespace. I have committed an update to the Java source that fixes this issue. It should be available in the latest snapshot release by now, but some defect in the snapshot build system is preventing the extension from being properly rebuilt. Mauritz - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - 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 parameters: (epub.cover.id)
On Tue, Jun 23, 2009 at 2:32 PM, Robert Nagleidiotprogram...@gmail.com wrote: I'm having trouble figuring out the meaning of the epub parameters, especially the ones related to cover. (see bottom) The cover can be a little bit tricky to generate generically in DocBook 4.x because of the lack of the cover element. It should be simpler in DocBook 5.0. I know that docbook has a cover element, but cover in the context of epub parameters seems to mean something different. (Or am I supposed to assume that the cover image information should be inside a mediaobject element which is inside docbook's cover element?) Does epub.cover.filename assume that the file is an html file or a graphic file? In general, most of the epub.* parameters should be left as the default unless you're writing an EPUB generation tool. The epub.cover.filename contains the name of the generated cover XHTML file. Will the epub.cover.image.id refer to a file name or simply be an identifying attribute? The epub.cover.image.id is used to identify the cover in the OPF file. Finally, I see this note on docbook.xsl !-- Via Martin Goerner: On covers: the IDPF2.0 standard ... I'm sorry; I don't understand exactly what this means. Does he mean that in the html output from docbook you include cover information in a meta tag ? Is there a file reference inside this meta tag? You shouldn't need to worry about this. Also, when epub.cover.linear = 0 or 1, what does that mean? One typically keeps the cover out of the OPF spine. The default of 0 keeps it out. It would be nice to see a simple example of the values used to produce a cover. You can see an example of a DocBook 4.x cover here (less clearly): https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/epub/bin/spec/files/orm.book.001.xml and 5.0 here (more clearly): https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/epub/bin/spec/files/v5cover.xml Keith - 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: meta information
On Thu, Jun 18, 2009 at 4:49 AM, Michael Wiedmannm...@miwie.in-berlin.de wrote: What would be the preferred way to add meta information (like dc:description, dc:identifier, dc:title, or dc:language) given that the input file might not contain the necessary information? Sorry, I don't understand where this data would come from. Currently, dc:title comes from $doc.title dc:description comes from the abstract dc:language comes from the l10n.language of the root note dc:identifier comes from an identifier found on /*/*info (look at the template for the options) Should I simply override the opf template? That would probably be the easiest way. PS: Some TeX guys asked me about how to convert LaTeX files to ePub. My suggestion probably will be to use tex4ht to convert the source files to DocBook and further to ePub using the ePub support in the actual DocBook XSL stylesheets. A first attempt was very promising, but the converted DocBook file doesn't contain the (wanted) meta information. It may be easier for them to go to XHTML, I dunno. Keith - 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] list pulled out of containing para in html output
On Wed, Jun 10, 2009 at 7:18 AM, David Cramerdcra...@motive.com wrote: Using the 1.72.0 html xsls 1.72.0 was released 869 days ago. While I'm not certain your issue would be fixed, it would probably be easier to answer questions if you were using a more recent version of the stylesheets. Are you able to upgrade? Thanks, Keith - 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] Checking before reporting a bug with XRef to nonexistent id:
On Tue, Jun 9, 2009 at 3:51 PM, Johan Perssonjoh...@aditus.nu wrote: Is this a known problem ? I'm not seeing it in the list of open bugs (http://sourceforge.net/tracker/?limit=10func=group_id=21935atid=373747status=1category=321159) and have confirmed that it is still an issue in the current trunk. Please report a new bug. My initial guess is that xlink support has not been added to the processing of xrefs in no.anchor.mode (https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/common/titles.xsl). FYI: @linkend works fine Keith - 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] footnote/para/programlisting - invalid XHTML
On Sun, Jun 7, 2009 at 11:20 AM, Philipp Kempgenphilipp.kemp...@amooma.de wrote: Don't really know what to do with this so I'll post it here. Please bear with me. Thanks for the bug report. Formally, http://sourceforge.net/tracker/?atid=373747group_id=21935func=browse is the bug tracker. I have a problem with how the XSL stylesheets (nwalsh) transform footnote/para/programlisting to XHTML. Which version of the stylesheets are you using? 1.74.3? 1.75.1? xsltproc, make.valid.html=1, html.cleanup=1 Are you using the xhtml/ or xhtml-1_1/ targets or html/? Output: div class=footnotep ... pre class=programlisting pre inside p is invalid XHTML. Would you mind including the DocBook that generated that XHTML? I fixed it by modifying the template which matches footnote/para[1]|footnote/simpara[1] (in footnote.xsl) to call the paragraph template (in block.xsl) which then calls unwrap.p -- just as the template which matches para (in block.xsl) does. Are you familiar with the diff command? That might be a clearer way to specify your changes. $ cp footnote.xsl footnote.before.xsl # Make your edits to footenote.xsl $ diff footnote.before.xsl footnote.xsl Thanks, Keith - 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] FO processors
O'Reilly uses Antenna House. The initial use case (a number of years ago) demanded maximum speed, which favored AH over XEP (at the time). We've been generally happy with AH, so we haven't re-evaluated. I suspect you'd be happy with either, but your choice may depend on language support or other features (as above). HTH, Keith - 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] nested inline emphasis - bug?
On Sun, May 31, 2009 at 9:09 AM, Damon Mannion da...@mannion.me.uk wrote: Where are bugs supposed to be logged? The DocBook-XSL bug tracker is at https://sourceforge.net/tracker/?group_id=21935atid=373747 Keith - 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] Missing Text in Nested Lists
On Wed, May 27, 2009 at 2:30 PM, Youliang Cheong tc...@interchange.ubc.ca wrote: I have been using the following command: xsltproc -o error.html DOCBOOK_DIR/xhtml/docbook.xsl error.xml where DOCBOOK_DIR is the DocBook installation directory for docbook-xsl-1.75.0. Can someone explain what's wrong? I'm not able to reproduce this. What XHTML output _are_ you seeing? - 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] Missing Text in Nested Lists
On Wed, May 27, 2009 at 3:20 PM, Youliang Cheong tc...@interchange.ubc.ca wrote: I've attached the HTML output. Sure enough... I don't know who resolved this bug, but it seems fixed in the SVN trunk and should be resolved in 1.75.1 (out soon). Keith - 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] ANNOUNCE: DocBook XSL XSL-NS Stylesheets 1.75.1 released
Version 1.75.1 of the DocBook XSL XSL-NS Stylesheets, for processing DocBook 4 and namespaced (DocBook 5) documents, is now available: http://docbook.sf.net/files/xsl/latest The release notes are included below, and also available online. The reference docs are available as a separate package, and online. http://docbook.sf.net/files/xsl-doc/latest The following is a list of changes that have been made since the 1.75.0 release. FO The following changes have been made to the fo code since the 1.75.0 release. ● Keith Fahlgren: block.xsl Switching to em dash for character before attribution in epigraph; resolves Bug #2793878 ● Robert Stayton: lists.xsl Fixed bug 2789947, id attribute missing on simplelist fo output. HTML The following changes have been made to the html code since the 1.75.0 release. ● Keith Fahlgren: block.xsl Switching to em dash for character before attribution in epigraph; resolves Bug #2793878 ● Robert Stayton: lists.xsl Fixed bug 2789678: apply-templates line accidentally deleted. Epub The following changes have been made to the epub code since the 1.75.0 release. ● Keith Fahlgren: bin/spec/epub_regressions_spec.rb; docbook.xsl Added regression and fix to correct bug with namespace-prefixed container elements in META-INF/container.xml ; resolves Issue #2790017 ● Keith Fahlgren: bin/spec/epub_regressions_spec.rb; bin/spec/files/ onegraphic.xinclude.xml;⋯ Another attempt at flexible named entity and XInclude processing ● Keith Fahlgren: bin/lib/docbook.rb Tweaking solution to Bug #2750442 following regression reported by Michael Wiedmann. Params The following changes have been made to the params code since the 1.75.0 release. ● Mauritz Jeanson: highlight.source.xml Updated documentation to reflect changes made in r8419. - 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] 1.75.0 Bug Period Ends
Hi all, We're planning on releasing DocBook-XSL 1.75.1 next week. Please test 1.75.0 in your environment this week and report any issues to the tracker (https://sourceforge.net/tracker/?group_id=21935atid=373747). Thanks, Keith - 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] xinclude ...... of plain text?
On Wed, May 13, 2009 at 10:24 AM, DavePawson da...@dpawson.co.uk wrote: As an alternative to using the textinsert element, consider using an Xinclude element I'd argue that using XIncludes rather than textinsert increases the chances of interoperability. Here's Bob on the same: http://www.sagehill.net/docbookxsl/ModularDoc.html#XIncludePlainText - 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] Problems with named entities and dbtoepub in 1.75.0
On Sat, May 9, 2009 at 1:48 AM, Michael Wiedmann m...@miwie.in-berlin.de wrote: This is my test-file (test-entity.xml): ?xml version='1.0' encoding='ISO-8859-1'? !DOCTYPE article PUBLIC '-//OASIS//DTD DocBook XML V4.5//EN' http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; article section titleTitle/title paracopy;/para /section /article Thank you for the test case. I just committed another fix regression to try to solve this issue flexibly. Please let me know if that doesn't resolve it. Keith - 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] ANNOUNCE: DocBook XSL and XSL-NS 1.75.0 released
On Fri, May 8, 2009 at 11:31 AM, Michael Wiedmann m...@miwie.in-berlin.de wrote: Keith Fahlgren wrote, on 07.05.2009 05:55: Version 1.75.0 of the DocBook XSL XSL-NS Stylesheets, for processing DocBook 4 and namespaced (DocBook 5) documents, is now available: I notice a different behaviour of epub/bin/db2epub (release 1.75.0 against 1.74.3 resp. snapshot of 04-13): The new version complains like: db-templ.xml:31: parser error : Entity 'copy' not defined holdercopy; Michael Wiedmann/holder about not declared entities, whereas earlier versions processed the same file w/o such error (at least IIRC). Bummer thanks for testing and the report. I changed some of the dbtoepub architecture to try to fix this bug related to XIncludes and named entities: https://sourceforge.net/tracker/?func=detailaid=2750442group_id=21935atid=373747 I'm becoming increasingly unhappy with the quality of dbtoepub itself as an end-user tool, although it's critical for the current testing framework. Specifically, Ruby doesn't include mature XML libraries in its standard library, so I'm forced to call out to xmllint. In this case, I'm running up against my inability to collapse XIncludes, collapse entities, and validate. I either need to choose --postvalid (breaks entities) or --valid (breaks XIncludes). I suppose I could do two steps, but... In the meantime, you can always get rid of entities before handing off documents to dbtoepub (--noent). I'll work on a fix now. Keith - 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] ANNOUNCE: DocBook XSL and XSL-NS 1.75.0 released
is right to left because all program languages
are left-to-right.
● Robert Stayton: verbatim.xsl
Add support for @width on screen and programlisting, fixes bug #2012736.
● Robert Stayton: xref.xsl
Fix bug #1973585 xref to para with xrefstyle not handled correctly.
● Mauritz Jeanson: block.xsl
Added support for acknowledgements in article.
Support in book/part remains to be added.
● Robert Stayton: xref.xsl
Fix bug #1787167 incorrect hot text for some olinks.
● Robert Stayton: fo.xsl
Add writing-mode=tb-rl as well since some XSL-FO processors support it.
● Robert Stayton: autotoc.xsl; lists.xsl; glossary.xsl; fo.xsl; table.xsl;
pagesetup.xsl
Add support for writing-mode=rl-tb (right-to-left) in FO outputs.
Changed instances of margin-left to margin-{$direction.align.start}
and margin-right to margin-{$direction.align.end}. Those direction.align
params are computed from the writing mode value in each locale's
gentext key named 'writing-mode', introduced in 1.74.3 to add
right-to-left support to HTML outputs.
● Robert Stayton: param.xweb; param.ent
Add attribute-sets for formatting glossary terms and defs.
● Robert Stayton: param.xweb; param.ent
Add writing.mode param for FO output.
● Robert Stayton: autotoc.xsl
Fix bug 1546008: in qandaentry in a TOC, use its
blockinfo/titleabbrev or blockinfo/title
instead of question, if available. For DocBook 5, use the info versions.
● Keith Fahlgren: verbatim.xsl
Add better pointer to README for XSLTHL
● Keith Fahlgren: verbatim.xsl
More tweaking the way that XSLTHL does or does not get called
● Keith Fahlgren: verbatim.xsl
Alternate attempt at sanely including/excluding XSLTHT code
HTML
The following changes have been made to the html code since the 1.74.3 release.
● Robert Stayton: lists.xsl
Removed redundant lang and title attributes on list element inside
div element for lists.
● Robert Stayton: inline.xsl; titlepage.xsl; division.xsl; toc.xsl;
sections.xsl; table.xsl;⋯
Convert all calls to class.attribute to calls to common.html.attributes
to support dir, lang, and title attributes in html output for all elements.
Fulfills feature request #1993833.
● Robert Stayton: chunk-common.xsl
Fix bug #2750253 wrong links in list of figures in chunk.html
when target html is in a subdirectory and dbhtml filename used.
● Jirka Kosek: highlight.xsl
Inclusion of highlighting code was simplified. Only one import is
now necessary.
● Robert Stayton: chunk-common.xsl; chunktoc.xsl; docbook.xsl;
chunk-changebars.xsl; autoidx⋯
Convert function-available for node-set() to use
new $exsl.node.set.available param in test.
● Mauritz Jeanson: pi.xsl
Fixed doc bug for row-height.
● David Cramer: glossary.xsl
Internationalized punctuation in glosssee and glossseealso
● Robert Stayton: lists.xsl; html.xsl; block.xsl
More elements get common.html.attributes.
Added locale.html.attributes template which does the lang,
dir, and title attributes, but not the class attribute
(used on para, for example).
● Robert Stayton: lists.xsl
Replace more literal class atts with mode=class.attribute to support
easier customization.
● Robert Stayton: glossary.xsl
Support olinking in glosssee and glossseealso.
● Robert Stayton: inline.xsl
In simple.xlink, rearrange order of processing.
● Robert Stayton: xref.xsl
Handle firstterm like glossterm in mode=xref-to.
● Robert Stayton: lists.xsl; html.xsl; block.xsl
Added template named common.html.attributes to output
class, title, lang, and dir for most elements.
Started adding it to some list and block elements.
● Robert Stayton: qandaset.xsl
Add two new qanda.defaultlabel values so that numbered sections
and numbered questions can be distinguished. Satisfies
Feature Request #1539045.
● Robert Stayton: param.xweb; chunk-code.xsl; param.ent; xref.xsl;
chunkfast.xsl; verbatim.x⋯
Use new param exsl.node.set.available to test, handles Xalan bug.
● Robert Stayton: autoidx.xsl
Use named anchors for primary, secondary, and tertiary ids so
duplicate entries with different ids can still have an id output.
● Robert Stayton: param.xweb; param.ent
Add new param index.links.to.section.
● Robert Stayton: xref.xsl; autoidx.xsl
Pass through an id on primary, secondary, or tertiary to
the index entry, so that one could link to an index entry.
You can't link to the id on an indexterm because that is
used to place the main anchor in the text flow.
● Robert Stayton: autoidx.xsl
Add support for the new index.links.to.section param which permits
precise links to indexterms in HTML output rather than to
the section title.
● Mauritz Jeanson: synop.xsl
Added modeless template for ooclass|oointerface|ooexception.
Closes
Re: [docbook-apps] ePub metadata: dc:language
On Sat, Apr 11, 2009 at 11:16 AM, Michael Wiedmann m...@miwie.in-berlin.de wrote: I'm using the 2009-04-10 snapshot of the DocBook XSL stylesheets to take advantage of the significant improvements I've seen in the repository with respect to ePub metadata. So far (almost) everything works great: - attribute file-as of dc:creator works like expected - dc:publisher and dc:identifier works too - dc:description works if I omit the optional title. Otherwise the title content gets part of dc:description, which might not be satisfactory in any case. I don't have a final suggestion for this, but maybe there should be at least a kind of separator (e.g. ':') after the title. OK, I've added your ':'. As you know, figuring out a generic mapping of a potentially rich tag like abstract into the flatness of plain text can be difficult. Inexplicably I can't get to work setting the language of the document using the standard lang attribute of the article: Thanks for the bug report. This has been fixed in SVN revision 8407 a regression has been added with your test file. Please let me know if that does not resolve your issue. Keith - 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 and multiple sub-files and graphics
On Fri, Apr 10, 2009 at 8:22 AM, Raphael Hertzog raph...@ouaza.com wrote: Le mercredi 08 avril 2009, Keith Fahlgren a écrit : On Wed, Apr 8, 2009 at 7:31 AM, Raphael Hertzog raph...@ouaza.com wrote: This is because REXML::Parsers::PullParser doesn't expand the sub-files and thus never scans all the graphics elements. Instead it returns the Xinclude tag or the entity and those are skipped by get_image_refs(). Ugh, I'm sure this is correct. It's possibly the correct behaviour for REXML::Parsers::PullParser but that means that dbtoepub must use something else or become aware of xinclude and DTD entities. In the meantime, are you able to collapse your documents using xmllint (or similar) before feeding them into dbtoepub? - 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] attaching a patch to an issue
Upload a file attachment when creating? On Wed, Apr 8, 2009 at 4:06 PM, Eric Johnson emjoh...@progress.com wrote: How do I attach a patch to an issue in the tracker? - 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 with Chinese character
On Thu, Mar 26, 2009 at 8:11 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: After I create epub book, FBReader works fine, Adobe Digital Editions can't display Chinese character, only show ''. Is there any advice for Chinese eBook ? Either embed a font or use a different reader. Adobe Digital Editions comes with basically no font support. Keith - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
