Re: [docbook-apps] Multiplatform toolchain for outputting "nice" PDF

[Richard Hamilton]

There is a section in Chapter 1 of The Definitive Guide titled "What's New
in DocBook V5.0" that covers 4.5 to 5.0. I don't know of anything that
extends that to 5.1 or beyond.

Best regards,
DIck Hamilton
hamil...@xmlpress.net

On Tue, Jan 23, 2024 at 2:51 AM Norm Tovey-Walsh  wrote:

> > If I'm not mistaken, there is no direct summary of changes between
> DocBook 4.5
> > and 5.1.
>
> And that seems like an awful oversight on my part. I’ll plan to update
> The Definitive Guide to include a comprehensive list-of-changes
> appendix. I sort of thought that already existed, but I guess I’m not as
> clever as I think I am ;-)
>
> Be seeing you,
>   norm
>
> --
> Norm Tovey-Walsh 
> https://norm.tovey-walsh.com/
>
> > Thanks to words, we have been able to rise above the brutes; and thanks
> > to words, we have often sunk to the level of the demons.--Aldous Huxley
>


-- 

XML Press
XML for Technical Communicators
http://xmlpress.net

Re: [docbook-apps] TOC placement in pdf

[Richard Hamilton]

Hello,

The element I’ve used to put things before the toc is , which 
allows a lot more elements than you might expect, including paragraphs and 
tables.

It is an abuse of the tag, (I’ve used it only for a dedication in our books), 
but in a pinch, it might do what you need.

I’m sure others on this list may have some good (probably better:) ideas, but 
I’m not sure you can do what you want to do with any other element, unless you 
modify the stylesheets.

I hope that helps.
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Feb 20, 2023, at 23:04, rohith R  wrote:
> 
> Hi,
> 
> 
> I'm using an article style docbook and convert it into pdf.
> 
> The TOC is getting generated after the title page. I want it before the 
> section but after the front matter. How can I accomplish  this?
> 
> My article structure (docbook5):
> - title page
> - other stuff (text and couple of tables)
> - multiple sections 
> 
> I want the TOC placed after "other stuff" and before sections. 
> 
> How can I accomplish it?
> At the moment they get generated after title page when generating pdf.
> 
> Regards,
> R


-
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] LCCN in ePub metadata

[Richard Hamilton]

Has anyone figured out how to represent an LCCN (Library of Congress Control 
Number) in the metadata of an ePub?

It’s easy enough to represent it in DocBook source, using biblioid with 
class=“libraryofcongress”, and to display it on the ePub copyright page, but I 
can’t find any reference on how to code it as metadata in an ePub, and the 
current stylesheets (up to a relatively recent snapshot) don’t handle that 
class.

If anyone knows the correct way to represent this in an ePub, I’d be glad to 
add code to the ePub stylesheets to implement it and do a pull request.

Thanks,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Do different xslt processors and parsers really make a difference for pdf output?

[Richard Hamilton]

Hi Norm,

I’m resurrecting this thread to see if your thoughts on sticking with Saxon 6.5 
for XSLT 1.0 have changed now that Saxon 11 is out.

Thanks,
Dick 
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Jul 7, 2021, at 02:06, Norm Tovey-Walsh  wrote:
> 
> Kevin Dunn  writes:
>> Thanks, Norm. Yes, I evaluated fop, xep, and ahf, and bought the
>> Antenna House Formatter. My question now is between xsltproc, Saxon
>> 6.5, and Saxon 10.
> 
> Sorry I misunderstood your question.
> 
>> All three are working for me, and I don't have a reason to prefer one
>> to the others. Is there one?
> 
> Saxon 6.5 is written in Java. If you need or want extension functions
> (like the DocBook extension functions that work out image sizes), they
> are probably easier to write and use in Java then they are in C. But
> xsltproc might be faster in some cases because C is sometimes faster
> than Java. Saxon 10 is an XSLT 3.0 processor. It will be processing 1.0
> stylesheets in backwards compatible mode. That’s probably ok, I can’t
> think of any areas where it’s likely to be a problem off the top of my
> head, but it does mean you can accidentally write XSLT 3.0 instructions
> into your customization layers and they’ll slip past the processor. That
> might be really useful or really confusing depending on circumstances.
> Saxon 10 is being actively developed. If you find a bug in Saxon 6.5,
> it’s exceptionally unlikely (IMHO) that a bug fix would be released.
> That said, Saxon 6.5 has been in use for going on a couple of decades,
> so it’s not likely you’ll find any new bugs.
> 
> I’d probably use Saxon 6.5 or xsltproc for XSLT 1.0 stylesheets, but I’m
> not sure. Saxon 10 is probably a better choice if you have an eye
> towards someday using maps or arrays or packages or any of the modern
> features of the XPath/XQuery/XSLT ecosystem.
> 
> I found XSLT 3.0 compelling enough to switch.
> 
>Be seeing you,
>  norm
> 
> --
> Norman Tovey-Walsh 
> https://nwalsh.com/
> 
>> We are constantly invited to be who we are.--Henry David Thoreau


-
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] Creating Styles for an Attribute

[Richard Hamilton]

Hi Beth,

With XSLT, you can match on just the attribute.

For example:

…..

You may need to select different actions (for example if the element is a block 
vs. an inline element), but you probably won’t need to duplicate the code for 
every element.

You can also match multiple elements with the same match attribute, for example:

…

I hope that helps,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Sep 10, 2021, at 13:19, Beth Van Wie  wrote:
> 
> Hello,
>  
> I’m trying to customize the Docbook stylesheets so my profiling attributes 
> will produce colored text when I build the document without profiling. I 
> currently have stylesheets that pull out the profiled information as needed, 
> and I want to create a new stylesheet that uses the same attributes, does not 
> profile, and colors the profiled sections.
>  
> I currently use the attribute doc=”” to profile my documents.
>  
> For example:
>  
>  
>  
>  
> I commonly profile the following elements: para, row, step, procedure, 
> section, table, figure, lists (different kinds of lists), and others.
>  
> I was able to write a stylesheet that would do this for a para element, and 
> for a para element inside a step element, but the way I am doing it, I will 
> have to write a new template for each element. Is there a way I can write one 
> template to cover every time I use doc=””?
>  
> Thank you,
>  
> Beth
>  
>  
> Sent from Mail for Windows


-
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] Header and footer alignment for center cell

[Richard Hamilton]

Hi Kevin,

XSL-FO 1.1 has the values inside and outside for text-align, which should do 
the job.

Those values are supported in renderx (xep), but I think FOP doesn’t support 
them. I’m not sure about Antenna House (but I’ll bet they do).

I hope that helps.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Jul 19, 2021, at 12:39, Kevin Dunn  wrote:
> 
> In double-sided xsl-fo, how can you control text-align for the center cell of 
> the header or footer table (usually chapter or section title)?
> 
> Using the attribute-set footer.table.properties, I can set text-align, but it 
> doesn't distinguish between recto and verso pages. "center" centers the 
> center cell for both recto and verso pages, which is acceptable. But some 
> books (e.g., DocBook XSL TCG) align "end" on the recto pages and "start" on 
> the verso pages, which I find attractive.
> 
> I tried customizing footer.table.cell.properties, but that had no affect.
> 
> Would I have to customize the footer.table template, or can it be done with 
> attribute-sets?
> 
> Get Outlook for Android


-
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] Hypenation in titles

[Richard Hamilton]

Hello Philo,

The attribute you need is hyphenate, which needs to be set to “false” to turn 
off hyphenation.

There are a bunch of attribute sets with names like XXX.title.properties, where 
XXX refers to the particular title, for example section, part, etc.

You can put this attribute into the sets for titles where you want to turn 
hyphenation off.

You may also want to check out this part of Bob Stayton’s book: 
http://sagehill.net/docbookxsl/PrintCustomEx.html#Hyphenation

This covers other aspects of hyphenation, too.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Apr 7, 2021, at 11:11, Philo Calhoun  wrote:
> 
> How do you prevent hyphenation in title and subtitles  when docbook files are 
> converted to pdf with Oxygen XML Editor?


-
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] Designations in docbook for conversion to ePub

[Richard Hamilton]

Hi Philo,

Regarding your first question, if you put a role attribute on a phrase (contents), the value of that role will be carried to the 
HTML (e.g., contents)

You can then apply css normally.

Regarding your second question, I’m not so sure what’s the best thing to do, 
but you might try the same approach, wrapping the inlinemediaobject in a phrase 
with a role, then key off whatever sequence of spans you get (probably 
something like span.XYZ>span.inlinemediaobject>img).

I hope that helps.

Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Mar 24, 2021, at 15:43, Philo Calhoun  wrote:
> 
> I have a well formed book in docbook XML format. I was wondering how to solve 
> two issues:
> 
> First, what designation can I use for color attributes for text? I would like 
> it to convert over to EPub3 with a CSS that has something like span.red 
> {font-color: red;}
> 
> Second, I have several images with specified widths in the XML file, coded 
> like:
> 
>  
> 
>  
> 
>
> 
> This is fine in docbook but when I convert this to ePub, it generates ePub 
> errors - as XHTML cannot specify image width directly. To be error free, I 
> need to specify with width  through a CSS designation like img.half where 
> img.half is set to 50% width in the CSS. Is there a way in Oxygen XML to 
> specify a designation in docbook that will at least tag these images so that 
> I can add the CSS specification for width?


-
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 stylesheet for papers

[Richard Hamilton]

Hi Ismael,

A (long) while ago I created a DocBook stylesheet customization that converted 
a DocBook article into a PDF in what was (at that time) the IEEE conference 
paper format.

Your request prompted me to upload this customization to github at this URL:

https://github.com/rlhamilton/ieee-customization

As you’ll see when you look at the README, this no longer matches IEEE style 
(if it ever did:-), but it might be usable as a starting place for what you’re 
trying to do.

Feel free to take it and try it out (it’s open source under the GPL-3.0 
license).

Best regards,
Dick Hamilton

P.S. Thanks for giving me an excuse to put this on Github:-). 
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Nov 23, 2020, at 02:26, Tony Graham  wrote:
> 
> On 22/11/2020 22:50, Ismael Olea wrote:
>> On Sun, Nov 22, 2020 at 11:45 PM Peter Desjardins wrote:
>> Can you give an example of the output format you're hoping for? And would 
>> PDF/print, HTML/web, or something else suit your purpose
>> better?
>> Oh, nothing really special but journal style, so you can adjust to a
>> very precise style if required.
> 
> FWIW, there is a customisation for the Markup UK conference proceedings
> available at:
> 
>   https://github.com/sgmlguru/MUK-proc/tree/muk2019
> 
> It's not your average journal style -- for example, it's meant to be
> primarily read on-screen, so papers begin on a left-hand page so that
> they start with a two-page spread -- but you may get something useful
> from how it customises the DocBook XSL-FO stylesheets.
> 
> The customisation isn't completely polished because finishing it became
> less of a priority when the conference had to be cancelled for this year
> and was replaced by a series of webinars.
> 
> Regards,
> 
> 
> Tony Graham.
> -- 
> Senior Architect
> XML Division
> Antenna House, Inc.
> 
> Skerries, Ireland
> tgra...@antenna.co.jp
> 
> -
> 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] gentext.template.exists -- possible bug

[Richard Hamilton]

I have created a “fix” to this, but it is more complex than I expected. 

gentext.template.exists, as currently written, simply calls gentext.template 
and if the return value is null (‘’), it returns 0, otherwise it returns 1.

However, because gentext.template has to consider locale, context, and locally 
defined templates, there are multiple checks required to determine if a 
matching template actually exists.

Rather than duplicate that, I hijacked the $purpose parameter on 
gentext.template (that parameter is not used as far as I can tell), and when 
that parameter is set to ‘check’ it returns 1 anywhere that it finds and would 
have returned a value and returns 0 it it can’t find a template. If $purpose is 
anything else, gentext.template works the same as always.

gentext.template.exists stays pretty much the same, except that it sets purpose 
to ‘check’ when it calls gentext.template and returns whatever gentext.template 
returns. I take just the first character of the returned string. Because there 
are some loops that I suppose might hit a not-found value more than once, I 
thought that would be the safest course.

If that seems like the best, or at least a reasonable, way to fix this bug, I 
can make the changes and put in a pull request.

Dick 
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Aug 26, 2020, at 15:08, Richard Hamilton  wrote:
> 
> Hi Bob,
> 
> Thanks. I just filed this as an issue in github. 
> 
> I’ll take a look and see if I can find a fix.
> 
> Dick
> ---
> XML Press
> XML for Technical Communicators
> http://xmlpress.net
> hamil...@xmlpress.net
> 
> 
> 
>> On Aug 14, 2020, at 00:18, Bob Stayton  wrote:
>> 
>> I'm inclined to think that is a bug, because there are perhaps legitimate 
>> reasons for the text attribute of a particular gentext template to be empty 
>> in some languages.
>> Bob Stayton
>> 
>> b...@sagehill.net
>> On 8/11/2020 6:06 PM, Richard Hamilton wrote:
>>> The template gentext.template.exists in the 1.0 stylesheets has what may be 
>>> a bug.
>>> 
>>> This template says that it returns 1 if a gentext template exists for a 
>>> particular context and name and 0 if the template doesn’t exist.
>>> 
>>> However, if a gentext template does exist, but it has a text value that is 
>>> empty (e.g., ), 
>>> gentext.template.exists returns 0, not 1.
>>> 
>>> That is, it doesn’t distinguish between a template with a null value for 
>>> the text and a non-existent template.
>>> 
>>> My question is whether this is a bug or a feature? I’m inclined to think 
>>> it’s a bug, but I’m not sure.
>>> 
>>> If it’s a bug, I’m glad to file a report.
>>> 
>>> Best regards,
>>> Dick Hamilton
>>> ---
>>> XML Press
>>> XML for Technical Communicators
>>> 
>>> http://xmlpress.net
>>> hamil...@xmlpress.net
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> 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] gentext.template.exists -- possible bug

[Richard Hamilton]

Hi Bob,

Thanks. I just filed this as an issue in github. 

I’ll take a look and see if I can find a fix.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Aug 14, 2020, at 00:18, Bob Stayton  wrote:
> 
> I'm inclined to think that is a bug, because there are perhaps legitimate 
> reasons for the text attribute of a particular gentext template to be empty 
> in some languages.
> Bob Stayton
> 
> b...@sagehill.net
> On 8/11/2020 6:06 PM, Richard Hamilton wrote:
>> The template gentext.template.exists in the 1.0 stylesheets has what may be 
>> a bug.
>> 
>> This template says that it returns 1 if a gentext template exists for a 
>> particular context and name and 0 if the template doesn’t exist.
>> 
>> However, if a gentext template does exist, but it has a text value that is 
>> empty (e.g., ), gentext.template.exists 
>> returns 0, not 1.
>> 
>> That is, it doesn’t distinguish between a template with a null value for the 
>> text and a non-existent template.
>> 
>> My question is whether this is a bug or a feature? I’m inclined to think 
>> it’s a bug, but I’m not sure.
>> 
>> If it’s a bug, I’m glad to file a report.
>> 
>> Best regards,
>> Dick Hamilton
>> ---
>> XML Press
>> XML for Technical Communicators
>> 
>> http://xmlpress.net
>> hamil...@xmlpress.net
>> 
>> 
>> 
>> 
>> 
>> -
>> 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] Update on biblioentry proposal

[Richard Hamilton]

This is an update on the work I’ve been doing on biblioentry styles.

I just posted an updated proposal for conventions for biblioentry elements at: 
https://rlhamilton.net/biblioentry/

You can see a PDF at: https://rlhamilton.net/biblioentry/bib-article.pdf

The objective is to create a set of guidelines that show writers how to create 
biblioentry elements that can be rendered in various styles (e.g., Chicago, 
MLA, APA, etc.).

I started by creating some guidelines that I thought would work, then created a 
customization to take biblientry elements written to those guidelines and 
render them in Chicago (CMOS) style.

That resulted in a few minor changes and some additions to the guidelines I 
posted a week or so ago (you can still see the first proposal at 
https://rlhamilton.net/biblioentry.orig/).

The html and pdf links shown above use that customization, which at this point 
is reasonably function for books and for articles/papers/chapters in 
journals/proceedings/books. There are some examples at the end of the proposal.

The rest of the rendering is mostly straight docbook using the XSL 1.0 
stylesheets, though I grabbed Norm’s new css files, which make the html a bit 
easier to read and navigate (though not as pretty as html created with those 
stylesheets in mind:-).

All comments are welcome.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] gentext.template.exists -- possible bug

[Richard Hamilton]

The template gentext.template.exists in the 1.0 stylesheets has what may be a 
bug.

This template says that it returns 1 if a gentext template exists for a 
particular context and name and 0 if the template doesn’t exist.

However, if a gentext template does exist, but it has a text value that is 
empty (e.g., ), gentext.template.exists 
returns 0, not 1.

That is, it doesn’t distinguish between a template with a null value for the 
text and a non-existent template.

My question is whether this is a bug or a feature? I’m inclined to think it’s a 
bug, but I’m not sure.

If it’s a bug, I’m glad to file a report.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Validating against Schematron

[Richard Hamilton]

Well that explains it. I was under the impression that jing and trang were 
stuck in amber back in 2009. I just checked and the version I had was from 2009.

I just tried the 2018 version, and it works fine with .sch files.

Thanks for setting me straight.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Jul 29, 2020, at 23:59, Norman Tovey-Walsh  wrote:
> 
> Richard Hamilton  writes:
>> Running it using docbook.sch, I get a namespace error on db:, which is
>> strange, since db is properly declared in the Schematron file. I even
>> modified a test file so that it also used the prefix db: defined the
>> same way, but no luck.
> 
> If I grab the latest 5.2 repo and build it, jing (20181222) validates
> src/test/docbook/pass/article.001.xml with build/docbook.sch without any
> errors.
> 
> And if I take out the version attribute, I get:
> 
> $ jing build/docbook.sch src/test/docbook/fail/article.001.xml
> /Users/ndw/Projects/docbook/docbook/src/test/docbook/fail/article.001.xml:1: 
> error: assertion failed:
>  If this element is the root element, it must have a version attribute.
> 
>Be seeing you,
>  norm
> 
> --
> Norman Tovey-Walsh 
> https://nwalsh.com/
> 
>> The greatest of all secrets is knowing how to reduce the force of
>> envy.--Cardinal De Retz


-
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] Validating against Schematron

[Richard Hamilton]

Hi Dave,

Thanks for the suggestion. I hadn’t used Jing in so long that I didn’t remember 
that it has (or claims) support for Schematron.

Did you modify Jing or the Schematron rules? I tried running it using the 
docbookxi.rng schema and also with the docbook.sch schematron rules (DocBook 
5.0, .1, and 5.2) and didn’t have much success.

Running it using docbook.sch, I get a namespace error on db:, which is strange, 
since db is properly declared in the Schematron file. I even modified a test 
file so that it also used the prefix db: defined the same way, but no luck.

Running it on docbookxi.rng (with embedded schematron rules), it doesn’t flag 
any Schematron errors (I removed version from the root element and nested 
 inside a , neither of which is not allowed by the rules). I did 
confirm that it flags errors against just the schema.

Any ideas would be welcome.

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Jul 28, 2020, at 23:49, Dave Pawson  wrote:
> 
> On Tue, 28 Jul 2020 at 22:55, Richard Hamilton  wrote:
>> 
>> This is a question for the group.
>> 
>> What do you currently use for validating DocBook agains both RelaxNG and 
>> Schematron?
>> 
>> I’ve been looking around and downloading and trying some 10-to-15 year old 
>> solutions, but I figure there has to be something newer (or an update to one 
>> of the older ones) that does the job.
> 
> Jing? Fast and accurate. Does the job well IMHO.
> 
> 
> regards
> 
> 
> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.


-
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] Validating against Schematron

[Richard Hamilton]

This is a question for the group.

What do you currently use for validating DocBook agains both RelaxNG and 
Schematron?

I’ve been looking around and downloading and trying some 10-to-15 year old 
solutions, but I figure there has to be something newer (or an update to one of 
the older ones) that does the job.

Any pointers would be greatly appreciated.

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Draft of a proposal for conventions for biblioentry element

[Richard Hamilton]

I just posted a draft proposal for conventions for the biblioentry element. You 
can find it at: https://rlhamilton.net/biblioentry/

The idea is to provide conventions that would allow a writer to create 
biblioentry elements that can be reliably rendered in various styles (Chicago, 
MLA, etc.). And to give implementers guidance in creating stylesheets that 
would render those styles.

This is just a draft that has a fair number of open questions, which are listed 
in Section 7.

Thanks to Peter Flynn, Tony Graham, and Norm Walsh for their suggestions on the 
mailing list and to Peter Flynn for his examples. Also, thanks to Norm for the 
xslTNG stylesheets, which I used to generate the html for the article.

FYI, my next step, which I’ve begun as a customization of the XSL 1.0 html 
stylesheets, is to implement Chicago and at least one other style (probably 
MLA), both as a proof of concept and to make sure there aren’t other 
conventions that need to be defined. I was tempted to do them in xslTNG, but I 
really need fo/PDF for my business, so that will have to wait. If they work 
well, I’ll make them to the community.

Please take a look and post your thoughts. I’m sure there’s plenty that I 
missed:-).

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Biblioentry markup standards -- identifying the type of entry

[Richard Hamilton]

I’m posting this to the DocBook mailing list, but double posting do 
DocBook-apps because the discussion started on that list.

Background: I’ve been using bibliomixed for XML Press publications. I would 
like to move to using biblioentry, so I can cover more than one output style. 
We primarily use the Chicago Manual of Style as our guide, but I would like to 
be able to easily use other styles.

My objective is to create (over time) customizations that would take a 
biblioentry in a consistent format and generate output that conforms to 
Chicago, APA, and other styles.

As part of that effort, I decided first to look for and create test examples 
for a variety of cases and begin creating guidelines.

This first issue I’ve uncovered is the question of how to identify what kind of 
entry an instance is (e.g., book, article, etc.).

I can find no standard method for doing that in DocBook, including the 
Publisher’s schema..

The ISO690 extension uses the role attribute on the biblioentry element.

Certain types can be guessed at by looking at biblioset (if it’s used) or the 
pubwork attribute on citetitle (if citetitle is used rather than title).

Both of these apply only if you use those elements. However, there are plenty 
of examples where biblioset is not needed and would just add complexity. And 
citetitle seems not to be the best choice for expressing a title in this 
context (especially if you want to separate out a subtitle).

So, am I missing something here, or is there no standard method for defining 
the type of a biblioentry?

If there isn’t an established method, does anyone have any ideas on how best to 
do this?

Best regards,
Dick Hamilton 
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Bibliographic styling

[Richard Hamilton]

Hi Norm,

That’s too bad. 

For the moment, I think I’ll back into the project by creating a set of 
biblioentry tests based on the existing bibliographies in XML Press books (they 
are currently all in bibliomixed form) and a set of examples from a book called 
Cite Right, which is a guide to a variety of citation styles, including 
Chicago, MLA, APA, and a bunch of others.

In addition to having a good set of tests, that should also be a test to see if 
biblioentry is sufficient to express a wide range of types, especially newer 
forms that have evolved since biblioentry was created.

If you, or anyone on the mailing list, have examples that I could add, I’ll be 
glad to take them.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On May 25, 2020, at 01:05, Norman Tovey-Walsh  wrote:
> 
> Richard Hamilton  writes:
>> Is the following correct?
> 
> [ Not intending to speak for Peter… ]
> 
>> - CSL encodes the details of how a particular style works. It provides
>> a machine readable set of instructions that can be used by a processor
>> to generate output that follows a particular citation style.
> 
> Yep. 
> 
>> - To use CLS with DocBook, you could write a stylesheet that would
>> take a biblioentry and format it based on the contents of a particular
>> CSL file. You might do that as a pre-processor and convert biblioentry
>> into bibliomixed, or you could convert directly from biblioentry into
>> fo, html, etc.
> 
> Also, yep.
> 
>> - Or, at least for HTML, you could convert a biblioentry into CSL-JSON
>> and convert it to HTML with citeproc-js or pandoc-citeproc. I haven’t
>> tried out citeproc-js or pandoc-citeproc, so I could be way off on
>> this one.
> 
> That might actually be the only short-term practical solution. I’ve
> filed a few bugs on the CSL spec and its test suite. Near as I can tell,
> what actually exists is a reference implementation (citeproc-js) and a
> specification that only incompletely describes the behavior of that
> implementation.
> 
> I still might poke at a DocBook+CSL to HTML stylesheet, but my
> enthusiasm as waned significantly. A third party implementation of CSL
> is going to fail tests in the test suite. The specification is not going
> to reflect why those tests *should* pass, and the only recourse is going
> to be to reverse engineer the citeproc-js implementation (either
> literally or by making something that’s bug-compatible; in as much as I
> assert that an implementation that doesn’t conform to the specification
> is buggy). Kind of disappointing, really.
> 
>Be seeing you,
>  norm
> 
> --
> Norman Tovey-Walsh 
> https://nwalsh.com/
> 
>> The common excuse of those who bring misfortune on others is that they
>> desire their good.--Vauvenargues


-
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] Bibliographic styling

[Richard Hamilton]

Hi Peter,

Looks interesting. I’ve poked around some and have a high-level, but possibly 
inaccurate idea of how this might work.

Is the following correct?

- CSL encodes the details of how a particular style works. It provides a 
machine readable set of instructions that can be used by a processor to 
generate output that follows a particular citation style.

- To use CLS with DocBook, you could write a stylesheet that would take a 
biblioentry and format it based on the contents of a particular CSL file. You 
might do that as a pre-processor and convert biblioentry into bibliomixed, or 
you could convert directly from biblioentry into fo, html, etc.

- Or, at least for HTML, you could convert a biblioentry into CSL-JSON and 
convert it to HTML with citeproc-js or pandoc-citeproc. I haven’t tried out 
citeproc-js or pandoc-citeproc, so I could be way off on this one.

So, am I in the right ballpark?

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On May 23, 2020, at 05:43, Peter Fleck  wrote:
> 
> Richard,
> 
> Would it be possible to step back a level and work on it in combination with 
> CSL? https://citationstyles.org/ That way, it would not just be limited to 
> CMOS. (Although having CMOS would be a major bonus for me.)
> The Github repo for the CSL styles are 
> https://github.com/citation-style-language/styles
> There are a few on that list I would find extremely helpful.
> 
> Peter
> 
> On Sat, 23 May 2020 at 12:43, Norman Tovey-Walsh  wrote:
> Richard Hamilton  writes:
> > I’m thinking of taking on the task of creating a docbook
> > customization, similar to the iso690 customization, to process
> > bibliographic information in the Chicago Manual of Style format.
> >
> > Before I dive in head first, I thought I’d check with the group to see
> > if anyone has already done that.
> 
> I wonder if it would be possible to describe the format in some
> declarative way and either derive the stylesheet from that or interpret
> it?
> 
> I looked briefly at doing that with BibTeX once, but that seemed a
> little too challenging for the amount of free time that I have (which is
> generally measured in negative numbers).
> 
> > To streamline the markup of inline references to bibliographic
> > entries, I wonder whether it would stretch the standard too far to
> > interpret a linkend in a citetitle as pointing to a bibliographic
> > reference and process it as though it were a biblioref immediately
> > following the citetitle. So, for example,
> >
> > DocBook XSL: The 
> > Complete Guide
> >
> > would be interpreted as equivalent to  > pubwork=“book”>DocBook XSL: The Complete Guide > linkend=“ref.stayton2007”/>
> 
> That doesn’t seem unreasonable to me. What I tend to do myself, however,
> is just the following:
> 
> 
> 
> Which I then render inline as the title from the bibliography entry with
> whatever styling seems appropriate. Saves me from having to type the
> titles each time.
> 
> > But, to take it a step further, how about interpreting  > pubwork=“book” linkend=“ref.stayton2007”/> the same way, but pulling
> > the title from the referenced biblioentry/bibliomixed element when the
> > citetitle element is empty.
> >
> > Any thoughts?
> 
> That’s what biblioref is for? :-)
> 
> Be seeing you,
>   norm
> 
> --
> Norman Tovey-Walsh 
> https://nwalsh.com/
> 
> > Next to knowing when to seize an opportunity, the most important thing
> > in life is to know when to forego an advantage.--Benjamin Disraeli


-
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] Bibliographic styling

[Richard Hamilton]

Hi Norm,

You’re exactly right. biblioref is the right element for this. I was so focused 
on citetitle that I missed that entirely:-).

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On May 23, 2020, at 04:42, Norman Tovey-Walsh  wrote:
> 
> Richard Hamilton  writes:
>> I’m thinking of taking on the task of creating a docbook
>> customization, similar to the iso690 customization, to process
>> bibliographic information in the Chicago Manual of Style format.
>> 
>> Before I dive in head first, I thought I’d check with the group to see
>> if anyone has already done that.
> 
> I wonder if it would be possible to describe the format in some
> declarative way and either derive the stylesheet from that or interpret
> it?
> 
> I looked briefly at doing that with BibTeX once, but that seemed a
> little too challenging for the amount of free time that I have (which is
> generally measured in negative numbers).
> 
>> To streamline the markup of inline references to bibliographic
>> entries, I wonder whether it would stretch the standard too far to
>> interpret a linkend in a citetitle as pointing to a bibliographic
>> reference and process it as though it were a biblioref immediately
>> following the citetitle. So, for example,
>> 
>> DocBook XSL: The 
>> Complete Guide
>> 
>> would be interpreted as equivalent to > pubwork=“book”>DocBook XSL: The Complete Guide> linkend=“ref.stayton2007”/>
> 
> That doesn’t seem unreasonable to me. What I tend to do myself, however,
> is just the following:
> 
> 
> 
> Which I then render inline as the title from the bibliography entry with
> whatever styling seems appropriate. Saves me from having to type the
> titles each time.
> 
>> But, to take it a step further, how about interpreting > pubwork=“book” linkend=“ref.stayton2007”/> the same way, but pulling
>> the title from the referenced biblioentry/bibliomixed element when the
>> citetitle element is empty.
>> 
>> Any thoughts?
> 
> That’s what biblioref is for? :-)
> 
>Be seeing you,
>  norm
> 
> --
> Norman Tovey-Walsh 
> https://nwalsh.com/
> 
>> Next to knowing when to seize an opportunity, the most important thing
>> in life is to know when to forego an advantage.--Benjamin Disraeli


-
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] Bibliographic styling

[Richard Hamilton]

I’m thinking of taking on the task of creating a docbook customization, similar 
to the iso690 customization, to process bibliographic information in the 
Chicago Manual of Style format.

Before I dive in head first, I thought I’d check with the group to see if 
anyone has already done that.

Also, I have an additional question that might more appropriately belong in the 
docbook list, but I’ll give it a shot:

To streamline the markup of inline references to bibliographic entries, I 
wonder whether it would stretch the standard too far to interpret a linkend in 
a citetitle as pointing to a bibliographic reference and process it as though 
it were a biblioref immediately following the citetitle. So, for example,

DocBook XSL: The Complete 
Guide

would be interpreted as equivalent to DocBook XSL: 
The Complete Guide

Since the ultimate result is a link (the only difference is that the link text 
would be an inline tag, e.g., [Stayton 2007], rather than the title text), I 
don’t think it’s too far out there.

But, to take it a step further, how about interpreting 
the same way, but pulling the title from the referenced biblioentry/bibliomixed 
element when the citetitle element is empty.

Any thoughts?

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Converting Docbook epub to Kindle shows warnings

[Richard Hamilton]

Hi Bob and Robert,

Things get curiouser and curiouser:-). It looks like kindlegen does pretty much 
the same conversion as the previewer.

When I use the kindle app on my Macbook, the variable lists (i.e., dl lists) do 
not nest, but when I run the same file on the previewer, of in the app on my 
iphone, it works fine.

So, the problem may be viewer specific. The only difference is that kindlegen 
complains about this and provides false notes about closing off tags, while the 
previewer is silent.

Bob, can you post or send me your modification of autoidx.xsl? I’d like to try 
it out, and I’m glad to be a tester. And does this index generate page number

Best regards,
Dick 

P.S. I’m going to get Solar Dividends, too. The topic is interesting, and I’d 
like to see the results of that autoidx.xsl. Thanks for making it available as 
a free ebook.
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Mar 20, 2020, at 09:13, Bob Stayton  wrote:
> 
> The index in my Power Shift ebook does not use dl, dt, and dd in the epub 
> xhtml.  I gave up on them and rewrote autoidx.xsl to output div elements 
> instead, with CSS to supply the indents.  In a nutshell:
> 
>   became 
> 
>  became 
> 
>  became 
> 
> That's it.  Since the divs are already nested by the indexing templates, it 
> turns out that the only CSS I needed was:
> 
> div.dd {
>   margin-left: 2em;
> }
> 
> I had intended to fold this back into the next release, so thanks for 
> reminding me about this.
> 
> By the way, if you liked Power Shift, you should check out my new book Solar 
> Dividends which describes how to use solar energy to eliminate poverty in the 
> world.
> Bob Stayton
> 
> b...@sagehill.net
> On 3/19/2020 9:16 PM, Robert Nagle wrote:
>> This is very interesting to me.  I have tried for two  projects to generate 
>> indexes that would work on Kindle. The indexterm content had both a primary 
>> and secondary level. Everything would look good in epubs on epub reading 
>> systems(and be valid, etc), but in mobipocket it would render inconsistently 
>> the elements in the index -- sometimes indenting, sometimes putting them on 
>> the same line. It was a mess. Even though it rendered fine in Kindle 
>> Previewer on all simulated devices, the dl, dt, dd just scrambled everything 
>> on Kindle app for android as well as on e-ink Paperwhites. 
>> 
>> I spent a  lot of time trying to troubleshoot (and the details were fuzzy), 
>> but concluded that the problem lay not with docbook but with kindlegen (or 
>> maybe the css support on kindle reading systems). It's frustrating because 
>> having a good multilevel index is standard on many nonfiction ebooks.  
>> 
>> On the other hand, when looking at Bob's POWER SHIFT ebook (which came out a 
>> few years ago), the index rendered fine on Kindle. - although in that ebook, 
>> it used page numbers for an ebook. 
>> 
>> (In my projects, I used   > select="1"> and   > select="0"> )
>> (I could provide an ebook example if you need) 
>> 
>> BTW, never got around to saying it, but Bob I enjoyed Power Shift ebook 
>> 
>> Robert Nagle 
>> 
>> 
>>  
>> 
>> 
>> 
>> From: Richard Hamilton 
>> To: Lars Vogel 
>> Cc: Jason Zech , DocBook Apps 
>> 
>> Bcc: 
>> Date: Thu, 19 Mar 2020 18:42:50 -0700
>> Subject: Re: [docbook-apps] Converting Docbook epub to Kindle shows warnings
>> Hi Lars,
>> 
>> I know this is from a long time ago, but I just ran into the same problem 
>> with a file that nests variable lists using the list-presentation=“blocks” 
>> processing instruction.
>> 
>> In that case, the XHTML5 (this is with 1.79.2, building an epub3) is valid, 
>> but kindlegen doesn’t like the nesting. It closes off the highest level  
>> and  elements and flags some  elements as being invalid.
>> 
>> The result doesn’t lose any content, but it removes the nesting and flattens 
>> everything to one level.
>> 
>> As with your case, the epub is valid and when displayed, the nesting is fine.
>> 
>> At this point, I’m convinced that the problem is in kindlegen. I just used 
>> the Kindle previewer, which wasn’t available in 2012, and it created a .mobi 
>> file that preserves the nesting (at least on the devices I tried in the 
>> previewer).
>> 
>> Anyway, this is probably way to late to help, but I figured I’d add it to 
>> the thread in case someone runs into it in the future, since it is still a 
>> problem using kindlegen.
>> 
>> Best regards,
>> Dick Hamilton
>> ---
>> XML Press
>> XML for Technical Communicators
>> http://xmlpress.net
>> hamil...@xmlpress.net  
>> 
>> -- 
>> Robert Nagle
>> 5115 Sandyfields Ln Katy, TX 77494
>> (Cell) 832-251-7522


-
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] Converting Docbook epub to Kindle shows warnings

[Richard Hamilton]

Hi Lars,

I know this is from a long time ago, but I just ran into the same problem with 
a file that nests variable lists using the list-presentation=“blocks” 
processing instruction.

In that case, the XHTML5 (this is with 1.79.2, building an epub3) is valid, but 
kindlegen doesn’t like the nesting. It closes off the highest level  and 
 elements and flags some  elements as being invalid.

The result doesn’t lose any content, but it removes the nesting and flattens 
everything to one level.

As with your case, the epub is valid and when displayed, the nesting is fine.

At this point, I’m convinced that the problem is in kindlegen. I just used the 
Kindle previewer, which wasn’t available in 2012, and it created a .mobi file 
that preserves the nesting (at least on the devices I tried in the previewer).

Anyway, this is probably way to late to help, but I figured I’d add it to the 
thread in case someone runs into it in the future, since it is still a problem 
using kindlegen.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Jul 12, 2012, at 01:00, Lars Vogel  wrote:
> 
> Hi Jason,
> 
> thanks for the pointer, I try to dig into the problem.
> 
> Best regards, Lars
> 
> 2012/7/10 Jason Zech :
>> This sounds like a bizarre problem I had a few months ago. I tracked it down
>> to my toc.ncx not matching up with toc.html, or something like that. Your
>> issue may be different, but it’s an idea.
>> 
>> 
>> 
>> From: Bob Stayton [mailto:b...@sagehill.net]
>> Sent: Tuesday, July 10, 2012 10:54 AM
>> To: Lars Vogel; DocBook Apps
>> Subject: Re: [docbook-apps] Converting Docbook epub to Kindle shows warnings
>> 
>> 
>> 
>> I have also seen those messages and don't understand what they mean.  When I
>> check the XHTML file in Oxygen, it reports that it is well-formed and valid,
>> so there are no missing tags that need to be "Forcefully closed".
>> 
>> 
>> 
>> Your output appears to be from the epub stylesheet.  You might try the epub3
>> stylesheet in version 1.77.1 of the stylesheets.  It does not use  for
>> the TOC, so kindlegen does not report those  errors.  However, kindlegen
>> still Forcefully closes the valid  and 
>> elements in the TOC file.
>> 
>> 
>> 
>> Bob Stayton
>> Sagehill Enterprises
>> b...@sagehill.net
>> 
>> 
>> 
>> 
>> 
>> - Original Message -
>> 
>> From: Lars Vogel
>> 
>> To: DocBook Apps
>> 
>> Sent: Tuesday, July 10, 2012 1:53 AM
>> 
>> Subject: [docbook-apps] Converting Docbook epub to Kindle shows warnings
>> 
>> 
>> 
>> Hello,
>> 
>> I'm using Apache Ant to create an epub with the XSL stylesheets. This
>> works fine.
>> 
>> During the conversion to .mobi via the Amazon command line tool
>> kindlegen I get several warnings which may indicate that the generated
>> epub has some issues. See below for the error messages. I attached the
>> file in question. I noted that in the Kindle version several TOC
>> entries are in the same line: I think this might be the reason for
>> this.
>> 
>> Has anyone seen such issues and know how to solve them?
>> 
>> Best regards, Lars
>> 
>> Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 004
>> Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 004
>> Warning(inputpreprocessor):W29010: Tag rejected due to being used in
>> unauthorized scope: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 004
>> Warning(inputpreprocessor):W29010: Tag rejected due to being used in
>> unauthorized scope: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 004
>> Warning(inputpreprocessor):W29010: Tag rejected due to being used in
>> unauthorized scope: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 005
>> Warning(inputpreprocessor):W29010: Tag rejected due to being used in
>> unauthorized scope: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 005
>> Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 005
>> Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: 
>>  in file: /tmp/mobi-v0Xfht/OEBPS/bk01-toc.html line: 005
>> 
>> 
>> 
>> 
>> -
>> 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: 

Re: [docbook-apps] No indent on the first paragraph of a page

[Richard Hamilton]

Hi Peter,

I suspect that this is going to be very difficult, if not impossible, because 
pagination happens in the FO processor, and the stylesheets don’t know where 
the FO processor will do page breaks. Therefore, the stylesheets can’t identify 
which paragraphs will appear at the top of a page.

I don’t keep up with the latest in FO processing, so there may be a way that 
I’m unaware of to code this as an option with one of the commercial processors 
(XEP or Antenna House), but I doubt there’s a way to do this with FOP.

Also, are you sure you want to do this in this way? The more common variable 
style that I’ve seen is where you indent the second and subsequent paragraphs 
in a chapter or after a heading, but you don’t indent the first paragraph. That 
is much easier to implement, because all the information you need is available 
to the stylesheets. In fact, a few years ago, Jirka Kosek provided some code to 
do just that. Here is a link to the mailing list entry about this, but be aware 
that this is nearly 14 years old, so I wouldn’t just drop it into the current 
code without doing some testing:-).

https://cygwin.com/ml/docbook-apps/2004-q2/msg00105.html

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Dec 4, 2017, at 02:44, Peter Fleck  wrote:
> 
> Hi,
> 
> I have the following code that indents the first line of paragraphs:
> 
>  match="d:*/d:para[preceding-sibling::d:para]|d:para[contains(@role,'indent')]">
>   
> 
>   
> 
> 
> Is there a way to not indent the paragraph if it is the first paragraph of a 
> page?
> 
> Using:
> 
> Apache FOP 2.2
> Docbook 5.1
> Stylesheets 1.79.2
> 
> Thanks,
> 
> Peter


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] using curly quotes for epubs -- best practices?

[Richard Hamilton]

Hi Robert,

I avoid the issue entirely by using the DocBook  element.

The  element gives you language appropriate quotation marks, and it will 
also handle quotes within quotes, which is a nice touch.

I don’t know of any automated smart quote processing in the DocBook stylesheets 
(in fact, I’m nearly certain there isn’t any, beyond processing ).

If you have existing text with curly or straight quotes in the source, 
converting them can be a bit tricky. I use emacs macros to replace quoted text 
with …, and that works surprisingly well. I match on the opening 
quote, capture everything until the ending quote, then replace with 
captured text. You need to be careful, since misplaced quotes 
can cause some strange results, and you need to handle both curly and straight 
opening and closing quotes, but generally it works well.

I think you can do something similar in Oxygen, but I haven’t done it myself. 
Check out this page and look for the discussion about “capturing groups": 
https://www.oxygenxml.com/doc/versions/18/ug-editor/topics/find-replace-dialog.html

I hope that helps.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Nov 30, 2017, at 16:13, Robert Nagle  wrote:
> 
> Up to now I've avoided dealing with the issue of smart quotes (curly quotes)  
> by simply dealing with straight quotes in my docbook source. 
> 
> About 75% of my source comes from MS Word, and I then find some way to paste 
> or convert into Docbook XML. 
> 
> Another 25% comes from .txt or from content I actually edit in Docbook. 
> 
> When I paste from MS Word to HTML, I often would get encoding errors. Even 
> when I didn't get encoding errors, the conversion would be inconsistent or 
> difficult to proof. 
> 
> Personally I could care less about smart quotes vs. curly quotes, and 
> honestly I believe that the reading system should be handling the conversion 
> from straight to curly quotes, but if the work involved in getting curly 
> quotes was minimal enough, I'd consider doing it. 
> 
> I was wondering whether anyone here has created  best practices to make sure 
> curly quotes are consistently implemented. (Does Docbook have anything to do 
> with it?). I use Oxygen, but I don't see any option in Author mode to use 
> only curly quotes. 
> 
> I usually just paste .txt files into a docbook file in  Author mode of 
> Oxygen. I don't really know of an easy way to do search/replace without 
> requiring a lot of quality control. Does anyone have any ideas? 
> 
> Thanks for your input. 
> 
> Robert Nagle
> 
> 
> 
> 
> 
> -- 
> Robert Nagle
> 22118 FINCASTLE DR KATY TX 77450-1727
> (Cell) 832-251-7522; (Skype) idiotprogrammer;  Carbon Neutral Since Jan 2010
> 


-
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] Documenting code

[Richard Hamilton]

It is an interesting book (I got the chance to review an early copy), but it 
isn’t particularly about documenting code. Rather it is about creating docs 
using the development methods and tools (e.g., git) that programmers use.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Mar 1, 2017, at 00:19, Dave Pawson  wrote:
> 
> http://docslikecode.com/
> 
> For me, first book I've seen (I think) on
> documenting code.
> 
> regards
> 
> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
> 
> -
> 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] Assemblies

[Richard Hamilton]

Hi Simon,

I would use the issue mechanism first, especially if you’ve fixed a bug. If 
you’re doing an enhancement, you might also want to discuss it on this mailing 
list.

FYI, since you’re talking about assemble.xsl, this is not a question for the 
DocBook TC. However, you did post it to the right group; docbook-apps is for 
discussion about the stylesheets.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Feb 28, 2017, at 05:31, Simon Dew  wrote:
> 
> Hello,
> 
> A question for the DocBook Technical Committee, I guess.
> 
> I've been experimenting with assemblies, and I'm doing some hacking on 
> assemble.xsl [1].  I haven't found any notes for contributors on the DocBook 
> github site, so I thought I'd ask here. Is it okay if I send some pull 
> requests? Would you prefer it if I raised an issue for each one first?
> 
> [1] 
> https://github.com/docbook/xslt10-stylesheets/blob/master/xsl/assembly/assemble.xsl
> 
> 
> Cheers
> -- 
> Simon Dew
> 
> simonjaba...@gmail.com
> https://janiveer.github.io
> 
> -
> 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] does not number...

[Richard Hamilton]

Hi,

Here is the link to the part of Bob’s book that covers the Saxon processor:

http://sagehill.net/docbookxsl/InstallingAProcessor.html#InstallSaxon

I think you can keep the xmllint processing as is (I use it for XInclude 
processing, too), and just swap in saxon for xsltproc, using Bob’s instructions.

I don’t bother swapping in Xerces (I don’t use any of the features that go 
beyond what Saxon supports).

Best regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Feb 10, 2017, at 12:26, stim...@comcast.net wrote:
> 
> Hi,
>  
> I was going by this reference as to requirements, and have not read the whole 
> book (thus I did not yet see the Java requirement):
> http://tdg.docbook.org/tdg/5.1/programlisting.html
>  
> Admittedly I'm trying to do something quicker than I should and not reading 
> everything (I've been through a lot of material, but it's just a drop in the 
> bucket for everything needed when I really just need to sit down and write 
> content). I've had some frustrations getting the Java-based processors 
> working and have tried to stick to the xmllint/jing/xsltproc family for that 
> single reason. The Java-based processing answer likely also answers my 
> earlier syntax highlighting question about whether to abandon my current 
> approach with xmllint.
>  
> To use Saxon or Xalan I would have to change the current build scheme, which 
> I've never succeeded at:
> xmllint --output "${OBJ}/${TITLE}_monolithic.xml" --nonet --noent -xinclude 
> "${CONTENT}/${TITLE}.xml"
> xsltproc --output ${OBJ}/${TITLE}_monolithic.fo ${XSLT}/docbook.xsl 
> ${OBJ}/${TITLE}_monolithic.xml
> fop -c ${PREFIX}/fop.xconf -fo ${OBJ}/${TITLE}_monolithic.fo -pdf 
> ${OUT}/${TITLE}.pdf
>  
> I realize I'm probably asking a lot, but is there any advice I can get on 
> editing that chain of commands to instead work with Saxon or Xalan? Getting 
> past the tools on the command line (for a hand written Makefile) is just 
> getting frustrating and is why the current chain of commands have never 
> evolved to anything Java-based.
>  
> I do plan on reading more (I'm not resisting reading), but there are other 
> requirements which tend to require at least a draft to be available sooner 
> rather than later.
>  
> Thanks!
>  
> - Original Message -
> From: Bob Stayton 
> To: stim...@comcast.net, Docbook 
> Sent: Fri, 10 Feb 2017 19:09:00 - (UTC)
> Subject: Re: [docbook-apps]  does 
> not number...
> Hi,
> Did you read this section in my online book about line numbering? It 
> only works with Java-based processors.
> Bob Stayton
> Sagehill Enterprises
> b...@sagehill.net
> On 2/10/2017 11:01 AM, stim...@comcast.net wrote:
> > Hi,
> >
> > Under DocBook 5.1 I've been able to list programs, but line numbering
> > has no effect (and there is no error under xmllint or jing). Is there
> > some ENTITY or other precondition required for line numbering under 5.1?
> >
> > Thanks!


-
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] Odd Characters in UTF-8, Docbook 5.1

[Richard Hamilton]

I’m getting out of my depth on fop, so maybe someone else on the list can help 
here.

However, diving in deeper than I should:-)I suspect the problem is number 1.

I suggest running fop with the -d (debug) mode, and you might also try -x, 
which will dump the configuration; that way you can see if the configuration 
fop uses is what you think it is using.

Good luck,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Feb 1, 2017, at 15:21, stim...@comcast.net wrote:
> 
> Hi,
>  
> So what my experimenting shows so far for trying to change font is that I can 
> adjust param.xsl and switch between serif or sans-serif. The result depends 
> on what is available in fop.xconf which lists Times-Roman for serif, and 
> Helvetica for sans-serif. I've attempted to add an additional font definition 
> for DejaVuSans by the following inside the  of fop.xconf:
>  
> 
> 
>
> 
>  
> I am unable to name "DejaVuSans" instead of "sans-serif" in param.xsl (it 
> falls back to Symbol). I see three possibilities...
> 1. My DejaVuSans declaration is wrong.
> 2. I have to remove Helvetica in fop.xconf from the sans-serif listings.
> 3. The Docbook parameters you mentioned are somewhere outside of fop.xconf or 
> param.xsl.
>  
> It seems unlikely I need to remove Helvetica, more likely there is another 
> configuration elsewhere. However, I don't see any occurrence of "Helvetica" 
> in any of the other Docbook files under the 
> "stylesheet/docbook-xsl-ns-1.79.1/" directory tree which are related to this 
> case (for example, there is a subdirectory for "slides" which would seem to 
> be unrelated to the "book" being published to pdf). The full path to the ttf 
> font file is available and readable to everyone; this is verifiable with a 
> font editor (one reason to choose DejaVu is that the font editor actually 
> shows the desired box drawing font glyphs at index 0x2500 and on).
>  
> Am I missing another file to edit, or am I simply using the wrong syntax for 
> my addition of DejaVuSans?
>  
> Thanks!
>  
> - Original Message -
> From: Richard Hamilton <hamil...@xmlpress.net>
> To: stim...@comcast.net
> Cc: Docbook <docbook-apps@lists.oasis-open.org>
> Sent: Wed, 01 Feb 2017 20:36:59 - (UTC)
> Subject: Re: [docbook-apps] Odd Characters in UTF-8, Docbook 5.1
> Hi,
> There are two steps to the font assignment process: 1) configuring fop’s 
> fonts and 2) setting DocBook parameters to call the fonts you have configured 
> in fop.
> In this case, the mapping between serif and Times (and sans-serif and 
> Helvetica) happens in the fop configuration file, fop.xconf.
> So, when you set the DocBook parameter to sans-serif, fop defaults to 
> Helvetica. If you want sans-serif to default to something else, or if you 
> want to add a font, you need to change the configuration in fop.xconf. Once 
> you have configured fop to recognize a font, you can refer to it from the 
> DocBook parameters using the name you have associated with the font in 
> fop.xconf. If you look in your fop.xconf file, you will find that the 
> definition for Times contains several instances of the  
> element, each of which defines a name you can use for that font, along with 
> information about style and weight.
> This page has some information on configuring the fop.xconf file for fonts:
> https://xmlgraphics.apache.org/fop/2.1/fonts.html
> Best regards,
> Dick Hamilton
> ---
> XML Press
> XML for Technical Communicators
> http://xmlpress.net
> hamil...@xmlpress.net
> > On Feb 1, 2017, at 11:53, stim...@comcast.net wrote:
> > 
> > Hi,
> > 
> > I tested this by changing body.font.family to sans-serif. The document did 
> > successfully switch, and used Helvetica. Unfortunately, Helvetica also 
> > lacks the box drawing characters. Is there a configuration file used for a 
> > given Docbook 5.1 installation which maps "Times Roman" to serif, and 
> > "Helvetica" to sans-serif? I think this is the key to getting those box 
> > drawing characters to work...perhaps if I can remap serif and sans-serif to 
> > valid fonts other than Helvetica and Times Roman it would work with those 
> > characters.
> > 
> > Thanks!
> > 
> > - Original Message -
> > From: Bob Stayton <b...@sagehill.net>
> > To: stim...@comcast.net, docbook-apps@lists.oasis-open.org
> > Sent: Wed, 01 Feb 2017 18:51:04 - (UTC)
> > Subject: Re: [docbook-apps] Odd Characters in UTF-8, Docbook 5.1
> > Hi,
> > If by system-wide you mean everyone sharing one DocBook XSL 
> > installation

Re: [docbook-apps] Odd Characters in UTF-8, Docbook 5.1

[Richard Hamilton]

Hi,

There are two steps to the font assignment process: 1) configuring fop’s fonts 
and 2) setting DocBook parameters to call the fonts you have configured in fop.

In this case, the mapping between serif and Times (and sans-serif and 
Helvetica) happens in the fop configuration file, fop.xconf.

So, when you set the DocBook parameter to sans-serif, fop defaults to 
Helvetica. If you want sans-serif to default to something else, or if you want 
to add a font, you need to change the configuration in fop.xconf. Once you have 
configured fop to recognize a font, you can refer to it from the DocBook 
parameters using the name you have associated with the font in fop.xconf. If 
you look in your fop.xconf file, you will find that the definition for Times 
contains several instances of the  element, each of which defines 
a name you can use for that font, along with information about style and weight.

This page has some information on configuring the fop.xconf file for fonts:

https://xmlgraphics.apache.org/fop/2.1/fonts.html

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Feb 1, 2017, at 11:53, stim...@comcast.net wrote:
> 
> Hi,
>  
> I tested this by changing body.font.family to sans-serif. The document did 
> successfully switch, and used Helvetica. Unfortunately, Helvetica also lacks 
> the box drawing characters. Is there a configuration file used for a given 
> Docbook 5.1 installation which maps "Times Roman" to serif, and "Helvetica" 
> to sans-serif? I think this is the key to getting those box drawing 
> characters to work...perhaps if I can remap serif and sans-serif to valid 
> fonts other than Helvetica and Times Roman it would work with those 
> characters.
>  
> Thanks!
>  
> - Original Message -
> From: Bob Stayton 
> To: stim...@comcast.net, docbook-apps@lists.oasis-open.org
> Sent: Wed, 01 Feb 2017 18:51:04 - (UTC)
> Subject: Re: [docbook-apps] Odd Characters in UTF-8, Docbook 5.1
> Hi,
> If by system-wide you mean everyone sharing one DocBook XSL 
> installation, you could edit the parameters file for that installation. 
> Find the file named fo/param.xsl and change these stylesheet parameters:
> serif
> sans-serif
> All of the stylesheet params are documented here:
> http://docbook.sourceforge.net/release/xsl/current/doc/fo/index.html
> 
> Bob Stayton
> Sagehill Enterprises
> b...@sagehill.net
> On 2/1/2017 10:22 AM, stim...@comcast.net wrote:
> > I just wanted to add some information from reading build logs for the
> > document. It turns out the error shows up under "fop" because the
> > particular font does not support this character (I'm surprised
> > Times-Roman does not have this by default since just about every
> > application on the system has the character):
> > WARNING: Glyph "├" (0x251c, SF08) not available in font "Times-Roman".
> >
> > The trouble here is I now want to change this for the system as a whole,
> > not just on the document (I want to avoid any project using
> > Times-Roman). I am curious if there is some simple way under Linux to
> > find out which fonts fop has available, and how to change the default
> > font family for all Docbook publishing via a system-wide setting? I've
> > found many documents on modifying Docbook behavior within source code,
> > but not much seems to exist on system-wide Docbook configuration from a
> > system administrator's point of view...if anyone has a URL for
> > information on specifics of tuning Docbook defaults under Linux I'd be
> > very happy!
> >
> > Thanks!
> >
> > - Original Message -
> > From: stim...@comcast.net
> > To: docbook-apps@lists.oasis-open.org
> > Sent: Tue, 31 Jan 2017 23:20:24 - (UTC)
> > Subject: [docbook-apps] Odd Characters in UTF-8, Docbook 5.1
> > Hi,
> >
> > I'm working on a Linux machine which has UTF-8 encoding. The docbook 5.1
> > I'm working with is declared:
> > 
> >  > 
> > ]>
> >
> > Entities changed a while back (relaxng changed things), but so far as I
> > know I should still be able to work with numeric entities when using odd
> > characters which are part of UTF-8. I'm trying to get some box drawing
> > characters to work, specifically because I need to illustrate a file
> > directory structure which has been output like this from the "tree -d"
> > command. Here's a short sample:
> >> tree -d -L 2 /etc | tail -n 20 | tail -n 6
> > │ ├── pluginconf.d
> > │ ├── protected.d
> > │ └── vars
> > └── yum.repos.d
> >
> > As you can see the vertical and horizontal box drawing characters are
> > used. When I redirect this to a file or copy and paste into the document
> > all I get is a substitute...each shows as "#". So I tried to use numeric
> > entities instead. As an example "boxh" (horizontal box line) should work
> > as "". This does not work, and rendering still ends up as "#". I
> > tried the numeric code for the plus/minus character, "||", and
> > this does work. I don't 

[docbook-apps] DocBook TC meeting agenda for 21 December 2016 (TODAY)

[Richard Hamilton]

Here is the agenda for today’s meeting. I apologize for the delay in getting it 
to you.

Talk with you in an hour.

Best regards,
Dick

DocBook Technical Committee Meeting Agenda: 21 December 2016
=

The DocBook Technical Committee will meet on Wednesday,
21 December 2016 at 2:00pm ET

Agenda

1. Roll call


2. Accept the minutes [1] of the previous meeting (16 November 2016).
 
3. Next meeting: 18 January 2017

4. Review of the agenda.

5. Review of open action items

 a: Jirka: Port changes in publisher's schema back to 5.1 on Github.

 b: Bob will send a note to voting members who have not voted and who have not 
already been contacted by members.
 COMPLETED: vote passed

 c: Bob will announce discontinuation of support for XSD starting with 5.2.

6: Chet Ensign has asked for feedback on the OASIS process for approving 
standards, based on our experience with 5.1

7. XSD support in 6.0

8.  Review of Requests for Enhancement
 Items 72 and 74 are new.

All open RFEs are now on Github.

 To find a Github issue by number, enter the URL (on one line):
  https://github.com/docbook/docbook/issues/NUMBER

  Open Github Issues (All still open for v5.2 or later):
  6 Add buildtarget element
  7 Allow revnumber inline.
  52   Allow multimediaparam in imagedata
  53   Extend article @class with other and otherclass
  54   Add XIncludes to Assembly Schema
  71   license tag (migrated from sourceforge)
  72  The DocBook websites should really be using https
  74   (Re)allow recursive use of optional
  
[1] https://lists.oasis-open.org/archives/docbook-tc/201611/msg00018.html



-
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] [ANN] XSL Coverage scripts

[Richard Hamilton]

Hi Ben,

Thanks for the explanation and for making this utility; it is very cool and 
useful.

Best regards,
Richard
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Nov 11, 2016, at 19:06, ben.guillon <ben.guil...@gmail.com> wrote:
> 
> Hi Richard,
> 
> Yes, it means that: when stylesheets are processed on a given test xml file, 
> the tool traces the templates applied, and within the called templates the 
> XSL instructions performed (some instructions can be unreachable because of 
> conditional processing with xsl:if, xsl:choose). In the HTML coverage report, 
> the covered lines (that is, the XSL lines used to transform the XML) have 
> green background, while unused lines have yellow backgrounds. Clicking on the 
> green lines point to the XML line(s) processed. The overall statistics for 
> the stylesheets used are in a coverage index file.
> 
> An example of such a report is here:
> https://marsgui.github.io/xslcoverage/example/traces/coverage_index.html
> 
> Regards,
> BG
> 
> On Fri, 11 Nov 2016 20:35:37 +0100, Richard Hamilton <hamil...@xmlpress.net> 
> wrote:
> 
>> Hi Ben,
>> 
>> This looks interesting, but I’ve got a basic (dumb:-) question. What do you 
>> mean by coverage?
>> 
>> Do you mean test coverage, that is, calculating how much a given test xml 
>> file exercises the stylesheets, or do you mean something else?
>> 
>> Thanks,
>> Dick Hamilton
>> ---
>> XML Press
>> XML for Technical Communicators
>> http://xmlpress.net
>> hamil...@xmlpress.net
>> 
>>> On Nov 8, 2016, at 15:58, ben.guillon <ben.guil...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> For your information, I've packaged a few python scripts and a java plugin 
>>> for Saxon to compute and visualize the coverage of XSL stylesheets when 
>>> processed on documents with saxon (currently tested with saxon 6.5.5).
>>> 
>>> It's available here:
>>> 
>>> https://github.com/marsgui/xslcoverage/tree/master
>>> 
>>> You can look at the result with an example at the end of the readme.
>>> 
>>> Regards,
>>> BG
>>> 


-
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] [ANN] XSL Coverage scripts

[Richard Hamilton]

Hi Ben,

This looks interesting, but I’ve got a basic (dumb:-) question. What do you 
mean by coverage?

Do you mean test coverage, that is, calculating how much a given test xml file 
exercises the stylesheets, or do you mean something else?

Thanks,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



> On Nov 8, 2016, at 15:58, ben.guillon  wrote:
> 
> Hi,
> 
> For your information, I've packaged a few python scripts and a java plugin 
> for Saxon to compute and visualize the coverage of XSL stylesheets when 
> processed on documents with saxon (currently tested with saxon 6.5.5).
> 
> It's available here:
> 
> https://github.com/marsgui/xslcoverage/tree/master
> 
> You can look at the result with an example at the end of the readme.
> 
> Regards,
> BG
> 
> -
> 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] Decimal align labels in a print TOC

[Richard Hamilton]

By default, the chapter number in a TOC line is left aligned, as shown here:

1. Title of chapter 1 1
2. Title of chapter 2 5
...
100. Title of chapter 100 X

I'm trying to figure out the best way to have the chapter numbers right align, 
so the separator (in this case a period) aligns vertically. That would look 
something like this (simulated in a variable width font):

1.
2.
100.

I've tried applying various attributes to the fo:inline element in the toc.line 
template, but to no avail.

Does anyone have any suggestions on the best way to do this?

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] [OT] DocBook XSL license

[Richard Hamilton]

Hi Jan,

The DocBook TC met today, and after the official meeting concluded, we 
discussed your request. Norm Walsh told us that the current license uses the 
same wording as the MIT license, except that we added provisions concerning 
attribution of code and didn't identify the license as coming from the MIT 
license.

No one on the call is a lawyer, but we didn't see any objections to someone 
distributing customizations that carried another license as long as the 
existing material carries the current license.

We agreed to change the license file to identify the license as the MIT 
license, then separately note the additional restriction concerning the use of 
the names of the copyright holders.

I hope that helps.

FYI, I'm cross posting this to the DocBook Apps group because that's were it 
initiated.

Best regards,
Richard
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Mar 13, 2016, at 15:37, Richard Hamilton <hamil...@xmlpress.net> wrote:

> Hi Jan,
> 
> I'm forwarding this to the DocBook TC. I don't know the answer to your 
> question, but there are people on the TC who probably do know.
> 
> Best regards,
> Richard Hamilton
> ---
> XML Press
> XML for Technical Communicators
> http://xmlpress.net
> hamil...@xmlpress.net
> 
> 
> 
> Begin forwarded message:
> 
>> From: "Jan Tosovsky" <j.tosov...@email.cz>
>> Subject: [docbook-apps] [OT] DocBook XSL license
>> Date: March 12, 2016 at 4:13:49 PST
>> To: "'Docbook apps List'" <docbook-apps@lists.oasis-open.org>
>> 
>> Dear All,
>> 
>> I am implementing stylesheets for DocBook conversion into special format
>> which I'd like to publish on GitHub. I am reusing the code from DocBook XSL
>> distribution - from /common and /lib.
>> 
>> I plan to distribute it under a common license, most likely GPL v3.
>> 
>> I'd like to verify if this license is compatible with that found in DocBook
>> XSL distribution:
>> 
>> http://docbook.sourceforge.net/release/xsl/current/COPYING or alternatively
>> http://docbook.sourceforge.net/release/xsl/current/doc/copyright.html
>> 
>> What do you think?
>> 
>> Btw, do you happen plan changing this license to something more common? :-)
>> 
>> Thanks,
>> 
>> Jan
>> 
>> 
>> -
>> 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] Preserving entities and language translation

[Richard Hamilton]

Hi Warren,

I'm not sure if I can come up with a standard, or truly elegant way of doing 
this, but here are a few possibilities:

1) If the only entities in your files are the ones that shouldn't be 
translated, just don't have xmllint resolve the entities when you normalize the 
file, then use it again to expand entities when you get the translated files 
back. Of course, this option won't work if you have other entities that contain 
content you need to translate.

2) Place the large blocks in files that would be included using xinclude. You 
could then translate the file before resolving the inclusions. Of course, this 
one doesn't work if you have other xincludes that contain content you need to 
translate.

3) Create a simple XSL stylesheet or script (Perl, PHP, ...) that would convert 
the code as you have shown below, leaving everything else as is, then another 
script that converts the translated file back. You could then run xmllint to 
resolve those entities. This is a five-step process:

  - Run the first script to transform the translate on/off processing 
instructions into non-entities.
  - Run xmllint to normalize everything else
  - Translate
  - Run the second script on the translated file to restore the entities inside 
the translate instructions
  - Run xmllint to resolve those entities. 

I hope that helps.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jan 18, 2016, at 20:42, Warren Block  wrote:

> Some of the articles in the FreeBSD documentation use entities to include 
> large blocks of data.  For example, one article is just a very large list of 
> PGP keys for developers: 
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pgpkeys/index.html
> 
> The DocBook article.xml is only 2K, because it does things like this:
> 
>  
>Officers
> 
>
>  
> 
> We use xmllint to normalize the article into a single XML file for use with 
> PO translation tools.  Of course, all entities are expanded into text at that 
> point.
> 
> It would be really nice to mark that particular entity as one that should be 
> preserved in the translated file.  Is it possible to do that with processing 
> instructions or some other method?  For example:
> 
>  
>Officers
> 
>
>
>
>  
> 
> In the normalized file, it could be a string to indicate to translators that 
> it should be left alone:
> 
>  
>Officers
> 
>
>do not translate: section.pgpkeys-officers
>
>  
> 
> Of course, it has to be changed back when the translated XML file is 
> generated.
> 
> Is there a standard or elegant way to do this?
> 
> -
> 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] Indexterms with one or more See elements

[Richard Hamilton]

I think the reference to "at least one  entry" is probably a typo, because 
the grammar only allows one  element in an indexterm.

It should be possible (but maybe not too easy) to get the Chicago Manual style 
with a stylesheet customization that looks for multiple indexterms with the 
same term(s) and  elements. 

That approach doesn't change the grammar, but would give you the visual result 
you want.

However, it's not unreasonable to allow multiple  elements on one 
.

If you think that's important, you can propose an RFE (Request for Enhancement) 
on either SourceForge or (preferably) Github for consideration in the next 
revision of the DocBook standard. If you're not sure how to do that (or don't 
have permissions), let me know, and I'll file one (I think it's worth 
considering).

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jan 8, 2016, at 6:52, Pc Thoms  wrote:

> While working on a legacy project I found the following to be valid:
> 
> EngineersInstitution
> EngineersNorth of England
> 
> This produces an entry that appears as
> 
> Engineers (see Institution) (see North of England)
> 
> and usually the see would italicized in an index. 
> 
> However, the following is does not validate.
> 
> EngineersInstitutionNorth of 
> England
> 
> On the page, http://docbook.org/tdg51/en/html/indexterm.singular.html, there 
> is reference to "if there is at least one see entry for a particular term." 
> This to my mind implies that there may one or more see references.
> 
> When consulting the Chicago Manual, Edition 17, the first example is an entry 
> with see two different entries, as follows:
> 
> adolescence. See teenagers; youth
> 
> Edition 16, however, has only single see entries in its' examples.


-
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] any problems with DocBook XSL 1.79.0?

[Richard Hamilton]

Hi Bob,

Thanks for the information. No need to apologize for the delay; I have a 
workaround, so time was not an issue.

One follow-up, to make sure I understand the situation.

docbook.xsl without the  directive works fine with Saxon. When is 
that directive needed? Is this an incompatibility between Saxon and other 
processors or is something else going on?

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Nov 3, 2015, at 16:10, Bob Stayton <b...@sagehill.net> wrote:

> Hi Dick,
> Sorry for the slow response.  If you look in the xhtml directory, there
> is a special master file named docbook-no-doctype.xsl, which is
> identical to docbook.xsl except it omits that  directive.
> Switching to that solved the problem in some cases.  But no one ever did it 
> for xhtml-1_1 for epub 2 documents.
> 
> Bob Stayton
> Sagehill Enterprises
> b...@sagehill.net
> 
> On 10/21/2015 5:52 PM, Richard Hamilton wrote:
>> Hi Bob,
>> 
>> As a followup, it looks like this is a problem that existed in
>> 1.78.1. Looking back at my files and email, I see that this was
>> discussed in 2013 and was attributed to a quirk in Saxon.
>> 
>> The issue comes up in xhtml-1_1/docbook.xsl which has the following
>> line:
>> 
>> > doctype-public="-//W3C//DTD XHTML 1.1//EN"
>> doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"/>
>> 
>> Once set, saxon will put that DOCTYPE into everything, even if the
>> output has a different namespace.
>> 
>> I resolved this locally by removing the doctype-public and
>> doctype-system attributes from this line in docbook.xsl, maketoc.xsl.
>> and profile-docbook.xsl.
>> 
>> I forget why this couldn't be changed in the distributed stylesheets
>> (maybe a problem with xsltproc or another xslt processor), but if it
>> can be changed, that would be helpful.
>> 
>> Thanks, Dick --- XML Press XML for Technical Communicators
>> http://xmlpress.net hamil...@xmlpress.net
>> 
>> 
>> 
>> On Oct 21, 2015, at 17:15, Richard Hamilton <hamil...@xmlpress.net>
>> wrote:
>> 
>>> Hi Bob,
>>> 
>>> I built one of our books using the fo stylesheets, and it came out
>>> clean. Not an extensive test, but it does build a book with an
>>> index, a glossary, and a fair number of customizations.
>>> 
>>> I built an epub using the epub2 stylesheets and got the following
>>> message from epubcheck (both epubcheck 3.0.1 and 4.0.0):
>>> 
>>> ERROR: xliff.epub/OEBPS/content.opf: Obsolete or irregular DOCTYPE
>>> statement. The DOCTYPE can be removed. WARNING:
>>> xliff.epub/OEBPS/toc.ncx: Irregular DOCTYPE: found '-//W3C//DTD
>>> XHTML 1.1//EN', expecting '>> 2005-1//EN" "http://www.daisy.org/z3986/2005/ncx-2005-1.dtd;>'.
>>> 
>>> I removed all of my customizations, and got the same error with the
>>> standard stylesheets, so I'm pretty sure that the problem is not in
>>> my customizations.
>>> 
>>> The same book run through the epub3 stylesheets does not generate
>>> this error, so it looks like it is specific to epub2.
>>> 
>>> I'll keep using the stylesheets and let you know if I see anything
>>> else.
>>> 
>>> Thanks for everything you do to support the stylesheets.
>>> 
>>> Dick --- XML Press XML for Technical Communicators
>>> http://xmlpress.net hamil...@xmlpress.net
>>> 
>>> 
>>> 
>>> On Oct 21, 2015, at 15:35, Bob Stayton <b...@sagehill.net> wrote:
>>> 
>>>> It has been about a week since candidate DocBook XSL 1.79.0 was
>>>> released, and it has been downloaded about 150 times.  Has anyone
>>>> who has tried it run into any problems yet?  If so, please let me
>>>> know so they can be fixed for the 1.79.1 release.
>>>> 
>>>> -- Bob Stayton Sagehill Enterprises b...@sagehill.net
>>>> 
>>>> -
>>>> 
>>>> 
> 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] any problems with DocBook XSL 1.79.0?

[Richard Hamilton]

Hi Bob,

As a followup, it looks like this is a problem that existed in 1.78.1. Looking 
back at my files and email, I see that this was discussed in 2013 and was 
attributed to a quirk in Saxon.

The issue comes up in xhtml-1_1/docbook.xsl which has the following line:

http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"/>

Once set, saxon will put that DOCTYPE into everything, even if the output has a 
different namespace.

I resolved this locally by removing the doctype-public and doctype-system 
attributes from this line in docbook.xsl, maketoc.xsl. and profile-docbook.xsl.

I forget why this couldn't be changed in the distributed stylesheets (maybe a 
problem with xsltproc or another xslt processor), but if it can be changed, 
that would be helpful.

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Oct 21, 2015, at 17:15, Richard Hamilton <hamil...@xmlpress.net> wrote:

> Hi Bob,
> 
> I built one of our books using the fo stylesheets, and it came out clean. Not 
> an extensive test, but it does build a book with an index, a glossary, and a 
> fair number of customizations.
> 
> I built an epub using the epub2 stylesheets and got the following message 
> from epubcheck (both epubcheck 3.0.1 and 4.0.0):
> 
> ERROR: xliff.epub/OEBPS/content.opf: Obsolete or irregular DOCTYPE statement. 
> The DOCTYPE can be removed.
> WARNING: xliff.epub/OEBPS/toc.ncx: Irregular DOCTYPE: found '-//W3C//DTD 
> XHTML 1.1//EN', expecting ' "http://www.daisy.org/z3986/2005/ncx-2005-1.dtd;>'.
> 
> I removed all of my customizations, and got the same error with the standard 
> stylesheets, so I'm pretty sure that the problem is not in my customizations.
> 
> The same book run through the epub3 stylesheets does not generate this error, 
> so it looks like it is specific to epub2.
> 
> I'll keep using the stylesheets and let you know if I see anything else.
> 
> Thanks for everything you do to support the stylesheets.
> 
> Dick
> ---
> XML Press
> XML for Technical Communicators
> http://xmlpress.net
> hamil...@xmlpress.net
> 
> 
> 
> On Oct 21, 2015, at 15:35, Bob Stayton <b...@sagehill.net> wrote:
> 
>> It has been about a week since candidate DocBook XSL 1.79.0 was released, 
>> and it has been downloaded about 150 times.  Has anyone who has tried it run 
>> into any problems yet?  If so, please let me know so they can be fixed for 
>> the 1.79.1 release.
>> 
>> -- 
>> Bob Stayton
>> Sagehill Enterprises
>> b...@sagehill.net
>> 
>> -
>> 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] any problems with DocBook XSL 1.79.0?

[Richard Hamilton]

Hi Bob,

I built one of our books using the fo stylesheets, and it came out clean. Not 
an extensive test, but it does build a book with an index, a glossary, and a 
fair number of customizations.

I built an epub using the epub2 stylesheets and got the following message from 
epubcheck (both epubcheck 3.0.1 and 4.0.0):

ERROR: xliff.epub/OEBPS/content.opf: Obsolete or irregular DOCTYPE statement. 
The DOCTYPE can be removed.
WARNING: xliff.epub/OEBPS/toc.ncx: Irregular DOCTYPE: found '-//W3C//DTD XHTML 
1.1//EN', expecting 'http://www.daisy.org/z3986/2005/ncx-2005-1.dtd;>'.

I removed all of my customizations, and got the same error with the standard 
stylesheets, so I'm pretty sure that the problem is not in my customizations.

The same book run through the epub3 stylesheets does not generate this error, 
so it looks like it is specific to epub2.

I'll keep using the stylesheets and let you know if I see anything else.

Thanks for everything you do to support the stylesheets.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Oct 21, 2015, at 15:35, Bob Stayton  wrote:

> It has been about a week since candidate DocBook XSL 1.79.0 was released, and 
> it has been downloaded about 150 times.  Has anyone who has tried it run into 
> any problems yet?  If so, please let me know so they can be fixed for the 
> 1.79.1 release.
> 
> -- 
> Bob Stayton
> Sagehill Enterprises
> b...@sagehill.net
> 
> -
> 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] Kindle TOCs

[Richard Hamilton]

Back about 2 years ago, there was a thread concerning a problem with Kindle 
TOCs.

If you use the html  element for toc.list.type (as recommended for Kindle) 
and the CSS style "list-style-type: none" to suppress the numbers, some devices 
work fine, but others, including older Kindle devices and Kindle on iPhone, 
ignore the CSS directive and display numbers that are completely unrelated to 
the actual chapter numbers.

We tolerated this and just didn't show chapter numbers in the TOC. Most of the 
time, that's ok, but it isn't a totally satisfying solution. And when a book is 
used as a textbook, this "solution" becomes a real problem if the instructor 
uses the print chapter numbers in assignments.

In the initial thread, and in some other discussions on the web, solutions have 
been proposed that use either  or  elements instead of .

One of those solutions may turn out to be the best way to proceed, but I 
thought that before I pursue that solution, I'd ask if anyone has come up with 
a way to handle this situation in the DocBook stylesheets that they'd be 
willing to share?

Thanks,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Show off what you've done with Docbook

[Richard Hamilton]

Hi Katie,

My company uses DocBook for most of its publications (we publish books for 
technical communicators, content strategists, and others in the technical 
communication world). We publish in print and ebook form (which is essentially 
HTML). We also publish excerpts in HTML. 

Here is a link to a sample we posted in 2010 that has ePub, Mobi, and PDF: 
http://xmlpress.net/2009/12/20/free-ebook-sample-chapter-managing-writers/

Here is a more recent example in HTML and PDF: 
http://thecontentwrangler.com/2014/12/03/the-role-of-content-inventory-and-audit-in-governance/

The chapter in HTML format is the main part of this page, but there's a link to 
the PDF here: 
https://www.slideshare.net/abelsp/sample-chapter-content-audits-and-inventories

We do use other formats from time to time (e.g., DITA for a series about DITA 
and Author-It for a book about Author-It), but the bulk of our books are in 
DocBook and generated from a single source.

DocBook works well for us, though I would concur with others on this thread 
that there is a learning curve. But if you're going to use XML, I don't think 
you will find the learning curve for any of the major dialects (DITA, DocBook, 
S1000D) to be significantly different from the others, as long as you have good 
tools and good training.

Best regards,
Richard Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Sep 11, 2015, at 9:56, Katie Welles <ka...@inkwelle.com> wrote:

> It’s been a while since I’ve used Docbook or participated in this forum. 
> 
> I used Docbook a number of years ago to put together a web-based API 
> reference system. To be frank, I found it to be a pretty painful project, but 
> mainly because I thought it was downright foolish to jump through all those 
> Docbook hoops just to output simple HTML. It seems to me that the power of 
> Docbook is when your single XML source is used for multiple outputs.
> 
> I support a consortium that manages 12+ open APIs, and we’ve been 
> re-examining the tools we use to output published specs. We know we want 
> **all** our API specs to be available as PDF and also HTML, but are not sure 
> which tool to bank on. So far we’ve been looking at asciidoc, which I find 
> pretty underwhelming.
> 
> Have any of you PDF + HTML output with Docbook? If anyone has such a project 
> and will be willing to show it off, send some URLs!
> 
> As an aside: Have any of you used asciidoc? 
> 
> (BTW — I use MadCap Flare for another of my clients. The output is stunningly 
> beautiful, but the tool is far too unwieldy and expensive for me to be able 
> to recommend it to my API client.)
> -
> 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] should become in another book

[Richard Hamilton]

Hi Benjamin,

Catching up on email and noticed that I hadn't replied earlier.

I am using xpointer, though with xmllint rather than Xerces.

I had to define the namespace in the xpointer call (e.g., http://docbook.org/ns/docbook)xpointer(/d:chapter/d:info/following-sibling::*))"/>)

I don't know if that is needed with Xerces, but it might be worth trying. 

Best regards,
Richard
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Aug 25, 2015, at 7:07, Kallauch, Benjamin (EEIN) 
<benjamin.kallau...@volkswagen.de> wrote:

> Hi Richard,
> 
> I've read your post and it looks like you're using the xpointer() scheme, 
> right? Unfortunately, my tool chain with Xalan and Xerces does not support 
> that scheme as described in the FAQ on the Xerces-Website by Apache. Rather 
> it says Xerces supports the element() scheme. But this seems at least not 
> fully functional: I encounter an XPointer error when using something like: 
> 
> http://www.w3.org/2001/XInclude; href="foo.xml" 
> xpointer="element(foo)"/>
> 
> 
> On the other hand, if I use a childsequence like the following, it works fine.
> 
> http://www.w3.org/2001/XInclude; href="foo.xml" 
> xpointer="element(/1/4)"/>
> 
> At the moment I have no need to include only parts of an xml with xinclude, 
> but in case I had to I would have a problem with my tool chain. Maybe you or 
> someone else have a solution for working with Xalan/Xerces and XPointer. (Or 
> maybe I have to switch to a more sophisticated XSLT processor / XML parser 
> combination some time.)
> 
> best regards
> Benjamin
> 
> -Ursprüngliche Nachricht-
> Von: Richard Hamilton [mailto:hamil...@xmlpress.net] 
> Gesendet: Freitag, 21. August 2015 22:09
> An: DocBook Apps
> Betreff: Re: [docbook-apps]  should become  in another book
> 
> I think that thread should get you headed in the right direction.
> 
> I still use the method I described in a post on that thread. Some might call 
> it inelegant, but it works for me:-). The only thing that I don't know about 
> is how to integrate it into an Ant script. I'm an old fogey who still uses 
> make for most builds (if it's not broken, don't fix it:-).
> 
> Dick Hamilton
> ---
> XML Press
> XML for Technical Communicators
> http://xmlpress.net
> hamil...@xmlpress.net
> 
> 
> 
> On Aug 19, 2015, at 6:31, Frank Arensmeier <farensme...@gmail.com> wrote:
> 
>> Just a quick heads-up. I just stumbled upon an old thread on this list 
>> dealing with more or less the same problem as you have.
>> 
>> http://comments.gmane.org/gmane.text.docbook.apps/29005
>> 
>> Maybe worth reading?
>> /frank 
>> 
>> 
>>> 19 aug 2015 kl. 15:20 skrev Lars Vogel <lars.vo...@gmail.com>:
>>> 
>>> Hi Frank,
>>> 
>>> thanks, xpointers sound very useful.
>>> 
>>> I tried it but my self-written xinclude Apache Ant task does not support 
>>> xpointers. Is anyone aware of an existing Ant xinclude task which has 
>>> support for xpointers?
>>> 
>>> Best regards, Lars
>>> 
>>> 2015-08-19 15:04 GMT+02:00 Frank Arensmeier <farensme...@gmail.com>:
>>> Hi there!
>>> 
>>> There is probably some XLST foo out there that does what you want. I'd like 
>>> to suggest an other approach. Have a look at "Xpointers" for the x:include 
>>> element. The attribute "xpointer" on that element defines an xpath 
>>> expression (kind of) that is used to select only parts of the document you 
>>> want to include.
>>> 
>>> http://www.sagehill.net/docbookxsl/ModularDoc.html#UsingXinclude
>>> 
>>> See e.g. "Selecting part of a file". However, your tool chain must support 
>>> xpointers (not sure if xproc has suport for the full power of xpointers).
>>> 
>>> Hope this helps!
>>> 
>>> Regards
>>> /frank 
>>> 
>>>> 19 aug 2015 kl. 14:21 skrev Lars Vogel <lars.vo...@gmail.com>:
>>>> 
>>>> Hi,
>>>> 
>>>> I use xinclude to include certain documents in different books. In a 
>>>> certain context I want to use it as part in another as appendix.
>>>> 
>>>> I tried to remove the top level node with the following to my 
>>>> customization layer:
>>>> 
>>>> 
>>>>
>>>>
>>>>
>>>> 
>&

Re: [docbook-apps] part should become appendix in another book

[Richard Hamilton]

I think that thread should get you headed in the right direction.

I still use the method I described in a post on that thread. Some might call it 
inelegant, but it works for me:-). The only thing that I don't know about is 
how to integrate it into an Ant script. I'm an old fogey who still uses make 
for most builds (if it's not broken, don't fix it:-).

Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Aug 19, 2015, at 6:31, Frank Arensmeier farensme...@gmail.com wrote:

 Just a quick heads-up. I just stumbled upon an old thread on this list 
 dealing with more or less the same problem as you have.
 
 http://comments.gmane.org/gmane.text.docbook.apps/29005
 
 Maybe worth reading?
 /frank 
 
 
 19 aug 2015 kl. 15:20 skrev Lars Vogel lars.vo...@gmail.com:
 
 Hi Frank,
 
 thanks, xpointers sound very useful.
 
 I tried it but my self-written xinclude Apache Ant task does not support 
 xpointers. Is anyone aware of an existing Ant xinclude task which has 
 support for xpointers?
 
 Best regards, Lars
 
 2015-08-19 15:04 GMT+02:00 Frank Arensmeier farensme...@gmail.com:
 Hi there!
 
 There is probably some XLST foo out there that does what you want. I’d like 
 to suggest an other approach. Have a look at Xpointers for the x:include 
 element. The attribute xpointer on that element defines an xpath 
 expression (kind of) that is used to select only parts of the document you 
 want to include.
 
 http://www.sagehill.net/docbookxsl/ModularDoc.html#UsingXinclude
 
 See e.g. Selecting part of a file. However, your tool chain must support 
 xpointers (not sure if xproc has suport for the full power of xpointers).
 
 Hope this helps!
 
 Regards
 /frank 
  
 19 aug 2015 kl. 14:21 skrev Lars Vogel lars.vo...@gmail.com:
 
 Hi,
 
 I use xinclude to include certain documents in different books. In a 
 certain context I want to use it as part in another as appendix.
 
 I tried to remove the top level node with the following to my customization 
 layer:
 
 !-- Remove all sections marked with wrapper --
 xsl:template match=part[@role='wrapper'] mode=profile
 xsl:apply-templates select=part mode=profile /
 /xsl:template
 
 And include it into the books like this:
 
 part
 titleGerrit code reviews with Eclipse/title
 xi:include xmlns:xi=http://www.w3.org/2001/XInclude; 
 href=820_gerrit.xml /
 /part
 
 or 
 
 appendix
 titleGerrit code reviews with Eclipse/title
 xi:include xmlns:xi=http://www.w3.org/2001/XInclude; 
 href=820_gerrit.xml /
 /appendix
 
 Unfortunately my customization removes not only the top level part element 
 but the whole part.
 
 Is anyone aware of a nice trick to replace part in some books with 
 appendix? 
 
 Best regards, Lars
 
 P.S. What I would like to have is the equivalent of the merge node for 
 defining Android layouts, this node is only their to have a valid XML file, 
 but is removed during the include process.
 
 
 


-
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] Linking to an HTML file

[Richard Hamilton]

Hi Gabriela,

I don't know the specific software you're using (i.e., Python Notebook and 
QtAssistant). However, if the software handles HTML like a browser, the 
xlink:href attribute can contain a variety of things in addition to a web URL. 
For example, you can use a relative path. For example, if the file is in a subf 
wouldolder called myfiles, you could use link 
xlink:href=myfiles/myfile.htmlLink Text/link.

This page shows the syntax for the href attribute in HTML, which is what 
xlink:href will be converted to when you generate html from DocBook:

http://www.w3schools.com/tags/att_a_href.asp

I would suggest trying out various possibilities and see what happens. DocBook 
will pass through pretty much anything in that attribute, so you have a fair 
amount of latitude to experiment.

I hope that helps.
Richard
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 10, 2015, at 9:03, Gabriela Simonka gabri...@inrosoftware.com wrote:

 Thanks Dick,
 
 I think I must add some additional information. The HTML file I want to link 
 to is in another folder on my file system. It is a Python Notebook document 
 that I exported to HTML format. It does not have a URL. It will be included 
 in our distribution package. I just need to know if it is possible to link to 
 it using a relative path. I can't seem to find anything that would help me.
 
 I compile XML to HTML files to then generate QtAssistant Help collection 
 files for our software help system. I was wondering how to refer to the HTML 
 file so that it would open in a browser.
 
 Regards,
 Gabriela
 
 -- 
 Gabriela Simonka
 Technical Writer
 inro-email-logo.gif
 T +1 514-369-2023
 F +1 514-369-2026
 www.inrosoftware.com
 Subscribe to INRO announcements  
 DISCLAIMER: This message, including attachments, may contain confidential 
 information for the sole use of the intended recipient(s). Any unauthorized 
 use, disclosure, viewing, copying, alteration, or distribution of any 
 information in this message is prohibited. If you have received this message 
 in error please notify the sender immediately.


-
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] Page numbering and volumes

[Richard Hamilton]

Hi Gabriela,

I don't think there is a single parameter that controls the starting number.

However, there is a template in the stylesheets called initial.page.number, 
which I think you can customize to do this.

Here is the description of that template in the online version of Bob Stayton's 
book, DocBook XSL: The Complete Guide:

http://www.sagehill.net/docbookxsl/PrintHeaders.html#InitialPageNumber

I hope that helps.
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 8, 2015, at 12:18, Gabriela Simonka gabri...@inrosoftware.com wrote:

 Hello,
 
 I am splitting one of our manuals into two volumes.  How does one continue 
 the page numbering and autolabelling of tables, figures in the second volume? 
  For example, volume 1 goes from page 1 to 650 and I would like volume 2 to 
 go from page 651 to 1140. 
 
 -Gabriela
 -- 
 Gabriela Simonka
 Technical Writer
 Mail Attachment.gif
 T +1 514-369-2023
 F +1 514-369-2026
 www.inrosoftware.com
 Subscribe to INRO announcements  
 DISCLAIMER: This message, including attachments, may contain confidential 
 information for the sole use of the intended recipient(s). Any unauthorized 
 use, disclosure, viewing, copying, alteration, or distribution of any 
 information in this message is prohibited. If you have received this message 
 in error please notify the sender immediately.


-
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] Linking to an HTML file

[Richard Hamilton]

Hi Gabriela,

The following will do the job:

link xlink:href=http://URL-TO-HTML-FILE;text/link

You do need to declare the xlink namespace, which you can do on the root 
element, like this:

article xmlns=http://docbook.org/ns/docbook;
 version=5.0 xml:lang=en
 xmlns:xlink=http://www.w3.org/1999/xlink;

Or, you can put the declaration right in the link element:

link xmlns:xlink=http://www.w3.org/1999/xlink; 
xlink:href=http://URL-TO-HTML-FILE;text/link


Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 8, 2015, at 13:36, Gabriela Simonka gabri...@inrosoftware.com wrote:

 Hello,
 
 I am writing documentation (article) in XML for one of our products, and I 
 would like to link to an HTML file exported from an IPython Notebook document 
 that we are including alongside our documentation. How does one do this?
 
 Thanks in advance,
 Gabriela
 -- 
 Gabriela Simonka
 Technical Writer
 inro-email-logo.gif
 T +1 514-369-2023
 F +1 514-369-2026
 www.inrosoftware.com
 Subscribe to INRO announcements  
 DISCLAIMER: This message, including attachments, may contain confidential 
 information for the sole use of the intended recipient(s). Any unauthorized 
 use, disclosure, viewing, copying, alteration, or distribution of any 
 information in this message is prohibited. If you have received this message 
 in error please notify the sender immediately.


-
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: new solar book produced using Docbook

[Richard Hamilton]

Hi Bob,

Congratulations.

I have a couple of thoughts regarding, mostly, the DocBook portion. However, I 
have to congratulate you on getting a Kirkus review; they aren't the easiest 
folks to get a review from.

Regarding DocBook, where did you run into CSS problems? We have been doing 
epub2 files with a common CSS file that seems to work across the various 
vendors, but I suspect the reason is that we don't push the bleeding edge quite 
as much as you did.

Also, regarding Look Inside, we've run into the same slowness with Amazon, 
though it is good that they include something, even if it is the Kindle. If you 
sent the PDF to the right people, they should get around to posting the pdf 
look inside, but it can take a while, and they probably won't tell you; it will 
just appear one day:-).

Regarding the cover, that is one place where we also don't try and use DocBook 
(though we do spend some time making the inside cover look nice). We use 
InkScape, but InDesign is even better (if you know how to use it; I don't, so I 
skip it). We have also found Acrobat Pro to be essential for creating PDFs that 
make Lightning Source happy.

Best regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 7, 2015, at 14:16, Bob Stayton b...@sagehill.net wrote:

 You know me as the author of DocBook XSL: The Complete Guide.  Now I have 
 written another book on a completely different topic: solar energy.  Since I 
 produced my new book using DocBook, I'm taking this opportunity to tell the 
 DocBook community about it, and I describe how I produced it at the end of 
 this message.  Replies about the DocBook process can go to the whole list if 
 you think it's appropriate.  If you want to reply about the book's content, 
 please reply just to me so we don't burden the mailing list.
 
 
 I'm pleased to announce that my book Power Shift: From Fossil Energy to 
 Dynamic Solar Power has been unleashed from its long development and is now 
 available to the world.  If you have any interest in solar energy, then you 
 should read this book.
 
 powershift-front-cover-lores.jpg
 
 Climate change researchers sometimes paint a bleak picture of our current 
 global-warming crisis, but rarely explain how we got into this predicament in 
 the first place and how we get out of it. Now, for the first time, my new 
 book does just that. Power Shift retells human history through the lens of 
 energy, explains the science behind the crisis--in clear, succinct language 
 that anyone can understand—and provides a detailed blueprint for the future, 
 from governmental, commercial, and individual perspectives. 
 
 Wondering if the book is any good?  Here is what others are saying:
 
 Solar is surging all of a sudden, and if you read this comprehensive
 book you’ll understand why! -- Bill McKibben, author of The End of Nature
 
 An energy book that is a pleasure to read -- Kirkus Reviews
 
 visionary and brilliant -- NASA Researcher Joe Jordan
 
 Exceptionally well written -- Midwest Book Review
 
 lucid, convincing -- Denis Hayes, organizer of the first Earth Day
 
 points the way to a clean energy future -- California Secretary of Natural 
 Resources John Laird
 
 or check out the reader reviews on Amazon
 
 
 After teaching solar energy for many years, I spent over 15 years researching 
 and writing this book, all while living the life in the off-grid solar home 
 we built. This is my lifework.
 
 It has been a long road to publication.  I handed out the first draft in 
 January 2000, and many things have changed since then. Now I get to report on 
 solar energy's success instead of just wishing for it.  I'm self publishing 
 the book, because as an unknown author I could not interest a publishing 
 company, and because they don't offer much in the way of marketing for new 
 authors anyway.  So I started my own publishing company, Sandstone Publishing 
 (www.sandstonepublishing.com), whose catalog contains exactly one book.
 
 Now I get to market my book, an activity for which I am totally unsuited.  My 
 low-budget marketing plan consists of getting good reviews, and word of 
 mouth.  So if you read the book and like it, please write a review on Amazon 
 or Goodreads, and tell your friends and family about it.  Even climate 
 skeptics can get something out of this book.
 
 The book is available in paperback and Kindle at Amazon, in paperback and 
 Nook Book at Barnes  Noble,  in iBooks at the Apple iTunes Store and in Kobo 
 from Kobo Books. And if you can't afford one, convince me and I'll give you 
 an Ebook copy.  8^)
 
 By the way, although you know me as Bob Stayton, I'm publishing the book 
 under my full name Robert Arthur Stayton as a gesture to honor my father 
 Chester Arthur Stayton, Jr. and my grandfather Chester Arthur Stayton, Sr., 
 with whom I share my middle name.
 
 Producing Power Shift with DocBook
 
 I wrote the book in DocBook 5 using XMetal 7.  I started 

Re: [docbook-apps] xi:include publisher

[Richard Hamilton]

Hi Peter,

What error did you get and what software were you using to do the includes?

Best regards,
Richard Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jun 26, 2015, at 11:24, Peter Fleck peterfl...@gmail.com wrote:

 HI,
 
 I moved our common xml files to a webserver and now publisher does not get 
 included.
 
 I'm using the following syntax:
 
 xi:include xmlns:xi=http://www.w3.org/2001/XInclude; 
 href=http:///publisher.xml/
 
 It works great for legalnotice, for colophon etc and it worked when the 
 file was local (though that doesn't mean it was correct).
 Is it because publisher is not a block item? Is there a better way of 
 including the common publisher across documents?
 
 Thanks,
 
 Peter
 
 -
 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] xi:include publisher

[Richard Hamilton]

Hi Peter,

Are you getting this error when you run jing on publisher.xml by itself?

If so, the problem is that publisher is not valid as a root element in 5.1, 
and legalnotice is. Since jing is just looking at that file in isolation, it 
considers the top element in the file to be a root element.

If you resolve the xincludes (you can do that with xmllint --xinclude) to get a 
single, resolved file, that file should validate successfully (assuming 
everything else is ok).

DocBook 5.1 added a lot more elements as valid root elements (though not 
publisher), but even before 5.1, I often xincluded files that had illegal 
root elements. I just avoided checking syntax until after resolving the 
xincludes.

I normally don't use xsltproc, but I did try using it (with the --xinclude 
option) with the example you gave (local files only), and it resolved the 
xincludes without complaint and ran a transform successfully.

If xsltproc is failing, then please post the error message it gives you and the 
command line you used.

Also, if you haven't already, you might want to try doing this with a local 
file and see if that makes a difference.

Hope that helps.
Richard
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jun 26, 2015, at 13:05, Peter Fleck peterfl...@gmail.com wrote:

 Hi Richard,
 
 JIng gives me error: element publisher not allowed here; expected element 
  and a long list.
 
 I was using xsltproc
 
 The start of the publisher.xml file is:
 
 ?xml version='1.0' encoding='UTF-8'?
 publisher xmlns='http://docbook.org/ns/docbook'
  xmlns:svg='http://www.w3.org/2000/svg'
  xmlns:xlink='http://www.w3.org/1999/xlink'
  xmlns:xi='http://www.w3.org/2001/XInclude' version=5.1 xml:lang=en 
 xml:id=publisher
 
 It works fine for legalnotice which gets included in the output, publisher 
 does not.
 
 So I have
 
 ?xml version=1.0 encoding=UTF-8?
 book xmlns=http://docbook.org/ns/docbook; 
 xmlns:svg=http://www.w3.org/2000/svg; 
 xmlns:xlink=http://www.w3.org/1999/xlink; 
 xmlns:xi=http://www.w3.org/2001/XInclude; version=5.1 xml:lang=en 
 xml:id=idname
  info
titleBook Title/title
subtitleSubtitle/subtitle
author
  personname
firstnameBob/firstname
surnameSmith/surname
  /personname
/author
xi:include xmlns:xi=http://www.w3.org/2001/XInclude; 
 href=http://.../publisher.xml;
  xi:fallbackPublisher Missing/xi:fallback
/xi:include
 
 Thanks,
 
 Peter
 
 
 On 26/06/15 20:30, Richard Hamilton wrote:
 Hi Peter,
 
 What error did you get and what software were you using to do the includes?
 
 Best regards,
 Richard Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 On Jun 26, 2015, at 11:24, Peter Fleck peterfl...@gmail.com wrote:
 
 HI,
 
 I moved our common xml files to a webserver and now publisher does not get 
 included.
 
 I'm using the following syntax:
 
 xi:include xmlns:xi=http://www.w3.org/2001/XInclude; 
 href=http:///publisher.xml/
 
 It works great for legalnotice, for colophon etc and it worked when the 
 file was local (though that doesn't mean it was correct).
 Is it because publisher is not a block item? Is there a better way of 
 including the common publisher across documents?
 
 Thanks,
 
 Peter
 
 -
 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] linked on tag element

[Richard Hamilton]

Hi Bob,

Thanks for the information. I will file a report. 

It looks like the fix is pretty straightforward. I'll try it out and if it 
works, I'll include it as a suggestion in the report.

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On May 19, 2015, at 14:14, Bob Stayton b...@sagehill.net wrote:

 Hi Dick,
 This is a bug.  The problem is how the template named inline.monoseq 
 handles its $content param.  When the call does not include a $content param, 
 then it calls the generate.xlink template to handle linking. When the 
 inline.monoseq call does include $content (as in your second case), then 
 generate.xlink is not called, so no link.
 
 The inline.monoseq template needs to be refactored to accept a $content param 
 and *then* call generate.xlink to handle the linking.  The same applies to 
 the other inline.seq templates.  If you could file a bug report, then this 
 issue will get tracked and fixed.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 On 5/19/2015 12:23 PM, Richard Hamilton wrote:
 I'm running into something curious with the stylesheets.
 
 Consider these two snippets:
 
 tag class=attribute linkend=gloss.hrefhref/tag
 
 tag class=starttag linkend=gloss.htmlhtml/tag
 
 If I generate PDF that contains these two cases, the first tag will link 
 correctly (it is hot and points to the right place), but the second doesn't 
 (there is no link at all). I'm using a recent snapshot, tested with no 
 customizations, and confirmed that both ids exist.
 
 Looking at the XSL, here are the two cases in the stylesheets (inline.xsl):
 
 xsl:when test=$class='attribute'
   xsl:call-template name=inline.monoseq/
 /xsl:when
 
 ...
 
 xsl:when test=$class='starttag'
   xsl:call-template name=inline.monoseq
 xsl:with-param name=content
   xsl:textlt;/xsl:text
   xsl:apply-templates/
   xsl:textgt;/xsl:text
 /xsl:with-param
   /xsl:call-template
 /xsl:when
 ===
 I tried a couple of other classes (pi and element), and it appears that when 
 the case just calls inline.monoseq, everything is fine, but when the case 
 calls apply-templates inside inline.monoseq, things go wrong. But it's not 
 clear to me why that should be a problem.
 
 Does anyone have any idea what the problem is?
 
 Thanks,
 Dick
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 
 -
 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] linked on tag element

[Richard Hamilton]

I'm running into something curious with the stylesheets.

Consider these two snippets:

tag class=attribute linkend=gloss.hrefhref/tag

tag class=starttag linkend=gloss.htmlhtml/tag

If I generate PDF that contains these two cases, the first tag will link 
correctly (it is hot and points to the right place), but the second doesn't 
(there is no link at all). I'm using a recent snapshot, tested with no 
customizations, and confirmed that both ids exist.

Looking at the XSL, here are the two cases in the stylesheets (inline.xsl):

xsl:when test=$class='attribute'
  xsl:call-template name=inline.monoseq/
/xsl:when

...

xsl:when test=$class='starttag'
  xsl:call-template name=inline.monoseq
xsl:with-param name=content
  xsl:textlt;/xsl:text
  xsl:apply-templates/
  xsl:textgt;/xsl:text
/xsl:with-param
  /xsl:call-template
/xsl:when
===
I tried a couple of other classes (pi and element), and it appears that when 
the case just calls inline.monoseq, everything is fine, but when the case calls 
apply-templates inside inline.monoseq, things go wrong. But it's not clear to 
me why that should be a problem.

Does anyone have any idea what the problem is?

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Edge case with dbfo-need

[Richard Hamilton]

Hi Bob,

Thanks very much. I'll download the latest snapshot and give it a try.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 2, 2015, at 11:44, Bob Stayton b...@sagehill.net wrote:

 Hi Dick,
 This was actually an oversight when the dbfo-need template was written.  That 
 feature is a bit of a kludge to begin with, because there is no property in 
 XSL-FO that performs that function. The PI does it by creating a 
 block-container of the specified height, then backspacing up to the top of 
 that container with a negative space-before value to output the content that 
 follows.  If the container does not fit, it forces a page break, otherwise 
 the content should just overwrite the container.
 
 But getting the spacing right is tricky, and the template has to resort to 
 testing to see what the following element is and then tries to recreate that 
 space.  It did not have a case for admonitions, hence the lack of space for 
 the warning element.
 
 I just updated the pi.xsl stylesheet module, checked it into SVN, and tested 
 the latest snapshot.  So that admonition problem should be fixed.
 
 I also got dbfo-need working properly with FOP 1.1.  A previous message 
 mentioned that your example worked with FOP 1.1, but that was just a lucky 
 happenstance that only worked with the fop1.extensions param was not set.  
 Now that feature works with FOP 1.1 with that param set to 1 as it should be.
 
 The updated template is in the snapshot in fo/pi.xsl.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 On 4/1/2015 12:47 PM, Richard Hamilton wrote:
 I just ran into an interesting edge case when building with dbfo-need when 
 the following conditions are true:
 
 1) You have a dbfo-need processing instruction above an admonition (warning, 
 tip, etc.)
 2) The admonition is the last element in a section (technically, the last 
 block element; an indexterm doesn't change anything).
 3) The dbfo-need is not activated (that is, the admonition is small enough 
 to fit on the current page).
 
 When these three things are true, the vertical space between the preceding 
 paragraph and the admonition will be smaller if there is a dbfo-need than if 
 the processing instruction is not present.
 
 I was running the 1.78.1 stylesheets (as well as a more recent snapshot) 
 with no customization, Saxon, and XEP. I don't have a version of FOP active, 
 so I don't know if this is a problem with XEP, the stylesheets, or something 
 else.
 
 I've included a short example that illustrates the problem.
 
 Does anyone have any idea what might be going on here?
 
 Best regards,
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
  Sample docbook =
 
 ?xml version=1.0 encoding=utf-8?
 article xmlns=http://docbook.org/ns/docbook; version=5.0
   titledbfo-need and admonition example/title
   section xml:id=s.shorthistory
 titleFirst section/title
 paraThis first admonition has a dbfo-need processing instruction in 
 front of it./para
 ?dbfo-need height=1in?
 warning
   paraThis one has a dbfo-need in front of it./para
 /warning
   /section
   section
 titleSecond section/title
 paraThis admonition does not have a dbfo-need processing instruction 
 in front of it./para
 warning
   paraThis one has no dbfo-need in front of it./para
 /warning
   /section
 /article
 
 
 
 
 
 
 -
 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] Edge case with dbfo-need

[Richard Hamilton]

Hi Benjamin,

Thanks for checking this out. Looks like it might be an XEP problem. I'll have 
to get the latest FOP and give it a try.

Best regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 2, 2015, at 0:07, Kallauch, Benjamin (EEIN) 
benjamin.kallau...@volkswagen.de wrote:

 I ran your example xml with my combination of Xalan-J-2.7.1 and FOP 1.1. No 
 problems there. The vertical space between the first para and admonition and 
 the second respectively ist absolutely the same. The processing instruction 
 was definitely recognized by the system, I changed the height value to 8 in 
 to force a page break. This was also successful. No errors or other warnings 
 in my log furthermore.
 
 regards,
 Benjamin
 
 
 -Ursprüngliche Nachricht-
 Von: Richard Hamilton [mailto:hamil...@xmlpress.net] 
 Gesendet: Mittwoch, 1. April 2015 21:47
 An: DocBook Apps Mailing List
 Betreff: [docbook-apps] Edge case with dbfo-need
 
 I just ran into an interesting edge case when building with dbfo-need when 
 the following conditions are true:
 
 1) You have a dbfo-need processing instruction above an admonition (warning, 
 tip, etc.)
 2) The admonition is the last element in a section (technically, the last 
 block element; an indexterm doesn't change anything).
 3) The dbfo-need is not activated (that is, the admonition is small enough to 
 fit on the current page).
 
 When these three things are true, the vertical space between the preceding 
 paragraph and the admonition will be smaller if there is a dbfo-need than if 
 the processing instruction is not present.
 
 I was running the 1.78.1 stylesheets (as well as a more recent snapshot) with 
 no customization, Saxon, and XEP. I don't have a version of FOP active, so I 
 don't know if this is a problem with XEP, the stylesheets, or something else.
 
 I've included a short example that illustrates the problem.
 
 Does anyone have any idea what might be going on here?
 
 Best regards,
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
  Sample docbook =
 
 ?xml version=1.0 encoding=utf-8?
 article xmlns=http://docbook.org/ns/docbook; version=5.0
  titledbfo-need and admonition example/title
  section xml:id=s.shorthistory
titleFirst section/title
paraThis first admonition has a dbfo-need processing instruction in 
 front of it./para
?dbfo-need height=1in?
warning
  paraThis one has a dbfo-need in front of it./para
/warning
  /section
  section
titleSecond section/title
paraThis admonition does not have a dbfo-need processing instruction in 
 front of it./para
warning
  paraThis one has no dbfo-need in front of it./para
/warning
  /section
 /article
 
 
 
 
 
 
 -
 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] FO File from DocBook5

[Richard Hamilton]

Hi Sascha,

You should be able to use xsltproc for either DB4 or DB5. In fact, the 
stylesheets are the same for both DB5 and DB4. They handle either version.

You can also use Saxon (that's what I use, but I don't know of any reason why 
xsltproc won't work just fine, too).

Hope that helps.
Richard Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Mar 31, 2015, at 3:10, Sascha Manns sascha.ma...@xcom.de wrote:

 Hi Benjamin,
 
 i meant that i want to produce a fo file from DocBook5. In DB4 i can use 
 xsltproc but i don't know if it is the right tool for DB5.
 -- 
 Yours sincerly
 Sascha Manns
 -
 XCOM AG
 Qualitätsmanagement Banksystem Backend
 Rechnungswesen, Meldewesen, Steuern
 Rennweg 60
 Haus 2
 56626 Andernach
 
 Telefon  +49 2632 9899-158
 Telefax  +49 2632 9899-010
 
 sascha.ma...@xcom.de
 http://www.xcom.de
 
 
 *** XCOM AG Legal Disclaimer ***
 
 Diese E-Mail einschliesslich ihrer Anhaenge ist vertraulich und ist allein 
 für den Gebrauch durch den vorgesehenen Empfaenger bestimmt. Dritten ist das 
 Lesen, Verteilen oder Weiterleiten dieser E-Mail untersagt. Wir bitten, eine 
 fehlgeleitete E-Mail unverzueglich vollstaendig zu loeschen und uns eine 
 Nachricht zukommen zu lassen.
 
 This email may contain material that is confidential and for the sole use of 
 the intended recipient. Any review, distribution by others or forwarding 
 without express permission is strictly prohibited. If you are not the 
 intended recipient, please contact the sender and delete all copies.
 
 Hauptsitz: Allee 8, D-47877 Willich, USt-IdNr.: DE 812 885 664
 Kommunikation: Telefon +49 2154 9209-70, Telefax +49 2154 9209-900, 
 www.xcom.de
 
 Handelsregister: Amtsgericht Krefeld, HRB 10340
 Vorstand: Dirk Franzmeyer, Marco Marty, Dirk Werner, Sascha Bochartz
 Vorsitzender des Aufsichtsrates: Stefan H. Tarach
 
  Original-Nachricht 
 Betreff: Re: [docbook-apps] FO File from DocBook5
 Von: Kallauch, Benjamin (EEIN) benjamin.kallau...@volkswagen.de
 An: Sascha Manns sascha.ma...@xcom.de
 Datum: 31.03.2015 12:08
 Hi Sascha, is your question more about creating FO or about how to handle 
 DocBook 5 (instead of DocBook 4.x)?
  
 regards, Ben.
  
 Von: Sascha Manns [mailto:sascha.ma...@xcom.de] 
 Gesendet: Dienstag, 31. März 2015 11:26
 An: docbook-apps@lists.oasis-open.org
 Betreff: [docbook-apps] FO File from DocBook5
  
 Hello list,
 
 just a question. What is the best way to produce a *.fo file from a DocBook5 
 source?
 
 Greetings
 Sascha
 
 -- 
 Yours sincerly
 Sascha Manns
 -
 XCOM AG
 Qualitätsmanagement Banksystem Backend
 Rechnungswesen, Meldewesen, Steuern
 Rennweg 60
 Haus 2
 56626 Andernach
  
 Telefon  +49 2632 9899-158
 Telefax  +49 2632 9899-010
 sascha.ma...@xcom.de
 http://www.xcom.de
  
 *** XCOM AG Legal Disclaimer ***
  
 Diese E-Mail einschliesslich ihrer Anhaenge ist vertraulich und ist allein 
 für den Gebrauch durch den vorgesehenen Empfaenger bestimmt. Dritten ist das 
 Lesen, Verteilen oder Weiterleiten dieser E-Mail untersagt. Wir bitten, eine 
 fehlgeleitete E-Mail unverzueglich vollstaendig zu loeschen und uns eine 
 Nachricht zukommen zu lassen.
  
 This email may contain material that is confidential and for the sole use of 
 the intended recipient. Any review, distribution by others or forwarding 
 without express permission is strictly prohibited. If you are not the 
 intended recipient, please contact the sender and delete all copies.
  
 Hauptsitz: Allee 8, D-47877 Willich, USt-IdNr.: DE 812 885 664
 Kommunikation: Telefon +49 2154 9209-70, Telefax +49 2154 9209-900, 
 www.xcom.de
 Handelsregister: Amtsgericht Krefeld, HRB 10340
 Vorstand: Dirk Franzmeyer, Marco Marty, Dirk Werner, Sascha Bochartz
 Vorsitzender des Aufsichtsrates: Stefan H. Tarach
 
 


-
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] Edge case with dbfo-need

[Richard Hamilton]

I just ran into an interesting edge case when building with dbfo-need when the 
following conditions are true:

1) You have a dbfo-need processing instruction above an admonition (warning, 
tip, etc.)
2) The admonition is the last element in a section (technically, the last block 
element; an indexterm doesn't change anything).
3) The dbfo-need is not activated (that is, the admonition is small enough to 
fit on the current page).

When these three things are true, the vertical space between the preceding 
paragraph and the admonition will be smaller if there is a dbfo-need than if 
the processing instruction is not present.

I was running the 1.78.1 stylesheets (as well as a more recent snapshot) with 
no customization, Saxon, and XEP. I don't have a version of FOP active, so I 
don't know if this is a problem with XEP, the stylesheets, or something else.

I've included a short example that illustrates the problem.

Does anyone have any idea what might be going on here?

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net

 Sample docbook =

?xml version=1.0 encoding=utf-8?
article xmlns=http://docbook.org/ns/docbook; version=5.0
  titledbfo-need and admonition example/title
  section xml:id=s.shorthistory
titleFirst section/title
paraThis first admonition has a dbfo-need processing instruction in front 
of it./para
?dbfo-need height=1in?
warning
  paraThis one has a dbfo-need in front of it./para
/warning
  /section
  section
titleSecond section/title
paraThis admonition does not have a dbfo-need processing instruction in 
front of it./para
warning
  paraThis one has no dbfo-need in front of it./para
/warning
  /section
/article






-
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] A docbook-xsl parameter bridgehead.renderas

[Richard Hamilton]

Hi Erik,

I don't see anything wrong with the idea, though I'm not sure it would be 
widely used (bridgeheads themselves don't seem to be widely used, though they 
can be really helpful).

You can enter Feature Requests at 
http://sourceforge.net/p/docbook/feature-requests/. You probably need a 
sourceforge login, but that's easy and free.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Mar 13, 2015, at 10:58, Erik Leunissen e...@xs4all.nl wrote:

 L.S.
 
 As it happens, I find myself repeatedly in the situation where I want to use 
 bridgeheads.
 
 In all of these cases I want all bridgeheads throughout the document to be 
 rendered in the same way; as a section at a specific level (e.g. sect5). [*]
 
 The facility to customize this is the renderas attribute to the bridgehead 
 element.
 
 In my use case, it strikes me as inapt to have to adjust that attribute in 
 ever the same way for each instance of a bridgehead in the document. It seems 
 logical/practical to have a docbook-xsl parameter (e.g. 
 bridgehead.renderas) which handles this at at the document level.
 
 The docbook-xsl stylesheets do not currently provide such a facility. Well, I 
 guess that amounts to a Feature Request ...
 
 Anything wrong with this idea?
 
 Greetings,
 
 Erik Leunissen.
 
 
 [*] I'm producing PDF output using docbook-xsl - xsltproc - fop
 
 -
 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] Arabic-Indic numbering in XSL FO output for orderedlist

[Richard Hamilton]

Hi Amin,

You can do this, but you'll need to customize the stylesheets. The critical 
piece of code is the template that matches d:orderedlist/d:listitem in 
mode=item-number in the file common/common.xsl (not in the fo directory of 
the stylesheets).

This template uses the xsl:number function from XSL. While xsl:number uses (to 
some degree) the current language, it only seems to use it in conjunction with 
another attribute (format). The DocBook stylesheets only set the format to one 
of a restricted set (arabic, loweralpha, upperalpha, lowerroman, and 
upperroman), and does not provide a means to insert a custom value of format. 
Thus, regardless of which language you set, you will still get arabic (1-9) 
numerals for the first level of an orderedlist.

However, xsl:number will let you do what you want to do, but you'll need to 
customize the stylesheets:

The easiest way to do this (which is, without a doubt a real hack), is to 
customize this template and change the value 1. in the line that tests for 
$numeration='arabic' to #x661; as shown below:
  
xsl:template match=d:orderedlist/d:listitem mode=item-number
  ...
  xsl:variable name=type
xsl:choose
  xsl:when test=$numeration='arabic'#x661;/xsl:when !-- this is the 
line --
  xsl:when test=$numeration='loweralpha'a./xsl:when
  xsl:when test=$numeration='lowerroman'i./xsl:when
  xsl:when test=$numeration='upperalpha'A./xsl:when
  xsl:when test=$numeration='upperroman'I./xsl:when
  !-- What!? This should never happen --
  
  /xsl:variable
...
/xsl:template

This is a hack, but it will do the job (until you change your xml:lang or nest 
a list:-). You could also add some logic to only select this value when the 
locale is ar or when you use some parameter, which would be a bit better.

A much better, but much more complex, solution would be to use gentext to 
select the values associated with arabic, loweralpha, etc., based on locale. 
The DocBook Definitive Guide for DocBook 5 actually does suggest that the 
values could be based on locale, though it does not mandate that option.

I'm going to file an RFE on the stylesheets suggesting that the maintainers 
consider such an addition. It's not clear to me that this is the best thing to 
do in the general case, because it would change the current behavior for a lot 
of locales. But, I think it's worth having the discussion.

I hope this helps.
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Feb 14, 2015, at 20:27, Amin Abbaspour a.abbasp...@gmail.com wrote:

 hi everyone,
 
 how can I use arabic-indic numbering for orderedlist items in FO output of 
 docbook-xsl. 
 
 I can get it working with epub/html using CSS but not much success with FO. 
 
 for the record, setting chapter.autolabel parameter to '#x661;' makes 
 Arabic/Persian numbers working in chapters but that’s separate than 
 orderedlist items.
 
 many thanks for the help,
 Amin
 


-
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] Generating a page list for epub

[Richard Hamilton]

Has anyone on the list tackled the challenge of generating a page list for ePub 
output?

A page list is a mapping of print page numbers to locations in the ePub.

I don't see any easy way to do it; I suspect it would take some kind of parsing 
of a PDF version of the book, and post-processing of the ePub based on that 
parsing.

But, before I decide whether it's worth even trying, I thought I'd ask the 
group whether anyone has thought about approaches to the problem.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Generating a page list for epub

[Richard Hamilton]

Hi Peter,

It definitely depends on the size of pages in the PDF, since the idea is to 
match locations in an ePub with pages in the printed version of a book. But it 
doesn't depend on the size of the device rendering the ePub.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Feb 10, 2015, at 13:51, Peter Eisentraut pete...@gmx.net wrote:

 On 2/10/15 1:36 PM, Richard Hamilton wrote:
 Has anyone on the list tackled the challenge of generating a page list for 
 ePub output?
 
 A page list is a mapping of print page numbers to locations in the ePub.
 
 Doesn't the page count depend on the size of the rendering device?
 


-
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] Generating a page list for epub

[Richard Hamilton]

Hi Bob,

Thanks, I'll check that out. I figured I'd need to go directly into the PDF, 
but this sounds like it will be easier to work with (I much prefer parsing XML 
to parsing PDF:-).

If I come up with anything useful (which is an if, and a possibly long-term 
if:-), I'll post the results on the list.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Feb 10, 2015, at 14:15, Bob Stayton b...@sagehill.net wrote:

 Hi Dick,
 I have not actually done it, but I think you should look at using the 
 intermediate file format that most XSL-FO processors can output. For example, 
 FOP has:
 
 https://xmlgraphics.apache.org/fop/1.1/intermediate.html
 
 That format is an XML rendering of the area tree as pages.  It contains page 
 numbers and ids, so I think you could use it to post process the epub by 
 matching up ids and inserting page numbers.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 On 2/10/2015 10:36 AM, Richard Hamilton wrote:
 Has anyone on the list tackled the challenge of generating a page list for 
 ePub output?
 
 A page list is a mapping of print page numbers to locations in the ePub.
 
 I don't see any easy way to do it; I suspect it would take some kind of 
 parsing of a PDF version of the book, and post-processing of the ePub based 
 on that parsing.
 
 But, before I decide whether it's worth even trying, I thought I'd ask the 
 group whether anyone has thought about approaches to the problem.
 
 Best regards,
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 
 -
 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] Google Summer of Code 2015 -- Last call for participants

[Richard Hamilton]

So far, I've only received one message expressing interest in having the 
DocBook project apply to participate in the Google Summer of Code this year.

The applications open today (Feb 9) and close in 10 days (Feb 20), so unless I 
hear from a few more people, I don't think it will make sense to apply this 
time around.

I've enclosed my original message for your reference. If you're interested, 
now's your last chance to raise your hand.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net

===
As many of you know, the DocBook project (as distinct from the DocBook TC, 
though many people participate in both activities) applied to the program 
several times and was accepted twice. The program has brought us some useful 
software and, even more important, new contributors to the DocBook community.

To participate this year, we need two things:

1) Mentors: we need at least 5 or 6 people who are willing to participate as 
mentors.
2) Ideas: we need ideas for projects that students can work on.

I'm willing to be the organization administrator again this year, but I'm glad 
to hand over responsibility if someone else wants the job this year.

For the full schedule and more information about the program, go to:
https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page

February 20 is the deadline for applications. To participate, we need to have 
mentors lined up by February 9, which is the opening date for filing 
applications.

If you're interested in participating, you can reply to this message on the 
list or send me email directly at the address below.

Best regards,
Dick Hamilton


-
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] Indexterm in glossterm causes validationexception when using glossseealso

[Richard Hamilton]

Hi Bob,

Thanks for confirming this is a problem. I'll file the bug report. You should 
see it in an hour or so.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Feb 2, 2015, at 9:48, Bob Stayton b...@sagehill.net wrote:

 Yes, this is a bug.  A glossseealso is handled as a cross reference, and the 
 targets of any cross reference should be processed in mode=no.anchor.mode.  
 That mode prevents the inclusion in the link text of nested links and 
 indexterms.   Since that mode is not currently used for glossseealso, the 
 link text includes a duplicate marker for the indexterm included in the 
 glossterm.  The fix is easy, but could someone please file a bug report on 
 Sourceforge so this can be tracked.  Thanks.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 On 1/30/2015 3:48 PM, Richard Hamilton wrote:
 You're correct that this is valid DocBook, and I can confirm that you do get 
 a duplicate id, which means it looks like there's a bug in the stylesheets.
 
 BTW, I see the same thing using the XEP extensions, though RenderX actually 
 doesn't detect the error (or at least doesn't report it) and (almost) 
 correctly processes the .fo, even with the duplicate id. I say almost 
 because a printed PDF will be correct, but an online PDF may link the index 
 entry to the wrong instance of the id.
 
 In the short term, I'd suggest moving the indexterm out of the glossterm. 
 It's still valid, and should give you a good index.
 
 I'm going to post this to the docbook-apps list so the folks who maintain 
 the stylesheets can look at this more closely. I got lost in the depths of 
 some pretty complex code, and (frankly:) ran out of time. If no one else 
 looks at it, I'll come back and dig in deeper in a few weeks.
 
 Best regards,
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 On Jan 30, 2015, at 1:31, M F dark.ride...@yahoo.de wrote:
 
 Hi!
 I am using xsltproc (libxml 20902, libxslt 10128) and I have the following 
 glossary for testing purposes. Note the glossterm-tags have 
 indexterm-tags each and there is also one glossseealso-tag.
 
 ?xml version=1.0 encoding=iso-8859-1?
 !DOCTYPE glossary PUBLIC -//OASIS//DTD DocBook XML V4.5//EN
 http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
 
 glossary id=glossar
 titleGlossar/title
 
 !-- ... E ... --
 glossdiv id=gloss_E
 titleE/title
 glossentry id=gloss_e-file
 glossterm id=glossterm_e-file
 indexterm
 primaryE-File/primary
 /indexterm
 emphasis role=boldE-File/emphasis
 /glossterm
 glossdef
 para
 Glossary_Text
 /para
 glossseealso otherterm=gloss_testEinTest/glossseealso
 /glossdef
 /glossentry
 
 
 glossentry id=gloss_test
 glossterm id=gt_gloss_test
 indexterm
 primaryEinTest/primary
 /indexterm
 emphasis role=boldEinTest/emphasis
 /glossterm
 glossdef
 para
 Glossary_Text
 /para
 /glossdef
 /glossentry
 
 /glossdiv
 /glossary
 
 When I try to generate a pdf file using apache fop (version 1.1), I will 
 get a ValidationException:
 org.apache.fop.fo.ValidationException: Property ID idp8750595088 (found 
 on fo:wrapper) previously used; ID values must be unique within a 
 document!
 
 It is because of the glossseealso-tag. When resolved, a 
 fo:wrapper-element is created with the same ID as the gloss_test.
 
 Now, if I move the indexterm-tag out of the glossterm-tag, it works 
 just fine.
 I wonder if this is a bug or just a wrong use of the indexterm-tag. 
 According to the DTD the indexterm-tag is an allowed child of glossterm.
 
 Thanks in advance!
 
 
 Best regards,
 Dark.Rider85
 
 
 
 -
 To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org
 For additional commands, e-mail: docbook-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] Indexterm in glossterm causes validationexception when using glossseealso

[Richard Hamilton]

You're correct that this is valid DocBook, and I can confirm that you do get a 
duplicate id, which means it looks like there's a bug in the stylesheets.

BTW, I see the same thing using the XEP extensions, though RenderX actually 
doesn't detect the error (or at least doesn't report it) and (almost) correctly 
processes the .fo, even with the duplicate id. I say almost because a printed 
PDF will be correct, but an online PDF may link the index entry to the wrong 
instance of the id.

In the short term, I'd suggest moving the indexterm out of the glossterm. It's 
still valid, and should give you a good index.

I'm going to post this to the docbook-apps list so the folks who maintain the 
stylesheets can look at this more closely. I got lost in the depths of some 
pretty complex code, and (frankly:) ran out of time. If no one else looks at 
it, I'll come back and dig in deeper in a few weeks.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jan 30, 2015, at 1:31, M F dark.ride...@yahoo.de wrote:

 Hi!
 I am using xsltproc (libxml 20902, libxslt 10128) and I have the following 
 glossary for testing purposes. Note the glossterm-tags have 
 indexterm-tags each and there is also one glossseealso-tag. 
 
 ?xml version=1.0 encoding=iso-8859-1?
 !DOCTYPE glossary PUBLIC -//OASIS//DTD DocBook XML V4.5//EN
 http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
 
 glossary id=glossar
 titleGlossar/title
 
 !-- ... E ... --
 glossdiv id=gloss_E
 titleE/title
 glossentry id=gloss_e-file
 glossterm id=glossterm_e-file
 indexterm
 primaryE-File/primary
 /indexterm
 emphasis role=boldE-File/emphasis
 /glossterm
 glossdef
 para
 Glossary_Text
 /para
 glossseealso otherterm=gloss_testEinTest/glossseealso
 /glossdef
 /glossentry
 
   
 glossentry id=gloss_test
 glossterm id=gt_gloss_test
 indexterm
 primaryEinTest/primary
 /indexterm
 emphasis role=boldEinTest/emphasis
 /glossterm
 glossdef
 para
 Glossary_Text
 /para
 /glossdef
 /glossentry
 
 /glossdiv
 /glossary
 
 When I try to generate a pdf file using apache fop (version 1.1), I will get 
 a ValidationException:
 org.apache.fop.fo.ValidationException: Property ID idp8750595088 (found on 
 fo:wrapper) previously used; ID values must be unique within a document!
 
 It is because of the glossseealso-tag. When resolved, a fo:wrapper-element 
 is created with the same ID as the gloss_test. 
 
 Now, if I move the indexterm-tag out of the glossterm-tag, it works just 
 fine. 
 I wonder if this is a bug or just a wrong use of the indexterm-tag. 
 According to the DTD the indexterm-tag is an allowed child of glossterm.
 
 Thanks in advance!
 
 
 Best regards,
 Dark.Rider85
 


-
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] Google Summer of Code 2015

[Richard Hamilton]

Hi Stefan,

Thanks for volunteering.

Regarding the website, in about a week, if I get a few more interested people 
saying they can participate, I'll update http://docbook.xmlpress.net for 2015.

Anyone is welcome to look at that site now. It has all of the information from 
our 2013 application, so you can browse around and get a sense of what GSOC is 
all about.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jan 21, 2015, at 16:50, Stefan Seefeld ste...@seefeld.name wrote:

 On 21/01/15 07:44 PM, Richard Hamilton wrote:
 At today's DocBook TC meeting, we discussed the possibility of applying to 
 be a mentoring organization for this year's Google Summer of Code.
 
 As many of you know, the DocBook project (as distinct from the DocBook TC, 
 though many people participate in both activities) applied to the program 
 several times and was accepted twice. The program has brought us some useful 
 software and, even more important, new contributors to the DocBook community.
 
 To participate this year, we need two things:
 
 1) Mentors: we need at least 5 or 6 people who are willing to participate as 
 mentors.
 2) Ideas: we need ideas for projects that students can work on.
 
 I'm willing to be the organization administrator again this year, but I'm 
 glad to hand over responsibility if someone else wants the job this year.
 
 For the full schedule and more information about the program, go to:
 https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page
 
 February 20 is the deadline for applications. To participate, we need to 
 have mentors lined up by February 9, which is the opening date for filing 
 applications.
 
 If you're interested in participating, you can reply to this message on the 
 list or send me email directly at the address below.
 
 I'd be happy to mentor, if I have the required knowledge depending on
 the topic. (I'll think of ideas for the ideas page. Do we have a place
 where to put those for this year ?)
 
Stefan
 
 
 -- 
 
  ...ich hab' noch einen Koffer in Berlin...


-
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] Google Summer of Code 2015

[Richard Hamilton]

At today's DocBook TC meeting, we discussed the possibility of applying to be a 
mentoring organization for this year's Google Summer of Code.

As many of you know, the DocBook project (as distinct from the DocBook TC, 
though many people participate in both activities) applied to the program 
several times and was accepted twice. The program has brought us some useful 
software and, even more important, new contributors to the DocBook community.

To participate this year, we need two things:

1) Mentors: we need at least 5 or 6 people who are willing to participate as 
mentors.
2) Ideas: we need ideas for projects that students can work on.

I'm willing to be the organization administrator again this year, but I'm glad 
to hand over responsibility if someone else wants the job this year.

For the full schedule and more information about the program, go to:
https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page

February 20 is the deadline for applications. To participate, we need to have 
mentors lined up by February 9, which is the opening date for filing 
applications.

If you're interested in participating, you can reply to this message on the 
list or send me email directly at the address below.

Best regards,
Dick Hamilton

P.S. Sorry for the cross posting, but I wanted to make sure this gets out to 
the widest audience.
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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 and named entities

[Richard Hamilton]

Hi Jirka,

I got some clarification from the vendor, and you are correct that not all 
named character entities will be considered incorrect.

In particular, it looks like the following five entities remain ok: lt;, gt;, 
amp;, quote; and apos;

Thanks for the reply; it pushed me into checking further.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Oct 22, 2014, at 13:41, Jirka Kosek ji...@kosek.cz wrote:

 On 22.10.2014 18:48, Richard Hamilton wrote:
 It looks as though the next version of epubcheck may reject epub3 files that 
 use named character entities (amp;, etc.).
 
 Any source for this information?
 It's hard to believe that amp; will be refused as it can't be written
 directly (same with lt; and to some extent with gt;, quot; and apos;).
 
   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 rep.
 --
Bringing you XML Prague conferencehttp://xmlprague.cz
 --
 


-
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 and named entities

[Richard Hamilton]

I got the information from a conversion house, but I'm following up with them, 
so I'll refrain from naming them until they get a chance to respond.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Oct 22, 2014, at 13:41, Jirka Kosek ji...@kosek.cz wrote:

 On 22.10.2014 18:48, Richard Hamilton wrote:
 It looks as though the next version of epubcheck may reject epub3 files that 
 use named character entities (amp;, etc.).
 
 Any source for this information?
 It's hard to believe that amp; will be refused as it can't be written
 directly (same with lt; and to some extent with gt;, quot; and apos;).
 
   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 rep.
 --
Bringing you XML Prague conferencehttp://xmlprague.cz
 --
 


-
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] epub3 and named entities

[Richard Hamilton]

It looks as though the next version of epubcheck may reject epub3 files that 
use named character entities (amp;, etc.).

Right now, the stylesheets will generate at least some of these, even if you 
use the numeric equivalent (e.g., if you use #38; for ampersand in your 
source, the output will be amp;).

Is there an option that will keep Saxon (which is what we currently use) from 
making this change? Or are there options with other processors that might be a 
better choice?

Thanks,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Bad DOCTYPE on toc.ncx in epub2 stylesheets snapshot

[Richard Hamilton]

Hi Jirka,

Thanks for the information.

It turns out that you were exactly correct.

In xhtml-1_1 (which epub2 uses), the files docbook.xsl, maketoc.xsl, and 
profile-docbook.xsl each contain the following line:

xsl:output method=xml encoding=UTF-8 indent=no 
doctype-public=-//W3C//DTD XHTML 1.1//EN
doctype-system=http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd/

Apparently, this causes all files to have this doctype added, including 
content.opf and toc.ncx, which use different schemas.

When I remove the attributes doctype-public and doctype-system from this line 
in all three files, the problem goes away and the epub validates correctly 
against epubcheck.

BTW, your message reminded me that I ran into (and fixed) this same problem 
about a year ago, fixed it, and then forgot about it:-).

Update: I just went to sourceforge and found that this problem has been 
reported, closed, and reopened a couple of times:-). It looks like it may be a 
case where only some processors exhibit this behavior (possibly just saxon6). 

It's probably worth checking out with later versions of saxon and xsltproc, but 
I don't have the time to do that now. I'll try to look at it again in a week or 
so.

Best regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Oct 2, 2014, at 1:35, Jirka Kosek ji...@kosek.cz wrote:

 On 2.10.2014 2:22, Richard Hamilton wrote:
 !DOCTYPE ncx
  PUBLIC -//W3C//DTD XHTML 1.1//EN 
 http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
 
 There is a valid xmlns attribute on the root element, and if you remove the 
 DOCTYPE lines completely, the file is fine. In 1.78.1 this does not happen.
 
 I poked around the stylesheets, but couldn't figure out what's going on, and 
 I didn't see anything in the revision history that seemed pertinent.
 
 Has anyone run into the same thing?
 
 I never used EPUB2 stylesheets, but trouble spot is:
 
 xsl:template name=ncx
xsl:call-template name=write.chunk
  ...
  xsl:with-param name=doctype-public select=''/ !--
 intentionally blank --
  xsl:with-param name=doctype-system select=''/ !--
 intentionally blank --
 
 Specifying empty doctype usually doesn't override doctype specified on
 xsl:output. You might try disabling doctype everywhere, it shouldn't
 matter even for XHTML content inside EPUB package.
 
   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 rep.
 --
Bringing you XML Prague conferencehttp://xmlprague.cz
 --
 


-
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] Bad DOCTYPE on toc.ncx in epub2 stylesheets snapshot

[Richard Hamilton]

The subject line says nearly everything.

If I try to create an epub2 file using a recent snapshot (Sept. 28), toc.ncx 
gets written correctly, except it has a DOCTYPE for an xhtml file:

!DOCTYPE ncx
  PUBLIC -//W3C//DTD XHTML 1.1//EN 
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;

There is a valid xmlns attribute on the root element, and if you remove the 
DOCTYPE lines completely, the file is fine. In 1.78.1 this does not happen.

I poked around the stylesheets, but couldn't figure out what's going on, and I 
didn't see anything in the revision history that seemed pertinent.

Has anyone run into the same thing?

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Question on header.table template in fo stylesheets

[Richard Hamilton]

I noticed something curious in the header.table template in pagesetup.xsl in 
the fo stylesheets.

The first thing this template does is set the margin-left (or margin-right for 
right-to-left languages) attribute to 0pt. It doesn't change the other margin.

I noticed because I set the margin in header.content properties to a negative 
value to get an hanging header (that is, I want part of the header, in this 
case the page number, in the outside margin). The hanging header works 
everywhere except on the verso pages in the index because margin-left is reset 
for the index.

I'm guessing there is a good reason for this, but I'm not sure what it is.

Does anyone know why this is the case?

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Colophon doesn't reset footnote numbering

[Richard Hamilton]

I just ran into a bug in the fo stylesheets.

If a colophon has a footnote (or a link and you've set ulink.footnotes) and the 
preceding chapter, appendix, etc., also has a footnote, then the footnote 
numbering in the colophon will not start from 1; it will start from where the 
preceding section ended.

It looks like the error is in the following two templates:

footnote.xsl: xsl:template match=d:footnote mode=footnote.number
xref.xsl: xsl:template name=ulink.footnote.number

In both templates, the variable fnum is calculated using xsl:number.  I believe 
the error is that the from attribute for xsl:number should include colophon, 
but it doesn't.

Given that there's a note stating list in @from is probably not complete, and 
given that making this change fixed the problem, I think that's all that needs 
to be done to fix this bug.

Does anyone know if there is anything else that might have to be changed?

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] support for xpointer

[Richard Hamilton]

I have had success using xmllint to access nodes using xpath.

I can't tell you how well it supports xpath, but I am able to do things like 
the example below, which turns a chapter into a preface and changes the title.

  preface
  titlePreface/title
  xi:include href=ebook-intro.xml

xpointer=xmlns(d=http://docbook.org/ns/docbook)xpointer(/d:chapter/d:info/following-sibling::*))/

  /preface

I vaguely remember being told that the support for xinclude in xmllint is 
neither complete nor standard, so I wouldn't expect the markup above to work 
for any other tool, but xmllint does what I need:-).

Regarding the question of pulling the second listitem from a section with a 
particular id, I think the following will do the trick (I don't claim it's the 
most elegant way to do this, but it works with xmllint):

  xi:include href=filename.xml
  
xpointer=xmlns(d=http://docbook.org/ns/docbook)xpointer(//d:section[@xml:id='sect-a']//d:listitem[2]))/


Best regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Sep 14, 2014, at 7:34, Stefan Seefeld ste...@seefeld.name wrote:

 On 09/14/2014 05:09 AM, Jirka Kosek wrote:
 On 14.9.2014 3:22, Stefan Seefeld wrote:
 Can anyone confirm the state of xpointer support in xsltproc, or any
 other Free XSLT processor for that matter ? (For example, what about
 saxon ?) Are there any (free) test suites that I could use to get a
 sense of what is supported and what not ?
 AFAIK only thing which is reliable and works across different
 implementations is referencing node by its ID. Very sad.
 
 That's sad indeed. I was trying to fetch a specific subnode of an
 identified element, but couldn't manage to get that working with
 xsltproc (haven't tried with saxon yet), so I was looking for working
 examples.
 
 (I'm not even sure what the right spelling is to express second
 listitem within a section with id demo  using xpointers. And xsltproc
 typically doesn't even give an error. It simply ignores the entire
 xpointer attribute :-( )
 
 There is XInclude test suite, which has some XPointer tests as well:
 
 http://dev.w3.org/cvsweb/2001/XInclude-Test-Suite/
 
 Thanks. These tests all are rather old, and limited as far as I can see.
 Hasn't there been any recent activity on xpointers recently ? What other
 tools for transclusion are people using nowadays ?
 
 Thanks,
Stefan
 
 -- 
 
  ...ich hab' noch einen Koffer in Berlin...
 
 
 -
 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] support for xpointer

[Richard Hamilton]

Hi Stefan,

I didn't say it was elegant:-).

I agree that DocBook transclusion may be the way to go. I need to look into it 
further for our book process.

And a multi-stage process works well for us. Maybe it's my long experience with 
Unix, but I use multi-stage processes all the time. They let you use the right 
tool for each step in the process and give you intermediate files that you can 
examine when things go wrong.

Our current process uses xmllint, xsltproc, saxon (6 and 8), and perl, all 
stitched together using make (someday I may use ant, but not today:-).

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Sep 14, 2014, at 13:01, Stefan Seefeld ste...@seefeld.name wrote:

 On 09/14/2014 02:02 PM, Richard Hamilton wrote:
 Regarding the question of pulling the second listitem from a section with a 
 particular id, I think the following will do the trick (I don't claim it's 
 the most elegant way to do this, but it works with xmllint):
 
  xi:include href=filename.xml
  
 xpointer=xmlns(d=http://docbook.org/ns/docbook)xpointer(//d:section[@xml:id='sect-a']//d:listitem[2]))/
 
 Thanks, that works indeed !
 But the syntax is rather verbose and cumbersome, especially given that I
 want to establish references such as the above for a couple of hundreds
 of definitions in a single (modular) document.
 I'm considering defining my own technique (drawing inspiration from
 http://www.docbook.org/docs/transclusion/transclusion.html), then using
 a two-phase processing with the first doing the transclusion processing
 to generate valid DocBook, then the second to do the actual formatting.
 
 Thanks for all the help (and the continued work that goes into DocBook's
 evolution),
 
Stefan
 
 -- 
 
  ...ich hab' noch einen Koffer in Berlin...
 


-
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] Numbered paragraphs

[Richard Hamilton]

Before I dive into a customization, has anyone ever customized the fo 
stylesheets to generate paragraph numbers? That is, sequentially numbering 
every paragraph in a book from the beginning to the end.

The ideal would be to put them into the margin, but I'd be happy with any 
method that assigned a sequential number to each paragraph.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Numbered paragraphs

[Richard Hamilton]

Thanks Stefan and Jens,

Both of your suggestions were useful in leading me to a possible resolution.

I tried Jens' solution, which worked as advertised, but then after looking at 
Stefan's, I decided to create an intermediate DocBook source with the 
numbering. This has the advantage of letting me merge back into the source 
content (like index entries) that might have been generated using the PDF.

I tried to do this in two ways. The first way was to insert a phrase with the 
number at the beginning of every paragraph. The second was to insert a sidebar 
in the same spot, then monkey with the parameters to get the sidebar contents 
in the outside margin (basically just change body.start.indent and 
body.end.indent to .5in, though I think this won't work with FO. It does work 
with XEP).

Both methods work, but even though it seemed a bit strange to insert sidebars 
all over the place, I went with the second method, which works and is valid 
DocBook (though if I use real sidebars in a book, I'll need to detect them to 
avoid nesting sidebars:).

Since the objective was not to get beautiful output, but rather to get a 
working draft that an indexer can use, this does what I need. And, it looks 
like it wouldn't take too much to make this look pretty good, if you wanted to 
have a production output that did this kind of thing.

Thanks again, Jens and Stefan, for pointing me in the right direction.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Aug 1, 2014, at 3:56 PM, Stefan Seefeld ste...@seefeld.name wrote:

 On 08/01/2014 06:47 PM, Richard Hamilton wrote:
 Before I dive into a customization, has anyone ever customized the fo 
 stylesheets to generate paragraph numbers? That is, sequentially numbering 
 every paragraph in a book from the beginning to the end.
 
 The ideal would be to put them into the margin, but I'd be happy with any 
 method that assigned a sequential number to each paragraph.
 
 For an OMG specification I have used ordered lists to wrap all text to
 get essentially the same effect as you seem to seek (see
 http://www.omg.org/spec/VSIPL++/1.2/PDF/).
 You can find my customization in
 https://github.com/vsip/specs/tree/master/xsl, though this may look like
 a set of crude hacks to trained eyes. (Feel free to clone at your
 leisure)
 
Stefan
 
 -- 
 
  ...ich hab' noch einen Koffer in Berlin...
 


-
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] Possible to render footnotes on the same page as the reference?

[Richard Hamilton]

Hi David,

My very limited understanding of Flying Saucer and iText is that it works with 
xhtml content, so I presume you are using the xhtml stylesheets.

The DocBook html/xhtml stylesheets put footnotes at the end of the component 
(typically chapter or appendix) that the footnote appears in. If you're using 
chunked output, it puts them at the end of the chunk that contains the 
footnote. Since the pagination is not known in the xhtml, that's as close as 
you can get with the stylesheets. You can see a discussion of footnotes and the 
stylesheets in Bob Stayton's book at this link: 
http://www.sagehill.net/docbookxsl/Footnotes.html

You might be able to hack Flying Saucer and/or iText to recognize a footnote 
(the markup makes it easy to find footnotes and footnote references) and handle 
it appropriately, but I don't think that would be an easy hack. You might also 
try using the DocBook fo style sheets and fop (both open source) and generate 
PDF that way.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 7, 2014, at 1:31 PM, KARR, DAVID wrote:

 I know very little about docbook, I'm just starting to edit a set of 
 documents that is using it.
 
 The application I'm working on generates documents from docbook files through 
 Flying Saucer and iText.
 
 I see that footnotes currently render at the end of chapters, as opposed to 
 the end of the page.  Is it practical and possible to make footnotes render 
 at the bottom of the page?
 
 -
 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] I have a title page - how about a back page ?

[Richard Hamilton]

Hi Richard,

I'd use colophon. A colophon doesn't normally create a TOC entry, and it is 
normally placed at the end of the book. You'll probably need to do some 
customizing of the stylesheets to get it to look like you want, but you'd need 
to do that regardless.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jun 6, 2014, at 6:43 AM, Kerry, Richard wrote:

  
 I can see from Bob's book that Docbook and the stylesheets provide a 
 mechanism I can use to get a decorated title page, but at the moment my 
 result PDF document ends straight after all the sections and the appendix.
 I would like to have another page to finish off.  It will be decorated a bit 
 like my title page is, and have a little company information.
  
 But, I can't see anything built in to docbook and the stylesheets that looks 
 like the way to get me a page at the end of the document.
  
 Can anyone advise me how I might do this ?
  
  
  
 Regards,
 Richard.
  
  
  
 Richard Kerry
 BNCS Engineer, SI SOL Telco  Media Vertical Practice
 T: +44 (0)20 3618 2669
 M: +44 (0)7812 325518
 G300, Stadium House, Wood Lane, London, W12 7TA
 richard.ke...@atos.net
  
 
 
 
 
 
 This e-mail and the documents attached are confidential and intended solely 
 for the addressee; it may also be privileged. If you receive this e-mail in 
 error, please notify the sender immediately and destroy it. As its integrity 
 cannot be secured on the Internet, the Atos group liability cannot be 
 triggered for the message content. Although the sender endeavours to maintain 
 a computer virus-free network, the sender does not warrant that this 
 transmission is virus-free and will not be liable for any damages resulting 
 from any virus transmitt
 


attachment.ashx
Description: XML document


BsAt4ube4GblQIASUVORK5CYII=
Description: Binary data


attachment.ashx
Description: XML document
 
 -
 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] centring a picture

[Richard Hamilton]

Hi Alex,

Try align=center on the imagedata element.

I would also suggest checking out Bob Stayton's book, which has a lot of 
information about image placement and scaling, a topic that can get hairy.

You can find the book online at http://sagehill.net and I recommend getting the 
print version if you do very much with DocBook.

BTW, the docbook-apps mailing list is the best place for this kind of request, 
so I'm cross-posting my reply there.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On May 28, 2014, at 3:28 PM, Alex Kleider wrote:

 Still a beginner, I've become a great fan of docbook, mainly to then convert 
 to html.
 My current project requires insertion of photos (png, jpeg).
 Is there a way to specify that a photo 
 (mediaobjectimageobjectimagedata)should be aligned in the middle, 
 rather than to the left margin of the the page?
 Thanks in advance for any help.
 alex
 
 -
 To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org
 For additional commands, e-mail: docbook-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] Problems with sect1 when using 5.1CR2

[Richard Hamilton]

Hi Carlos,

Looks like that's a bug in the schema. (I'm copying this post to the DocBook 
TC, since the TC will need to look into this).

When I look in the 5.1CR2 schema, I see the following for sect1:

  define name=db.sect1
 element name=sect1
---
ref name=db.sect1.attlist/
ref name=db.sect1.info/
ref name=db.navigation.components/
   ...
   /div
==
The problem is that ref name=db.navigation.components/  should be inside a 
zeroOrMore element.

For db.section, db.sectX, this statement is inside a zeroOrMore element, so I 
think this is a typo in this version of the RelaxNG.

Thanks for catching this.

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 30, 2014, at 11:41 AM, Carlos Araya wrote:

 chapter xml:id=looking.forward xmlns=http://docbook.org/ns/docbook;
 xmlns:xlink=http://www.w3.org/1999/xlink;
 info
 titleLooking forward: What's next?/title
 /info
 para/
 
 sect1
 titlePushing the boundaries of EPub/title
 
 paraContent of the chapter goes here/para
 /sect1
 /chapter
 
 


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] ePub structure has TOC before inside title page

[Richard Hamilton]

When I generate an epub2, I get the TOC before the inside title page, rather 
than the other way around, which would seem to be the more natural order.

Does anyone have any idea why that might be happening, and is there a way to 
get a more traditional ordering?

Thanks,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Possible problem with typed indexes

[Richard Hamilton]

I just tried to use the type facility with indexes for the first time, and I 
got a strange result.

I have indexterms with type=author and indexterms with no type attribute. 
E.g.,

indexterm type=authorprimaryShakespeare, William/primary/indexterm

I inserted two index tags, one with type=author and one without. The one with 
author has a title. E.g.,

index type=authortitleAuthors/title/index
index/

I get two indexes, but they are identical except for the title. That is, all of 
the terms, regardless of type, are in both indexes. I expected to get one 
complete index and one index with only the terms that have type=author.

Has anyone else run into this? Am I doing something wrong, or is this a bug in 
the stylesheets (I'm using 1.78.1).

Best regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Indexes in mobi

[Richard Hamilton]

I'm running into something strange with indexes when I convert from epub to 
mobi using kindlegen.

I use the epub3 transform and set kindle.extensions=1, then use kindlegen to 
get a .mobi file.

The index comes out fine for ePub, but for .mobi, some devices (Paperwhite and 
Kindle Fire on the kindle previewer) throw away all indentation so there is no 
distinction between primary and secondary terms, though they do leave an extra 
vertical space between a primary and its secondaries.

And some (Kindle DX on the previewer and Kindle on iPhone) seemingly randomly 
indent (or don't indent) primary and secondary terms, and also frequently lose 
the line break when a primary term without secondaries precedes another primary 
(unless the first primary is immediately after a letter heading).

epub looks great on iOS, though I haven't tried it anywhere else.

Has anyone run into this, and has anyone figured out how to solve the problem? 
I've been playing around with CSS to no avail, but I'm reluctant to do any 
major surgery in the index if others have solved the problem.

Thanks,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Continued lines in index

[Richard Hamilton]

Has anyone implemented a way to get a continued line in a printed index?

That is, when a primary term that has a lot of secondaries breaks across a page 
boundary, many indexes will include a line like this at the top of the new page:

Bieber, Justin (continued)
   greatest hits
   ...

Right now, in this case, the stylesheets would start that page with greatest 
hits rather than a reiteration of the primary term.

Any suggestions would be welcome.

Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Continued lines in index

[Richard Hamilton]

Hi Bob,

Thanks for the pointer. If I can make this work (probably not for a few weeks), 
and have a reasonably clean implementation, I'll post the result (my client is 
me this time around:-).

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Sep 27, 2013, at 11:37 AM, Bob Stayton wrote:

 Hi Dick,
 Yes, I did this for a client using the same mechanism that can be used for 
 tables, as described in:
 
   
 http://www.sagehill.net/docbookxsl/TableTemplateCust.html#TableContinuedLabel
 
 You need to customize this template from fo/autoidx.xsl:
 
 xsl:template match=indexterm mode=index-primary
 
 and put the content inside a single-cell fo:table, as described in that 
 section. The method depends on the FO processor.  I don't think FOP supports 
 the retrieve-table-marker property yet, though.  Sorry, I can't give you the 
 code from that client.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 --
 From: Richard Hamilton hamil...@xmlpress.net
 Sent: Friday, September 27, 2013 10:49 AM
 To: apps docbook docbook-apps@lists.oasis-open.org
 Subject: [docbook-apps] Continued lines in index
 
 Has anyone implemented a way to get a continued line in a printed index?
 
 That is, when a primary term that has a lot of secondaries breaks across a 
 page boundary, many indexes will include a line like this at the top of the 
 new page:
 
 Bieber, Justin (continued)
  greatest hits
  ...
 
 Right now, in this case, the stylesheets would start that page with 
 greatest hits rather than a reiteration of the primary term.
 
 Any suggestions would be welcome.
 
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 
 -
 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] attribute sets -- what possible attributes can I use?

[Richard Hamilton]

Hi Robert,

Regarding your questions:

1) Yes, you can add other attributes. It's worth trying any attribute in Dave's 
book that you think might be useful.

2) I don't know of a list of allowable attributes for the DocBook attribute 
sets. I think a better way to approach things is to look at the fo elements 
that a particular attribute set is attached to. I suspect that 9 times out of 
10 that will be either fo:block or fo:inline. So, a lot of the time, if an 
attribute will work on one of those two elements, you can add it to an 
attribute set.

I usually grep for the attribute set name in the fo stylesheet directory and 
look for what it's attached to. For example, list.block.spacing appears on 
fo:list-block and fo:block (I guess it's one of the exceptions:-).

I hope that helps.

Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Sep 14, 2013, at 8:25 AM, Robert Nagle wrote:

 I need to work with attribute sets to customize my print output. 
 
 I think I can  understand what they are about and also have looked at the 
 list of fo/param.xsl
 
 But  I don't understand is what possible named attributes can be added to a 
 single attribute set. For example, here is the list.block.spacing (which I 
 think I need to modify). 
 
 xsl:attribute-set name=list.block.spacing
   xsl:attribute name=space-before.optimum1em/xsl:attribute
   xsl:attribute name=space-before.minimum0.8em/xsl:attribute
   xsl:attribute name=space-before.maximum1.2em/xsl:attribute
   xsl:attribute name=space-after.optimum1em/xsl:attribute
   xsl:attribute name=space-after.minimum0.8em/xsl:attribute
   xsl:attribute name=space-after.maximum1.2em/xsl:attribute
 /xsl:attribute-set
 
 1. Am I correct in assuming that it's possible to add other attributes here 
 which are not mentioned? 
 2. Where can I find a list of possible values which can be used for each (or 
 all) attribute sets? 
 
 I know it has something to do with xsl-fo, and actually I have a copy of Dave 
 Pawson's XSL-FO book lying around, but other than that, I don't really have a 
 clue where to start. 
 
 -- 
 Robert Nagle
 6121 Winsome Ln #56C, Houston TX 77057-5581
 (H) 713 893 3424/ (W) 832-251-7522 Carbon Neutral Since Jan 2010
 http://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

Re: [docbook-apps] DocBook 5 samples for tests

[Richard Hamilton]

Hi Camille,

I don't think there is a comprehensive set of DB5 examples. However, in testing 
changes to the db4 to db5 stylesheet (db4-upgrade.xsl), I converted all of the 
db4 samples to db5. There were a few files that for various reasons didn't 
convert successfully (five total), but the rest are all fine.

If you'd like, I can zip up the files and send them over to you.

In related news, I just committed to sourceforge changes to the db4-upgrade.xsl 
stylesheet based on changes suggested by Alexey Neyman (who also provided code 
to implement his suggestions). In addition, I made further changes that expand 
the range of cases the conversion handles.

If enough people are interested, I can post the DB5 converted tests somewhere 
convenient, though they are easy to make with db4-upgrade.xsl.

Best Regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Aug 21, 2013, at 9:42 AM, Camille Bégnis wrote:

 Hello,
 
 there is an extensive set of samples in DB4, but I cannot find a DB5 version, 
 does it exist?
 
 I'm looking for it to stress test our Calenco CMS (http://www.calenco.com)
 
 Thanks for your help,
 
 -- 
 NeoDoc
 Camille Bégnis
 cami...@neodoc.fr
 Tél: +33 (0)4.42.52.24.20
 5, rue de la Touloubre
 13770 Venelles
 France
 http://www.neodoc.fr/


-
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] A little XML-to-XML handholding?

[Richard Hamilton]

Hi Mike,

I bit off topic for DocBook, but not for your question: rather than doing a 
print run, you may want to look into print-on-demand using a company like 
CreateSpace or Lulu. You'll have much lower up-front costs and you won't need 
to turn your home into a warehouse:)

Also, I'm not sure which tool you were referring to, but Herold (the xhtml to 
DocBook converter) is open source. In fact, you can build an entirely 
open-source tool chain for DocBook. The only weak link is FOP, which has some 
gaps in compliance with the FO standard (most noticeably in indexing), but it 
is getting better all the time and may work for your purposes.

Best Regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 30, 2013, at 12:01 AM, Michael Crawford wrote:

 Thanks for your help, everyone.
 
 I need to brush up on my DocBook before I reply in real detail.  It's
 been eons.  I did know DocBook quite well back in the day, but at the
 time was not happy with the available tools.  DocBook itself I think
 is just dandy, but the tools I was using then were a real PITA.
 
 Camille, I'm afraid mine is quite a low budget operation.  However,
 I'm contemplating using a KickStarter Campaign to finance an initial
 print run of at least one of my books.  If I do that, I expect I could
 afford to pay for a license for the proprietary version of your tool.
 
 It's been a long time, but I was at one time intimately familiar with
 the Apache Xerces-C (actually C++) XML DOM API.  One approach that I
 could conceivably take, would be to write a C++ program, that would
 use Xerces-C to read my essays one-at-a-time into their own DOM, then
 copy the contents of the XHTML elements into the corresponding DocBook
 5 XML elements.  For p to Para that would be straightforward, but
 I haven't looked into the other kinds of elements yet, or attributes.
 
 I just now installed some of the DocBook packages on my Mountain Lion
 MacBook Pro with MacPorts, however the docbook-utils package would not
 install, no doubt due to some configuration bug in its port file.
 I'll report that via the MacPorts trouble ticket procedure.
 
 Best,
 
 Mike Crawford
 li...@warplife.com
 http://www.warplife.com/
 
 On Mon, Jul 29, 2013 at 6:25 PM, Richard Hamilton hamil...@xmlpress.net 
 wrote:
 Hi Mike,
 
 I have had very good luck with Herold (http://www.michael-a-fuchs.de).
 
 I'm usually not fortunate enough to have strict xhtml, so we do some 
 pre-processing (usually on well-behaved, but idiosyncratic, html), tidy it 
 up into xhtml, then run Herold.
 
 You may find that you need to do some light pre- or post-processing, but for 
 us it has never been more than a short XSL stylesheet to do things like 
 remove empty paragraphs from the initial XHTML or change the root element in 
 the resulting DocBook (the latter can probably be handled by Herold using 
 Groovy scripts, but I've learning all the scripting languages I need for the 
 time being, so I stick with XSL or Perl-:).
 
 When we build a book, like you're doing, rather than concatenate pieces, we 
 keep each file separate, then create a book file that uses xinclude to 
 pull in the chapters. That simplifies the scripting and makes it easier to 
 move parts around in the book.
 
 Regarding the killer feature, if you use the right option (I don't remember 
 off-hand, but it's in Bob Stayton's book (http://sagehill.net)), you can get 
 exactly what you want for links in the hard copy.
 
 Best Regards,
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 On Jul 27, 2013, at 6:18 PM, Michael Crawford wrote:
 
 Greetings, Earthlings,
 
 I have some articles and essays that are all marked up with valid XHTML 1.0 
 Strict with CSS, that I would like to publish as bound, dead-tree books, 
 possibly also eBooks.
 
 It seems to me that the best way to do that would be to convert each 
 collection of essays into a single DocBook XML document.  Can you give me 
 some tips on how to get started?  I'm happy to Read The Fine Manual, but 
 there are so many.
 
 One such volume, when printed both-sides on US Letter paper, is ~250 pages. 
  The essays range from two to fifty pages.
 
 What I _think_ I need to do is to use some manner of XML-to-XML 
 transformation, to strip everything from the beginning of each document, up 
 to and including the opening body, then from the closing /body, to the 
 end of each document
 
 ... then concatenate them all together, with each present XHTML document 
 being a single chapter in the resulting DocBook document...
 
 ... then replace HTML-style tags and attributes with DocBook-style: p to 
 Para, for example...
 
 ... what would be for me, A Killer Feature, would be to convert each HTML 
 a href=... hyperlink into a DocBook footnote.  So where I have this:
 
 ===
 a long-forgotten a href=http://www.kuro5hin.org/;cesspool/a in a 
 far-off

Re: [docbook-apps] Generating e-pub and html indexes

[Richard Hamilton]

Sorry for the delay in getting back to you all on this. I have been trying to 
upload the customization to wiki.docbook.org, but I am having a bit of trouble 
doing that. I may end up putting it on a different site temporarily, unless I 
can figure out what's going on in the wiki.

I should be set one way or the other in the next day or two, and I'll let 
everyone know at that point.

Dick 
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 22, 2013, at 7:33 PM, Xmplar wrote:

 Hi Richard,
 Please do publicize my customization - I haven't changed any of that coding 
 in the meantime.
 Dave
 
 On 23-07-13 11:49 AM, Richard Hamilton wrote:
 Hi Paul,
 
 Dave Gardiner put together an index customization that I've used to generate 
 index entries that point to numbered sections.
 
 That is, if you have section numbering turned on, and you use this 
 customization, the index will use the section number instead of the title. 
 So you get index entries that look like this:
 
 agile development, 1.4, 2.3.6
 
 This doesn't work if you have section numbering turned off. I have an item 
 on my todo list to make it so it will still work with section numbering on 
 or off, but that has sunk to the bottom of my todo list for now:-).
 
 If you'd like to see the customization, I can send it to you if it's okay 
 with Dave.
 
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 On Jul 22, 2013, at 5:02 PM, Pc Thoms wrote:
 
 A specific example I should not provide, as it is beyond my expertise, but 
 I have expectations and hopes for such. I am fairly competent in xml, but 
 not with xslt.
 
 If the locators in a DocBook formatted xml file can point to 
 thechapter/,section,para/,table/, etc., within the document, the 
 more specific the reference between the locator and the origination of 
 theindexterm/  so much the better. Preferably the generated locator will 
 point directly to the originatingindexterm/  placed in the document, or 
 the lowest hierarchical block element. Rather than linking to 
 thechapter/, which may contain hundreds, to thousands, of words it would 
 be better to link to the lowest hierarchical block element that contains 
 theindexterm/, such as apara/  orline/  (DocBook-Publisher).
 This should make the anindex/  locator link directly to specific place in 
 the text, that one would presumably be interested in once they click a link.
 Locators that link to the beginning of achapter/  orsection/  that may 
 contain 500+ words is not very useful. But a locator that links one 
 directly to thesection,para/,table/, orline/, would serve its’ 
 readers well.
 
 What I’m looking for is an index locator that has an “href” attribute that 
 links directly to an anchored point in an XHTML and E-Pub document.
 Any assistance, and direction, is appreciated.
 
 Paul
 
 
 


-
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] A little XML-to-XML handholding?

[Richard Hamilton]

Hi Mike,

I have had very good luck with Herold (http://www.michael-a-fuchs.de).

I'm usually not fortunate enough to have strict xhtml, so we do some 
pre-processing (usually on well-behaved, but idiosyncratic, html), tidy it up 
into xhtml, then run Herold.

You may find that you need to do some light pre- or post-processing, but for us 
it has never been more than a short XSL stylesheet to do things like remove 
empty paragraphs from the initial XHTML or change the root element in the 
resulting DocBook (the latter can probably be handled by Herold using Groovy 
scripts, but I've learning all the scripting languages I need for the time 
being, so I stick with XSL or Perl-:).

When we build a book, like you're doing, rather than concatenate pieces, we 
keep each file separate, then create a book file that uses xinclude to pull 
in the chapters. That simplifies the scripting and makes it easier to move 
parts around in the book.

Regarding the killer feature, if you use the right option (I don't remember 
off-hand, but it's in Bob Stayton's book (http://sagehill.net)), you can get 
exactly what you want for links in the hard copy.

Best Regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 27, 2013, at 6:18 PM, Michael Crawford wrote:

 Greetings, Earthlings,
 
 I have some articles and essays that are all marked up with valid XHTML 1.0 
 Strict with CSS, that I would like to publish as bound, dead-tree books, 
 possibly also eBooks.
 
 It seems to me that the best way to do that would be to convert each 
 collection of essays into a single DocBook XML document.  Can you give me 
 some tips on how to get started?  I'm happy to Read The Fine Manual, but 
 there are so many.
 
 One such volume, when printed both-sides on US Letter paper, is ~250 pages.  
 The essays range from two to fifty pages.
 
 What I _think_ I need to do is to use some manner of XML-to-XML 
 transformation, to strip everything from the beginning of each document, up 
 to and including the opening body, then from the closing /body, to the 
 end of each document
 
 ... then concatenate them all together, with each present XHTML document 
 being a single chapter in the resulting DocBook document...
 
 ... then replace HTML-style tags and attributes with DocBook-style: p to 
 Para, for example...
 
 ... what would be for me, A Killer Feature, would be to convert each HTML a 
 href=... hyperlink into a DocBook footnote.  So where I have this:
 
 ===
 a long-forgotten a href=http://www.kuro5hin.org/;cesspool/a in a far-off 
 corner of the World-Wide Web...
 ===
 would look something like this in hardcopy form:
 
 a long-forgotten cesspool[1] in a far-off corner of the World-Wide Web...
 
 1. http://www.kuro5hin.org/
 
 =
 
 I'd also like to design my own custom stylesheets.  I'll ask about that later 
 though.  I have a copy of Android Programming: The Big Nerd Ranch Guide by 
 Bill Phillips and Brian Hardy.  In the Acknowledgements, the authors credit 
 Chris Loper of http://www.intelligentenglish.com/ for his DocBook toolchain.
 
 That volume is exquisite.  I'd like to design my own volume, not to look the 
 same, but to look as good, with my own personal style.
 
 Thanks for any advice you can give me.
 
 Mike Crawford
 li...@warplife.com
 http://www.warplife.com/ 
 
 


-
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] Generating e-pub and html indexes

[Richard Hamilton]

Hi Paul,

Dave Gardiner put together an index customization that I've used to generate 
index entries that point to numbered sections.

That is, if you have section numbering turned on, and you use this 
customization, the index will use the section number instead of the title. So 
you get index entries that look like this:

agile development, 1.4, 2.3.6

This doesn't work if you have section numbering turned off. I have an item on 
my todo list to make it so it will still work with section numbering on or off, 
but that has sunk to the bottom of my todo list for now:-). 

If you'd like to see the customization, I can send it to you if it's okay with 
Dave.

Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Jul 22, 2013, at 5:02 PM, Pc Thoms wrote:

 A specific example I should not provide, as it is beyond my expertise, but I 
 have expectations and hopes for such. I am fairly competent in xml, but not 
 with xslt.
 
 If the locators in a DocBook formatted xml file can point to the chapter/, 
 section, para/, table/, etc., within the document, the more specific 
 the reference between the locator and the origination of the indexterm/ so 
 much the better. Preferably the generated locator will point directly to the 
 originating indexterm/ placed in the document, or the lowest hierarchical 
 block element. Rather than linking to the chapter/, which may contain 
 hundreds, to thousands, of words it would be better to link to the lowest 
 hierarchical block element that contains the indexterm/, such as a para/ 
 or line/ (DocBook-Publisher).
 This should make the an index/ locator link directly to specific place in 
 the text, that one would presumably be interested in once they click a link.
 Locators that link to the beginning of a chapter/ or section/ that may 
 contain 500+ words is not very useful. But a locator that links one directly 
 to the section, para/, table/, or line/, would serve its’ readers 
 well.
 
 What I’m looking for is an index locator that has an “href” attribute that 
 links directly to an anchored point in an XHTML and E-Pub document.
 Any assistance, and direction, is appreciated.
 
 Paul
 


-
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] converting DocBook to Confluence

[Richard Hamilton]

Hi Robert,

Confluence has a supported DocBook export, and an experimental DocBook import. 
Here is a link to a blog entry about this capability:

http://ffeathers.wordpress.com/2012/02/19/docbook-export-and-import-round-trip-with-confluence-wiki/

As you will see in the blog entry, the export was used to create a book that my 
company published. It worked quite well for that purpose. The author (Sarah 
Maddox) did some experimentation with the import, with results described in 
that entry, but I have not tried it myself. Also, be aware that the blog 
article is about a year old, so there has probably been some progress since 
then.

Sarah keeps good track of comments on her blog, so if you posted a comment on 
that blog entry, she could probably get you some more up-to-date information.

Best Regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 29, 2013, at 6:38 AM, robert wrote:

 Dear all,
 
 My technical documentation is developed using DocBook and then published to 
 many different formats using the DocBook XSL library, everything works 
 smoothly. 
 
 Now, I would like to publish some content developed in DocBook to a 
 Confluence-based portal. Confluence accepts its own XML format so I can of 
 course write XSL transformations by myself, but before I start I would like 
 to ask you if you have ever tried to convert DocBook to the one of supported 
 Confluence format. Are you aware of any existing tools that would do the job?
 
 Thanks,
 Robert
 
 


-
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] a inside li adds white space in Firefox and IE?

[Richard Hamilton]

Hi Bob,

Would you also recommend setting the same parameter for ePub (either 2 or 3)?

Thanks,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 25, 2013, at 10:10 AM, Bob Stayton wrote:

 Hi Eric,
 You can ditch the named anchors by setting the stylesheet param 
 'generate.id.attributes' to 1.  That will add an id to the li instead of 
 adding an named anchor after it.
  
 Now that ids are fully supported in browsers, and version 1.78 fully 
 implements that parameter, this should probably be the default setting.
  
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 From: Eric Nordlund
 Sent: Wednesday, April 24, 2013 11:29 PM
 To: docbook-apps@lists.oasis-open.org
 Subject: [docbook-apps] a inside li adds white space in Firefox and IE?
 
 Hello.
  
 I’m having a display issue in Firefox and IE regarding my XHTML output. If a 
 step is a linkend for an xref, the paragraph drops down below the line that 
 has the step number. It’s almost as if the a tag is pushing the p down. 
 This only happens on steps with the a tag, and if I delete the a tag the 
 problem goes away. This does not happen in Chrome.
  
 Has anyone found a fix for this? Here is the HTML below:
  
 li class=step title=Step 4
 a id=some_ID xmlns:saxon=http://icl.com/saxon;/a
 pSome text./p
 /li
  
 Thanks,
  
 Eric Nordlund
 Customer Documentation and Training
 Cray Inc.
 901 5th Ave
 Seattle, WA 98164
 (206)701-2232


-
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] a inside li adds white space in Firefox and IE?

[Richard Hamilton]

Thanks Bob, I'll give it a try and see what happens.

Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 25, 2013, at 11:02 AM, Bob Stayton wrote:

 Actually, generate.id.attributes is alread set to 1  in the xhtml5 
 stylesheet, which epub3 imports.  It is not set to that value in epub2 
 because the generate.id.attributes param was not fully implemented in 
 xhtml-1_1 when epub2 was being developed.  I haven't tried it in epub2 in 
 1.78.1, but it should probably work.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 --
 From: Richard Hamilton hamil...@xmlpress.net
 Sent: Thursday, April 25, 2013 10:15 AM
 To: Bob Stayton b...@sagehill.net
 Cc: Eric Nordlund nordl...@cray.com; docbook-apps@lists.oasis-open.org
 Subject: Re: [docbook-apps] a inside li adds white space in Firefox and 
 IE?
 
 Hi Bob,
 
 Would you also recommend setting the same parameter for ePub (either 2 or 3)?
 
 Thanks,
 Dick
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 On Apr 25, 2013, at 10:10 AM, Bob Stayton wrote:
 
 Hi Eric,
 You can ditch the named anchors by setting the stylesheet param 
 'generate.id.attributes' to 1.  That will add an id to the li instead of 
 adding an named anchor after it.
 
 Now that ids are fully supported in browsers, and version 1.78 fully 
 implements that parameter, this should probably be the default setting.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 From: Eric Nordlund
 Sent: Wednesday, April 24, 2013 11:29 PM
 To: docbook-apps@lists.oasis-open.org
 Subject: [docbook-apps] a inside li adds white space in Firefox and IE?
 
 Hello.
 
 I’m having a display issue in Firefox and IE regarding my XHTML output. If 
 a step is a linkend for an xref, the paragraph drops down below the line 
 that has the step number. It’s almost as if the a tag is pushing the p 
 down. This only happens on steps with the a tag, and if I delete the a 
 tag the problem goes away. This does not happen in Chrome.
 
 Has anyone found a fix for this? Here is the HTML below:
 
 li class=step title=Step 4
 a id=some_ID xmlns:saxon=http://icl.com/saxon;/a
 pSome text./p
 /li
 
 Thanks,
 
 Eric Nordlund
 Customer Documentation and Training
 Cray Inc.
 901 5th Ave
 Seattle, WA 98164
 (206)701-2232
 
 
 -
 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 and Saxon: DOCTYPE revisited

[Richard Hamilton]

Hi Bob,

Thanks for the information. That explains what was going on, though it seems 
more like a Saxon 6 bug than a quirk:-).

I had thought that I was through with epub2, but it turns out that there are 
some distributors out there who still only accept epub2, even if your epub3 
doesn't do anything exotic.

Best Regards,
Dick
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 11, 2013, at 9:09 AM, Bob Stayton wrote:

 Hi Dick,
 Generally, it is the last import that takes precedence, so putting 
 outputset.xsl first would not have an effect.  The issue with Saxon 6 is that 
 once the xsl:output doctype attribute values are set to some nonblank value, 
 they cannot be unset to blank by a later import.  As long as xhtml-1_1 is 
 included in the import chain, Saxon cannot reset it to nothing. It seems to 
 treat doctype-system= the same as a missing attribute, and does nothing 
 with it.  This is a Saxon 6 quirk.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 --
 From: Richard Hamilton d...@rlhamilton.net
 Sent: Wednesday, April 10, 2013 2:59 PM
 To: docbook-apps@lists.oasis-open.org
 Subject: [docbook-apps] Epub and Saxon: DOCTYPE revisited
 
 Regarding Bob Stayton's message from a few days ago concerning Saxon not 
 allowing a customization to override a DOCTYPE:
 
 Actually, once a doctype has been set by an xsl:output statement, a
 customization cannot reset it to nothing in Saxon.  That's a quirk of Saxon,
 confirmed by Michael Kay.  The epub stylesheet imports the 
 xhtml-1_1/docbook.xsl
 stylesheet that sets the doctype.  The stylesheet tries to reset that to 
 empty,
 and succeeds with xsltproc, but does not succeeed with Saxon.
 
 You might try the epub3 stylesheets, which don't have this problem.  The 
 other
 solution is to create your own version of xhtml-1_1/docbook.xsl that has an
 xsl:output statement without doctype, and then your own version of
 epub/docbook.xsl that imports it.
 
 Reading this, I thought you might be able to do a workaround like the 
 following (this assumes you have a customization that imports 
 epub/docbook.xsl):
 
 1) Create an xsl file (I'll call it outputset.xsl) that contains just the 
 following:
 
 ?xml version='1.0'?
 xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; 
 version=1.0
 xsl:output method=xml encoding=UTF-8 indent=no /
 /xsl:stylesheet
 
 2) Import that file in your customization before importing epub/docbook.xsl. 
 E.g.,
 
 xsl:import href=outputset.xsl/
 xsl:import href=./epub/docbook.xsl/
 
 
 Since outputset.xsl gets imported before either epub/docbook.xsl or 
 xhtml-1_1/docbook.xsl, it would seem like this xsl:output method would 
 prevail. However, when I tried this it had no effect.
 
 My question is, am I misunderstanding the import mechanism, are the contents 
 of outputset.xsl incorrect, or is something else going wrong?
 
 I'm going to go ahead with Bob's suggestion, but any ideas/explanation 
 concerning why this workaround doesn't work would be welcome.
 
 Best Regards,
 Dick Hamilton
 ---
 XML Press
 XML for Technical Communicators
 http://xmlpress.net
 hamil...@xmlpress.net
 
 
 
 
 -
 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] Epub and Saxon: DOCTYPE revisited

[Richard Hamilton]

Regarding Bob Stayton's message from a few days ago concerning Saxon not 
allowing a customization to override a DOCTYPE:

 Actually, once a doctype has been set by an xsl:output statement, a
 customization cannot reset it to nothing in Saxon.  That's a quirk of Saxon,
 confirmed by Michael Kay.  The epub stylesheet imports the 
 xhtml-1_1/docbook.xsl
 stylesheet that sets the doctype.  The stylesheet tries to reset that to 
 empty,
 and succeeds with xsltproc, but does not succeeed with Saxon.
 
 You might try the epub3 stylesheets, which don't have this problem.  The other
 solution is to create your own version of xhtml-1_1/docbook.xsl that has an
 xsl:output statement without doctype, and then your own version of
 epub/docbook.xsl that imports it.  

Reading this, I thought you might be able to do a workaround like the following 
(this assumes you have a customization that imports epub/docbook.xsl):

1) Create an xsl file (I'll call it outputset.xsl) that contains just the 
following:

?xml version='1.0'?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
xsl:output method=xml encoding=UTF-8 indent=no /
/xsl:stylesheet

2) Import that file in your customization before importing epub/docbook.xsl. 
E.g.,

xsl:import href=outputset.xsl/
xsl:import href=./epub/docbook.xsl/


Since outputset.xsl gets imported before either epub/docbook.xsl or 
xhtml-1_1/docbook.xsl, it would seem like this xsl:output method would prevail. 
However, when I tried this it had no effect.

My question is, am I misunderstanding the import mechanism, are the contents of 
outputset.xsl incorrect, or is something else going wrong?

I'm going to go ahead with Bob's suggestion, but any ideas/explanation 
concerning why this workaround doesn't work would be welcome.

Best Regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] GSoC Application

[Richard Hamilton]

Looks like odd-numbered years are not good for DocBook at GSoC.

Our application for this year's GSoC program was rejected.

Thanks to everyone who volunteered to be a mentor and for the interest from 
prospective students. I hope that some of the ideas generated for this year's 
program can get implemented in other ways. If not, they can form the basis for 
another try next year.

Best Regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net




-
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] Specify FO output font size in xml element?

[Richard Hamilton]

Hi Eric,

Take a look at the monospace.verbatim.properties attribute set. I know you can 
set the font there. You may also be able to adjust the margins (I haven't tried 
that in this context).

Generally, I always look for attribute sets first when doing a customization, 
because if you can get what you need done with the attribute set, it will save 
you having to customize templates.

Best Regards,
Dick Hamilton
---
XML Press
XML for Technical Communicators
http://xmlpress.net
hamil...@xmlpress.net



On Apr 5, 2013, at 5:35 PM, Eric Nordlund wrote:

 Hi gang, I've had so much luck with this list this week. Thanks!
 
 I have some verbatim sections that I need to shrink the font size so the 
 whole line fits on the page. I've modified the xsl:template 
 match=programlisting|screen|synopsis template in verbatim.xsl so that I 
 can pass a width='1' attribute which sets the resulting fo:block to have 0pts 
 indent left and right, which effectively opens my margins up. Another thing I 
 need to do is pass a role=8pt or role=7pt attribute that will shrink the 
 font size down on those elements for the really long ones. Is that something 
 anyone has done before that could share a sample with me?
 
 Am I even on the right track, or am I making things harder than they need to 
 be?
 
 Thanks in advance!
 
 Eric Nordlund
 Customer Documentation and Training
 Cray Inc.
 901 5th Ave
 Seattle, WA 98164
 (206)701-2232
 
 
 
 -
 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