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 other than HTML? #3

Open
NobbZ opened this issue Sep 22, 2017 · 7 comments
Open

Output other than HTML? #3

NobbZ opened this issue Sep 22, 2017 · 7 comments

Comments

@NobbZ
Copy link

NobbZ commented Sep 22, 2017

Is there currently a way to put out something else than HTML? Or is there at least an easy to hook into @behaviour to write “output filters”?

I'd be very interested in trying to provide some LaTeX printer if it is currently missing.

@tmbb
Copy link
Collaborator

tmbb commented Sep 22, 2017

It is undocumented but yes, there is. Formatters aren't behaviours yet, but I'll turn them into formal behaviours in the future.

Basically, a formatter converts a flat list of tokens into a string. For the HTML formatter, that string is HTML. You can write a formatter that converts the tokens into LaTeX with no problem.

My main problem here is a design one: I'm still not sure of whether there should be a very unified interface to all formaters, or if each formatter should work in a unique way.

@tmbb
Copy link
Collaborator

tmbb commented Sep 22, 2017

Actually, a behaviour might be overkill. I'm planning on formally making the token format part of the public API, and use the metadata for possible extensions, so you should be able to weite your own formatter just by processing these tokens (which are very simple).

@tmbb
Copy link
Collaborator

tmbb commented May 9, 2018

@NobbZ, let's open the discussion around whether the formatter should be a behaviour or not.

The HTML formatter currently supports two output functions, one that outluts iolists and anothe that outputs binaries. This output format should be common to all formatters that produce textual output (as opposed to calls to a stateful graphics API for example).

Do you think I should formalize this as a behaviour?

@OvermindDL1
Copy link

Well a binary is an iolist but not vice-versa, so iolists should be the output (especially since you can then just convert it to a binary anyway if necessary, or feed it straight to a network socket or so).

But otherwise unless the system itself needs the formatters and not the other way around, a behaviour itself is not needed, just a good API for accessing the tokens.

@tmbb
Copy link
Collaborator

tmbb commented May 9, 2018

Well a binary is an iolist but not vice-versa, so iolists should be the output

The function that outouts a binary just renders the iolist returned by the other function into a binary.

a behaviour itself is not needed, just a good API for accessing the tokens.

A token is just a {atom(), Map.t(), iodata()}. There isn't really much of an API xD

@OvermindDL1
Copy link

The function that outouts a binary just renders the iolist returned by the other function into a binary.

You don't always want that though as keeping it as an iolist can often be faster, so it is a good base. :-)

@tmbb
Copy link
Collaborator

tmbb commented May 9, 2018

They's why there are TWO funcions: one if you want an iolist and another one if tou want a binary

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

3 participants