docbook-apps

  • 1.  ragged index with recent fop snapshots

    Posted 07-15-2011 23:17
    Hi,

    I'm about to finish a larger DocBook project. Now that the contents
    are almost complete, I'm looking for ways to get everything rendered
    nicely as PDF. The latest fop release has a nasty bug which causes
    ragged paragraph margins if the lines contain forward links, see this
    thread:

    docbook-apps@lists.oasis-open.org/msg15826.html">http://www.mail-archive.com/docbook-apps@lists.oasis-open.org/msg15826.html

    This has been fixed months ago in the nightly fop builds. This is nice
    to have as my project uses xref liberally.

    However, there is a regression which isn't much better. The right
    margin of the table of contents now looks somewhat ragged. Not much,
    but still visible. I've uploaded an example right here:

    http://www.abload.de/img/docbook-fop-ragged-ind4un1.png

    The longer the title of a chapter or section, the bigger the offset
    from the right. Is there a solution for this problem?

    I'm currently using DocBook V 5.0, docbook-xsl-ns-1.76.1 stylesheets,
    fop-20110715 (same problem with fop-20110304 though). The font used in
    the document is Garamond which does not cause any other problems.

    regards,
    Markus

    --
    Markus Hoenicka
    http://www.mhoenicka.de
    AQ score 38



  • 2.  AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-18-2011 06:20
    Hi Markus,

    we are using dblatex with which we never had such problems.
    Maybe you give it a try.

    regards

    Robert

    -----Ursprüngliche Nachricht-----
    Von: markus.hoenicka@mhoenicka.de [mailto:markus.hoenicka@mhoenicka.de]
    Gesendet: Samstag, 16. Juli 2011 01:17
    An: docbook-apps@lists.oasis-open.org
    Betreff: [docbook-apps] ragged index with recent fop snapshots

    Hi,

    I'm about to finish a larger DocBook project. Now that the contents
    are almost complete, I'm looking for ways to get everything rendered
    nicely as PDF. The latest fop release has a nasty bug which causes
    ragged paragraph margins if the lines contain forward links, see this
    thread:

    docbook-apps@lists.oasis-open.org/msg15826.html">http://www.mail-archive.com/docbook-apps@lists.oasis-open.org/msg15826.html

    This has been fixed months ago in the nightly fop builds. This is nice
    to have as my project uses xref liberally.

    However, there is a regression which isn't much better. The right
    margin of the table of contents now looks somewhat ragged. Not much,
    but still visible. I've uploaded an example right here:

    http://www.abload.de/img/docbook-fop-ragged-ind4un1.png

    The longer the title of a chapter or section, the bigger the offset
    from the right. Is there a solution for this problem?

    I'm currently using DocBook V 5.0, docbook-xsl-ns-1.76.1 stylesheets,
    fop-20110715 (same problem with fop-20110304 though). The font used in
    the document is Garamond which does not cause any other problems.

    regards,
    Markus

    --
    Markus Hoenicka
    http://www.mhoenicka.de
    AQ score 38

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




  • 3.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-18-2011 07:47
    On Mon, 18 Jul 2011 08:19:33 +0200, Robert.Buergel@bmw.de wrote:
    > Hi Markus,
    >
    > we are using dblatex with which we never had such problems.
    > Maybe you give it a try.
    >
    Hi,

    this may be an option although I never tried if dblatex handles
    citations and reference lists well enough for my purposes. I keep my
    references in a SQL database and use RefDB to provide them as raw
    DocBook bibliomixed entries.

    regards,
    Markus

    --
    Markus Hoenicka
    http://www.mhoenicka.de
    AQ score 38



  • 4.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-18-2011 13:10
    On 7/18/2011 3:46 AM, Markus Hoenicka wrote:
    > On Mon, 18 Jul 2011 08:19:33 +0200, Robert.Buergel@bmw.de wrote:
    >> we are using dblatex with which we never had such problems.
    >> Maybe you give it a try.
    >
    > this may be an option although I never tried if dblatex handles
    > citations and reference lists well enough for my purposes. I keep my
    > references in a SQL database and use RefDB to provide them as raw
    > DocBook bibliomixed entries.

    dblatex does well with citations. As for the reference lists, it looks
    like RefDB outputs as BibTeX as well. We use dblatex +XeLaTeX with
    BibTeX for the references (rather than DocBook entries), and the ff.
    processing instruction:

    (which pulls in a BibTeX file References.bib). Then we can take
    advantage of the diversity of LaTeX packages for formatting the
    bibliography. The result is more than adequate for our purposes. The
    one drawback might be that BibTeX doesn't handle Unicode sorts well,
    although I think that only bites you if you have non-Roman scripts in
    some of your authors' names. (It seems to handle accented Roman scripts
    IIRC, but I haven't tested this thoroughly.)
    --
    Mike Maxwell
    maxwell@umiacs.umd.edu
    "My definition of an interesting universe is
    one that has the capacity to study itself."
    --Stephen Eastmond



  • 5.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-18-2011 14:26
    On Mon, 18 Jul 2011 09:10:01 -0400, Mike Maxwell wrote:
    > dblatex does well with citations. As for the reference lists, it
    > looks like RefDB outputs as BibTeX as well. We use dblatex +XeLaTeX
    > with BibTeX for the references (rather than DocBook entries), and the
    > ff. processing instruction:
    >
    > (which pulls in a BibTeX file References.bib). Then we can take
    > advantage of the diversity of LaTeX packages for formatting the
    > bibliography. The result is more than adequate for our purposes.
    > The
    > one drawback might be that BibTeX doesn't handle Unicode sorts well,
    > although I think that only bites you if you have non-Roman scripts in
    > some of your authors' names. (It seems to handle accented Roman
    > scripts IIRC, but I haven't tested this thoroughly.)

    Hi Mike,

    I guess I'll have to run some tests and see how it works out. It'll
    probably be a bit more involved than my current "gmake pdf". The dblatex
    examples indicate that it handles MathML pretty well, which is also
    important to me. At first sight, I didn't find any information about SVG
    graphics though. Are they known to work?

    regards,
    Markus

    --
    Markus Hoenicka
    http://www.mhoenicka.de
    AQ score 38



  • 6.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-18-2011 14:46
    Markus Hoenicka wrote:
    > At first sight, I didn't find any information about SVG
    > graphics though. Are they known to work?

    I don't know. I expect if there's a problem, it would be with LaTeX (or
    XeLaTeX), not with dblatex. As of a few years ago, svg and Xe(La)TeX were
    not compatible:
    http://tug.org/pipermail/xetex/2008-June/010185.html
    Doesn't look like the situation's much better in vanilla LaTeX; the
    consensus seems to be that you need to convert a SVG graphic to PDF before
    including it in the LaTeX source. The same work-around would work in
    XeLaTeX, too.

    Mike Maxwell



  • 7.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-18-2011 20:44
    On Mon, 18 Jul 2011 16:46:19 +0200, maxwell <maxwell@umiacs.umd.edu> wrote:

    > Markus Hoenicka wrote:
    >> At first sight, I didn't find any information about SVG
    >> graphics though. Are they known to work?
    >
    > I don't know. I expect if there's a problem, it would be with LaTeX (or
    > XeLaTeX), not with dblatex. As of a few years ago, svg and Xe(La)TeX
    > were
    > not compatible:
    > http://tug.org/pipermail/xetex/2008-June/010185.html
    > Doesn't look like the situation's much better in vanilla LaTeX; the
    > consensus seems to be that you need to convert a SVG graphic to PDF
    > before
    > including it in the LaTeX source. The same work-around would work in
    > XeLaTeX, too.

    Hi,

    Thanks Mike and Robert for mentionning dblatex. Dblatex can detect the
    figure format (by checking the filename suffix), automatically convert
    SVG to PDF, and then compile the tex file. For SVG figures, it calls
    inkscape.

    Therefore, provided that inkscape(*) is installed there is no need to
    convert manually the figures.

    Regards,
    BG


    (*) if another converter is required, it is not a big deal to add its call
    in dblatex.



  • 8.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-30-2011 21:47
    ben.guillon writes:
    > Thanks Mike and Robert for mentionning dblatex. Dblatex can detect the
    > figure format (by checking the filename suffix), automatically convert
    > SVG to PDF, and then compile the tex file. For SVG figures, it calls
    > inkscape.
    >
    > Therefore, provided that inkscape(*) is installed there is no need to
    > convert manually the figures.
    >

    Hi,

    it took a while to sort things out. This is a brief summary of what
    has happened since:

    1) I gave dblatex a whirl. It took a while to install missing packages
    from CTAN until dblatex ran at all. Eventually I got stuck when
    (La)TeX told me that a glyph was missing from a font that it intended
    to use. My document uses quite a few greek characters and other
    symbols, but I wouldn't expect LaTeX to have a problem with that. As it
    wasn't apparent to me how to move on from there, I had to give up.

    2) I obtained XEP from RenderX. I was not able to make this work
    either on my FreeBSD box. XEP was not able to make use of the
    installed PDF core fonts, resulting in a document mostly made up from
    hashes. However, as far as I could tell the TOC page numbers were
    aligned :-) I tried to add the custom fonts that I use according to
    the instructions shipped with XEP, but I couldn't find any indication
    that XEP would pick up this config file. Moreover, XEP was not able to
    handle approx. half of the 130 images (a mixture of SVG, TIFF, JPEG,
    and PNG created with an eclectic assortment of software). I had to
    give up on that too.

    3) I asked the folks on the fop mailing list. They think it may indeed
    be a fop bug, but they kindly provided a workaround which does the
    trick. I've added the following to my customization layer (taken from
    fo/autotoc.xsl):

    <xsl:template name="toc.line">
    <xsl:param name="toc-context" select="NOTANODE"/>

    <xsl:variable name="id">
    <xsl:call-template name="object.id"/>
    </xsl:variable>

    <xsl:variable name="label">
    <xsl:apply-templates select="." mode="label.markup"/>
    </xsl:variable>

    <fo:block xsl:use-attribute-sets="toc.line.properties">

    <fo:basic-link internal-destination="{$id}">
    <xsl:if test="$label != ''">
    <xsl:copy-of select="$label"/>
    <xsl:value-of select="$autotoc.label.separator"/>
    </xsl:if>
    <xsl:apply-templates select="." mode="titleabbrev.markup"/>
    </fo:basic-link>

    <xsl:text> </xsl:text>
    <fo:leader leader-pattern="dots"
    leader-pattern-width="3pt"
    leader-alignment="reference-area"
    keep-with-next.within-line="always"/>
    <xsl:text> </xsl:text>
    <fo:basic-link internal-destination="{$id}">
    <fo:page-number-citation ref-id="{$id}"/>
    </fo:basic-link>

    </fo:block>
    </xsl:template>

    The trick is to remove the fo:inline elements (I've commented them out
    so they're easier to spot for you).

    It is no big deal to do this in a customization layer. However, what
    is the purpose of these elements? Their presence does not seem to make
    any difference except that it breaks the page number alignment.

    regards,
    Markus

    --
    Markus Hoenicka
    http://www.mhoenicka.de
    AQ score 38



  • 9.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 07-30-2011 23:01
    On 7/30/2011 5:47 PM, markus.hoenicka@mhoenicka.de wrote:
    > 1) I gave dblatex a whirl. It took a while to install missing packages
    > from CTAN until dblatex ran at all. Eventually I got stuck when
    > (La)TeX told me that a glyph was missing from a font that it intended
    > to use. My document uses quite a few greek characters and other
    > symbols, but I wouldn't expect LaTeX to have a problem with that. As it
    > wasn't apparent to me how to move on from there, I had to give up.

    Sounds like you found another solution, but for the record:

    The easiest way to get all the LaTeX packages you might need to have
    installed is to install the latest "TeX Live" distro:
    http://www.tug.org/texlive/
    It's big, but compared to hard disks these days, no worries.

    As for the font issue: I'm not sure whether you were using LaTeX (8-bit
    pre-Unicode characters) or XeLaTeX (Unicode compliant version). (Both
    come in the Tex Live distro.) On the assumption that your XML was
    Unicode, you should have been using XeLaTeX. A good Unicode font (and
    it's nice looking, too) is the Charis SIL font:
    http://scripts.sil.org/CharisSILfont
    It includes regular, bold, italic, bold italic, small caps, tons of
    diacritics, IPA etc. It does not however cover Greek characters.

    I'm sure there are Unicode fonts that cover both Roman and Greek
    characters (Arial Unicode does, but is probably not what one would want
    for typesetting).

    The more general solution is to tag the non-Roman strings in XML (either
    manually or by a script), and create a small XSL transform that tags
    them for the font when converting to XeLaTeX. We do that for our
    grammars, which routinely mix in strings in Perso-Arabic scripts,
    Bengali script, etc. Or you could run a script over the XeLaTeX output
    by dblatex and font-tag the non-Roman strings directly.

    You might also want to use the Polyglossia package
    http://www.tex.ac.uk/ctan/macros/xetex/latex/polyglossia/
    to provide language-specific hyphenation, etc.

    And if someone wants help, there's a XeTeX mailing list:
    http://www.tug.org/mailman/listinfo/xetex
    --
    Mike Maxwell
    maxwell@umiacs.umd.edu
    "My definition of an interesting universe is
    one that has the capacity to study itself."
    --Stephen Eastmond



  • 10.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 08-01-2011 07:45
    Mike Maxwell <maxwell@umiacs.umd.edu> was heard to say:

    > The easiest way to get all the LaTeX packages you might need to have
    > installed is to install the latest "TeX Live" distro:
    > http://www.tug.org/texlive/
    > It's big, but compared to hard disks these days, no worries.
    >

    FreeBSD still has teTeX on board, although they may eventually drop
    support given that Thomas Esser no longer maintains the distro. teTeX
    has been good enough for me through the years as I mostly have used it
    for SGML/Passivetex processing once in a while. Moving to TeX Live
    would certainly make sense if I used TeX more often.

    > As for the font issue: I'm not sure whether you were using LaTeX
    > (8-bit pre-Unicode characters) or XeLaTeX (Unicode compliant
    > version). (Both come in the Tex Live distro.) On the assumption
    > that your XML was Unicode, you should have been using XeLaTeX. A
    > good Unicode font (and it's nice looking, too) is the Charis SIL font:
    > http://scripts.sil.org/CharisSILfont
    > It includes regular, bold, italic, bold italic, small caps, tons of
    > diacritics, IPA etc. It does not however cover Greek characters.
    >

    I assume that dblatex and/or teTeX do not have any provisions to
    handle UTF-8 encoded XML files automagically. This may be the point
    where my problems started.

    > I'm sure there are Unicode fonts that cover both Roman and Greek
    > characters (Arial Unicode does, but is probably not what one would
    > want for typesetting).
    >

    I'm currently using two non-Unicode fonts that still have all required
    glyphs. It required a bit of testing though, but many fonts actually
    have a full set of greek characters and those few symbols that my
    document uses.

    > The more general solution is to tag the non-Roman strings in XML
    > (either manually or by a script), and create a small XSL transform
    > that tags them for the font when converting to XeLaTeX. We do that
    > for our grammars, which routinely mix in strings in Perso-Arabic
    > scripts, Bengali script, etc. Or you could run a script over the
    > XeLaTeX output by dblatex and font-tag the non-Roman strings directly.
    >
    > You might also want to use the Polyglossia package
    > http://www.tex.ac.uk/ctan/macros/xetex/latex/polyglossia/
    > to provide language-specific hyphenation, etc.
    >
    > And if someone wants help, there's a XeTeX mailing list:
    > http://www.tug.org/mailman/listinfo/xetex

    Thanks for these explanations. Now I'm sure that dblatex would do the
    trick if I put enough effort in setting up things properly.

    best regards,
    Markus

    --
    Markus Hoenicka
    http://www.mhoenicka.de
    AQ score 38





  • 11.  Re: AW: [docbook-apps] ragged index with recent fop snapshots

    Posted 08-01-2011 13:36
    On 8/1/2011 3:45 AM, Markus Hoenicka wrote:
    > I assume that dblatex and/or teTeX do not have any provisions to handle
    > UTF-8 encoded XML files automagically. This may be the point where my
    > problems started.

    Dunno about teTeX, but dblatex is fine with UTF-8--we use it that way
    exclusively, and then use XeLaTeX (a Unicode-aware version of LaTeX) to
    process the resulting file.

    > I'm currently using two non-Unicode fonts that still have all required
    > glyphs. It required a bit of testing though, but many fonts actually
    > have a full set of greek characters and those few symbols that my
    > document uses.

    If you're using non-Unicode fonts, then you'll need LaTeX rather than
    XeLaTeX. I'm not sure how (or whether) dblatex handles the conversion
    in that case--it wouldn't be something a standard encoding converter
    could handle, because you'd have to convert the non-ASCII (or at least
    non-ISO) characters into some kind of LaTeX commands, I imagine. I've
    never tried that.
    --
    Mike Maxwell
    maxwell@umiacs.umd.edu
    "My definition of an interesting universe is
    one that has the capacity to study itself."
    --Stephen Eastmond