Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

afrey
Hi!

@mojavelinux: you wrote 10 months ago in https://gitlab.com/antora/antora/issues/349 that:

Given I have spend a substantial amount of time trying alternatives, I've become a huge believer in the the HTML/CSS workflow
(...)
So you don't have to convince me that the days of Asciidoctor PDF are numbered and that we need a new strategy based on web tech.


As I'm currently investing in asciidoctor-pdf, I'm curious if this is still your opinion and if asciidoctor-pdf is a long-term solution.

Also, I find it very useful to have a pure JVM pipeline like asciidoctorj / asciidoctorj-pdf. Do you think a future ADOC->HTML+CSS->PDF pipeline will also be able to be JVM-based?

Best regards,
-- Alex
Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

mojavelinux
Administrator
Alex,

There's nothing stopping it from existing now. The converter is an extension point, so someone could implement that converter using whatever solution they want.

As for the future of Asciidoctor PDF, you're a step ahead of me. I'm going to explain the plans once 2.0.0 is released (which I'm doing my best to finalize). But to foreshadow, yes, we'll be exploring other avenues. And the upcoming AsciiDoc spec will further open the doors to what's possible on the JVM.

Best,

-Dan

On Mon, Oct 21, 2019 at 3:16 AM afrey [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hi!

@mojavelinux: you wrote 10 months ago in https://gitlab.com/antora/antora/issues/349 that:

Given I have spend a substantial amount of time trying alternatives, I've become a huge believer in the the HTML/CSS workflow
(...)
So you don't have to convince me that the days of Asciidoctor PDF are numbered and that we need a new strategy based on web tech.


As I'm currently investing in asciidoctor-pdf, I'm curious if this is still your opinion and if asciidoctor-pdf is a long-term solution.

Also, I find it very useful to have a pure JVM pipeline like asciidoctorj / asciidoctorj-pdf. Do you think a future ADOC->HTML+CSS->PDF pipeline will also be able to be JVM-based?

Best regards,
-- Alex


If you reply to this email, your message will be added to the discussion below:
https://discuss.asciidoctor.org/Future-of-asciidoctor-pdf-vs-ADOC-HTML-CSS-PDF-tp7263.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

habamax
In reply to this post by afrey
>> As I'm currently investing in asciidoctor-pdf, I'm curious if this is still your opinion and if asciidoctor-pdf is a long-term solution.

It would be really sad if current asciidoctor-pdf would/is not considered as a first class citizen in asciidoctor family.

Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

mojavelinux
Administrator
I will explain why we have to start looking at other strategies in the announcement. Just know that it's out of necessity. We've hit a hard limit and it's a reality we have to face. But let's not get ahead of ourselves. The focus right now is on stabilizing Asciidoctor PDF. It's not going to disappear. Otherwise, why would I be toiling over it so much?

-Dan

On Mon, Oct 21, 2019 at 3:37 AM habamax [via Asciidoctor :: Discussion] <[hidden email]> wrote:
>> As I'm currently investing in asciidoctor-pdf, I'm curious if this is still your opinion and if asciidoctor-pdf is a long-term solution.

It would be really sad if current asciidoctor-pdf would/is not considered as a first class citizen in asciidoctor family.




If you reply to this email, your message will be added to the discussion below:
https://discuss.asciidoctor.org/Future-of-asciidoctor-pdf-vs-ADOC-HTML-CSS-PDF-tp7263p7265.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

afrey
mojavelinux wrote
The focus right now is on stabilizing Asciidoctor PDF. It's not going to
disappear. Otherwise, why would I be toiling over it so much?
Thanks for the confirmation ! I'm looking forward to knowing more about your plans.

Don't get me wrong: I really love asciidoctorj-pdf: this is a wonderful piece of software.

I have found that using theming and a little bit of Ruby code, I was able to come very close to the standard look&feel of my company documents. As our projects are already gradle-based, the asciidoctor gradle plugin and the fact that it's all JVM-based allow zero-installation, run-everywhere, which simplifies a lot the adoption.

Best regards,
-- Alex






Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

habamax
In reply to this post by mojavelinux
mojavelinux wrote
I will explain why we have to start looking at other strategies in the
announcement. Just know that it's out of necessity. We've hit a hard limit
and it's a reality we have to face. But let's not get ahead of ourselves.
The focus right now is on stabilizing Asciidoctor PDF. It's not going to
disappear. Otherwise, why would I be toiling over it so much?

-Dan
No pressure from my side, I can understand the necessity.

The thing is -- that information was really unexpected, given how much hard work you are putting into current implementation (I do git pull upstream master && git log almost every morning and I can see it).

I just selfishly wish all my current setup (themes and cmd parameters to asciidoctor) would not be dramatically changed.
Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

habamax
habamax wrote
I just selfishly wish all my current setup (themes and cmd parameters to asciidoctor) would not be dramatically changed.
And looks like asciidoctorj -b pdf is a drop-in replacement for the ruby asciidoctor-pdf (which is awesome)
Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

habamax
My only "issue" I can see is a personal attitude to java :).

It would be harder for me to contribute if it is pure java sources.  But again, not a big deal, "I can do java" if needed.
Reply | Threaded
Open this post in threaded view
|

Re: Future of asciidoctor-pdf vs ADOC->HTML+CSS->PDF

mojavelinux
Administrator
In reply to this post by habamax
> that information was really unexpected

I've talking about it quite a bit over the last few months in the gitter channel and issue tracker.

> looks like asciidoctorj -b pdf is a drop-in replacement for the ruby asciidoctor-pdf

I don't think Alex's point was about AsciidoctorJ PDF. I think it was about whether the browser-based rendering part would work on the JVM (the HTML to PDF step). We'll have to take that into consideration. But we're not talking about switching away from Ruby. I never said that.

Best,

-Dan

On Mon, Oct 21, 2019 at 8:28 AM habamax [via Asciidoctor :: Discussion] <[hidden email]> wrote:
habamax wrote
I just selfishly wish all my current setup (themes and cmd parameters to asciidoctor) would not be dramatically changed.
And looks like asciidoctorj -b pdf is a drop-in replacement for the ruby asciidoctor-pdf (which is awesome)


If you reply to this email, your message will be added to the discussion below:
https://discuss.asciidoctor.org/Future-of-asciidoctor-pdf-vs-ADOC-HTML-CSS-PDF-tp7263p7270.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux