search

Jason-S-Ross / ox-context

An Org Mode export backend for ConTeXt
13 stars 4 forks source link

table.el support #36

Open xeruf opened 2 years ago

xeruf commented 2 years ago

Is it possible to support table.el tables? Latex export is done via table-generate-source, maybe the resulting LaTeX can be translated?

Otherwise, any other hints on how to add a text-based table with colspans into ConTeXt?

Jason-S-Ross commented 2 years ago

Sorry, I'm not aware of any way to do this.

As far as potential implementation, it looks like the LaTeX exporter delegates the translation to table.el. It supports a few other formats including HTML, so it might be possible to translate the HTML to an XML flavor ConTeXt likes...? Maybe that could be done with some simple substitutions, but it depends on if the semantics of table.el are a subset of ConTeXt's xtable semantics.

Regardless, I don't think I'll have time to implement this in the near future. It looks like a pretty sizeable chunk of work.

xeruf commented 2 years ago

Pandoc to the rescue - maybe? Unfortunately colspan is just being implemented: https://github.com/jgm/pandoc/issues/1024

But theoretically it could go via HTML or LaTeX

Jason-S-Ross commented 2 years ago

I was thinking about Pandoc, but thanks for letting me know it's a dead end.

There's some examples of handling XML tables in ConTeXt, so I would think that's the best route to go down: tables.el -> export as html to temp buffer -> process the DOM with dom.el and perform substitutions -> wrap output in appropriate ConTeXt tags. The bulk of the work (at least for me) will be learning the models for ConTeXt tables and tables.el tables well enough to know how the elements should map onto each other.

xeruf commented 2 years ago

It is actually not a dead end - it works pretty well already. It is just that some special features need extra care - but it should be easier to contribute colspan to the pandoc ConTeXt writer than write our own translation ^^

Jason-S-Ross commented 2 years ago

My mistake. That might not be as bad as I thought. However, I don't know any Haskell...

xeruf commented 2 years ago

Haskell is a fantastic language. Maybe I will get to have a look at it myself. I really dislike if people reimplement the same functionality if it is perfectly modularily available already - because now you have multiple pieces of software with different bugs and features, rather than joining forces and ironing out one that does the job well for all kinds of cases. Which is why pandoc is such a great project.

Anyways, I guess the reason why we have so many specialized org-exporters rather than using pandoc everywhere lies in the special flags of org-mode that need to interpreted for optimum functionality. So a hybrid approach is needed.

Jason-S-Ross commented 2 years ago

The problem with getting really good Pandoc support for Org Mode is that it's a mode. There's more to how a document looks when it's exported than just the plain text. The user has their own hooks and configuration settings that should affect how the resulting file looks that are not part of the plain text, and there's no way for an external program to know about them. It makes modularity very difficult.

Maybe what is needed is an intermediate representation of Org documents where all the export hooks have been run and it's just an abstract representation of the document tree with all configuration and hooks applied (so I guess just Pandoc's JSON). This could serialize all user configuration data into the file, so there's a complete separation between the user's Emacs environment and the conversion of that file to an output format. However, I think we're too late to do this - too much work has gone into all the various modules and extensions that already work for anyone to bother implementing such a thing.

So that's part of why I lean towards reimplementing the functionality. The other reason is that adding more dependencies (and Pandoc is a BIG dependency) makes me sad.