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

Implement a writer for HTML or PDF #1

Open
stockiNail opened this issue Feb 3, 2023 · 2 comments
Open

Implement a writer for HTML or PDF #1

stockiNail opened this issue Feb 3, 2023 · 2 comments

Comments

@stockiNail
Copy link

Currently there is only 1 writer, to markdown.

It could be helpful to have different writers, for instance for HTML or PDF.
Furthermore, this feature could also enable a writer for framework (i.e. VuePress, Docusaurus) , based on MD, which are creating a complete doc site to publish somewhere (i.e. GH pages).

It could be better that these "plugins" could be coded also in other programming languages.

@ggabbiani
Copy link
Owner

Ciao Stock,

the currently implemented extensions are just the ones I needed for a project of mine, but the design is extendible and I had in mind other plugins for both writer and language plugins. The html writer is a planned feature for the next release, c++ language is another of the things I'd like to implement ... eventually.

Support for plugin written in programming language other than C++

  • pros: quicker extension of writers by enlarging the number of frameworks potentially usable.
  • cons: new runtime dependencies to be managed in the project configuration and in the target platform

A quick and dirty solution is to just export the analytic document in json format, making it possible to write anything else from there. In this case OrthoDocs would be used only for the analytics. I don't like this approach because it complicates things for the final user but it could be implemented very quickly.

A more complete solution would be to move the extension mechanism from static to dynamic and to write a 'general' configurable extension able to trigger an external program after having produced the export of the analytic documents and conveniently transcoded the input parameters.

Does it make sense for you?

Cheers
Giampiero

@stockiNail
Copy link
Author

A more complete solution would be to move the extension mechanism from static to dynamic and to write a 'general' configurable extension able to trigger an external program after having produced the export of the analytic documents and conveniently transcoded the input parameters.

I think this makes a lot of sense.

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

No branches or pull requests

2 participants