Process linebreaks and rules for xhtml

[ShadowKyogre]

I'm not sure why the rules for br and hr are missing from the xhtml xsl file. Any input on this would be appreciated.

[elextr]

Probably because its missing by accident and hasn't been noticed because 1) most users generate xhtml by asciidoc itself and/or 2) those using the toolchain don't use hard breaks or horizontal rules

[ShadowKyogre]

Aaah, oki. I mainly use the xhtml generation (along with some python scripting to inline the css) for making *.odts and *.rtfs. (<- which by far, is more reliable for me atm to produce such files)

[ShadowKyogre]

Commenting on this because I was wondering if I needed to do anything else with it before it's merged.

[ShadowKyogre]

Phone accidentally clicked on close, sorry about that.

[elextr]

Two things

1. checks are failing
2. somebody other than the PR author needs to determine which toolchains and which output formats it affects (eg does it affect epub?) and test them all

[ShadowKyogre]

@ p1: Understandable. The test failed here (python 2.6 only failure due to python syntax I didn't touch): https://travis-ci.org/asciidoc/asciidoc/jobs/130333555#L32 . I'll close and reopen again to run the test again when that's fixed since it's outside the domain of this PR

@ p2: Also understandable.

[ShadowKyogre]

That or I prolly need to rebase against master again.

Hm... the line it's complaining about is present in master too: https://github.com/asciidoc/asciidoc/blob/master/filters/latex/latex2img.py#L227

That's odd. I'll reclose and open one more time to see if it's consistently happening.

EDIT: Checks passed this time. Peculiar.

[elextr]

All the Python 2.6 checks on all PRs (well the ones I checked anyway) seem to be complaining about that line, but it doesn't seem to make them fail. You must have just been (un)lucky :)

[Minoru]

most users generate xhtml by asciidoc itself

Can someone elaborate on this? I thought that meant doing

$ asciidoc -b docbook input.txt
$ xsltproc --nonet /etc/asciidoc/docbook-xsl/xhtml.xsl input.xml > output.html

instead of

$ a2x -f xhtml input.txt

but obviously both will use the same XSL and result in the same HTML. (I actually checked—it is indeed so.)

somebody other than the PR author needs to determine which toolchains and which output formats it affects (eg does it affect epub?) and test them all

Grepping for xhtml.xsl shows that noone includes it, so editing the file shouldn't affect any output formats other than xhtml. Not sure what's meant by "toolchains" here (I'm an AsciiDoc newbie.)

[elextr]

Can someone elaborate on this? I thought that meant doing

asciidoc -b xhtml11 file.txt
asciidoc file.txt

generate xhtml from ASCIIDOC directly, no toolchain needed.

Grepping for xhtml.xsl shows that noone includes it,

Thats because its the top level .xsl, it includes the others, and just to fool ya a2x generates its filename programatically so it doesn't appear there either. 😁

[aerostitch]

@ShadowKyogre It seems this repo will no longer accept PR as the latest release has been cut a while ago but https://github.com/asciidoc/asciidoc-py3 would.
If you still want this PR integrated in asciidoc, do you mind pushing it there please?
Once done I think you can close this one.
Thanks!