On 27 October 2017 at 10:34, Shep <[email protected]> wrote:
> Fair point!
>
> Here are my build commands:
>
> a2x -fpdf -dbook book.txt
>
> a2x -fepub -dbook book.txt
>
> a2x -fxhtml -dbook book.txt
>
> For simple line-break, I get different results. That is “ + “ at the end of a
> line in book.txt results in line breaks for epub and xhtml, but not pdf
> (which uses dblatex).
I can confirm that the page break + works for PDF using FOP and
asciidoc generates the same docbook for dblatex.
I don't have dblatex since I can't install 1Gb of Texlive to support
it. If you run a2x with -k the docbook xml will be left and you can
check the <?asciidoc-br?> instruction is present in the required
places. If they are not you will need to post a *small* source that
shows the problem.
If the docbook is ok you can run a2x with -v you will see the dblatex
command which should look like:
"dblatex" -t pdf -p "/path/to/asciidoc/dblatex/asciidoc-dblatex.xsl"
-s "/path/to/asciidoc/dblatex/asciidoc-dblatex.sty" -V
"/tmp/untitled.xml"
You can check the .xsl and .sty files exist and the .xsl contains the
instructions to convert the <?asciidoc-br?> instructions to latex.
<xsl:template match="processing-instruction('asciidoc-br')">
<xsl:text>\newline </xsl:text>
</xsl:template>
You may be able to pass an option to dblatex using --dblatex-opts to
have it leave the latex file so you can check that they are added to
it (or not removed since I understand dblatex does some hacking of its
own on the latex file as well as the xsl).
Another alternative is to try the newer asciidoctor implementation of
Asciidoc which (as well as using docbook toolchains) has its own
(currently still experimental) internal PDF generation. Asciidoctor
is also a more actively developed project so I expect the PDF
generator to improve progressively.
>
> This, to me at least, seems inconsistent for basic asciidoc markup. I’m still
> getting used to the asciidoc toolchain approach, which I think provides a
> good deal of flexibility. I’m just surprised to get different results for
> something as basic as line-break. And my worry is that as my project
> progresses I will spend more and more time on back-end rendering issues, and
> less and less time on writing — the opposite of what I was hoping for.
Well, asciidoc(tor) does not do much about rendering as you have
understood, if things render differently its because the particular
backend toolchain has decided to do that for some reason (eg for page
layout purposes with PDF that don't apply to HTML). IIRC there are
HTML to PDF converters that should render PDF exactly like the HTML,
but (at least when I last looked at them) the results are plug ugly
because HTML rendering rules don't map well to page based media.
Cheers
Lex
>
> — Shep
>
> --
> You received this message because you are subscribed to the Google Groups
> "asciidoc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/asciidoc.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/asciidoc.
For more options, visit https://groups.google.com/d/optout.
