4

I have some files which contains data with ConTeXt syntax, e.g. containing macros and instructions for special symbols, but no preamble, sections, or other features tying the data to any particular place on a page. I need to compile these files, but instead of creating a PDF, simply convert the files to a UTF-8 text file.

E.g., a file might contain the following data:

\quotation{Do you want to go to the caf\acutee?}
\quotation{No, it costs 30\percent more than it did before.}

After compiling it with ConTeXt, it is converted to this:

"Do you want to go to the café?"
"No, it costs 30% more than it did before."

Is there any way I can compile these files using ConTeXt, but output to a UTF-8 text file?

4
  • I think we need to know a bit more about the 'text file' you want. For example, how should math mode material be handled, what happens about sectioning (MarkDown, HTML, something else?).
    – Joseph Wright
    Aug 18, 2012 at 9:12
  • I think the easiest way is to use context to get a pdf, and then some kind of pdftotext tool.
    – JLDiaz
    Aug 18, 2012 at 11:06
  • Does pdftotext convert the PDF to text without adding line breaks to the end of each line as happens if I copy and paste text from a PDF?
    – Village
    Aug 19, 2012 at 10:15
  • pdftotext adds line breaks, does not discard page numbers, does discard formatting, and is not what you need here. I don't know of any PDF-to-text tools that do maintain formatting, so focussing on the ConTeXt backend is your best bet for sure.
    – Esteis
    Aug 19, 2012 at 11:23

1 Answer 1

5

ConTeXt does have switchable backends built into its architecture, but the backend you want doesn't exist yet. There is an XML backend, whose output you may want to plug into an XML-to-text converter; or you may want to write your own backend. Either way, I don't know enough to help you any further.

If you want to know more about writing backends, send an e-mail to the mailing list at [email protected]. The developers actively participate there, and your question is sure to interest them. At least you should be able to discover if it's within your abilities.

Oh, and like Joseph Wright says, you'll need to think about your requirements. Do you want paginated output? How will you handle footnotes and cross-references? Where do floats go? What about paragraphs in table cells? In short: how many features do you want to translate?


Answer ends above; below are some facts about backends

ConTeXt keeps it backends in back-*.*. Current files:

back-ini.mkiv, back-ini.lua    # Initialization
back-exp.mkiv, back-exp.lua    # XML export
back-pdf.mkiv, back-pdf.lua    # PDF
back-swf.mkiv                  # Shockwave experiment (for *inclusion* in PDFs?)
back-u3d.mkiv                  # U3D experiment (3D graphics) (for inclusion?)

From the start of back-ini.mkiv:

Right from the start ConTeXt had a backend system based on runtime pluggable code. As most backend issues involved specials and since postprocessors had not that much in common, we ended up with a system where we could switch backend as well as output code for multiple backends at the same time.

Because LuaTeX has the backend built in, and since some backend issues have been moved to the frontend I decided to provide new backend code for MkIV, starting with what was actually used.

At this moment .dvi is no longer used for advanced document output and we therefore dropped support for this format. Future versions might support more backends again, but this has a low priority.

The big question is: what is to be considered a backend issue and what not. For the moment we treat image inclusion, object reuse, position tracking and color as frontend issues, if only because we deal with them via Lua code and as such we don't depend too much on macro calls that need to inject code for the backend.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .