Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output to HTML string omit header / footer #502

Closed
sschuberth opened this issue Aug 19, 2016 · 8 comments
Closed

Output to HTML string omit header / footer #502

sschuberth opened this issue Aug 19, 2016 · 8 comments

Comments

@sschuberth
Copy link
Contributor

I'm using AsciidoctorJ 1.5.4.1 and recently switched from calling convertFile with

OptionsBuilder.options()
  .backend(backend)
  .docType(DOCTYPE)
  .eruby(ERUBY)
  .safe(SafeMode.UNSAFE)
  .baseDir(basedir)
  .toFile(outFile);

to calling it with

...
  .toFile(false);

I.e. I simply switch to outputting to a String instead an output file. While investigating the HTML output String I noticed it lack the HTML header / footer, meaning there is no <!DOCTYPE html> and <head></head> tag in there, and no <div id="footer-text"> etc. in the end. I don"t believe this is expected as I did not see that behavior documented anywhere.

@robertpanzer
Copy link
Member

Did you try setting headerFooter(true) ?

Am 19.08.2016 um 16:38 schrieb Sebastian Schuberth notifications@github.com:

I'm using AsciidoctorJ 1.5.4.1 and recently switched from calling convertFile with

OptionsBuilder.options()
.backend(backend)
.docType(DOCTYPE)
.eruby(ERUBY)
.safe(SafeMode.UNSAFE)
.baseDir(basedir)
.toFile(outFile);
to calling it with

...
.toFile(false);
I.e. I simply switch to outputting to a String instead an output file. While investigating the HTML output String I noticed it lack the HTML header / footer, meaning there is no and tag in there, and no

@sschuberth
Copy link
Contributor Author

Thanks, setting headerFooter(true) explicitly indeed works, but the point is that from reading the docs I would have have expected this to be necessary when just switching from file to string output.

@robertpanzer
Copy link
Member

I think these are sensible defaults for the different functions:
When converting to a string the primary use case would be imo to embed this result somewhere.
When converting to a file a full, self-contained document should be created.
Therefore it makes sense to me that the default for headerFooter changes with toFile true/false.
Does that make sense to you as well?

Please note that this behavior originates from Asciidoctor core and is not a special change in AsciidoctorJ: https://github.com/asciidoctor/asciidoctor/blob/master/lib/asciidoctor.rb#L1443

Cheers
Robert

@sschuberth
Copy link
Contributor Author

I was assuming this to be the rationale. However, in my use case I wanted to post-process the output file, and instead of reading its contents back into a string to do so, I wanted to use an output string directly, and was confused by the output not being the same when writing to a file.

While I do not disagree to the current behavior per se, I do think it at least deserves some documentation, also on the AsciidoctorJ side.

@robertpanzer
Copy link
Member

We're happily accepting Pull Requests:)

Am Freitag, 19. August 2016 schrieb Sebastian Schuberth :

I was assuming this to be the rationale. However, in my use case I wanted
to post-process the output file, and instead of reading its contents back
into a string to do so, I wanted to use an output string directly, and was
confused by the output not being the same when writing to a file.

While I do not disagree to the current behavior per se, I do think it at
least deserves some documentation, also on the AsciidoctorJ side.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#502 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHBjre8V4fYahn_8hAsXtZDioZmeg6Dks5qhcjpgaJpZM4JoiUK
.

@mojavelinux
Copy link
Member

Just to followup, @sschuberth has submitted the following PR to clarify the API documentation. #503

@sschuberth
Copy link
Contributor Author

@mojavelinux That's why I've linked my PR via a commit message to this issue ...

@mojavelinux
Copy link
Member

Thanks. I added the comment because GitHub doesn't send that link out via e-mail. To someone observing via e-mail it looks like the thread just dies, so I follow the practice of adding a wrap-up comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants