Exporting as LaTeX: HTMLEntities, <li> items

Hi there,

I’m super new to Tinderbox, so I apologize in advance if I’m missing something obvious.

I have a set of notes I would like to export as a LaTeX document. Two unexpected things happen in my output:

  1. Some unicode characters are escaped. For example, a “—” (in the text area or in the title) turns into &#x2014;. (LaTeX processing fails because of that.) $HTMLEntities is set to false throughout, as far as I can see.
  2. Lists and list items, inserted with Format > Text > List…, get exported inside a blockquote, and not in a ol/li structure. That prevents me from mapping them to a \(begin|end){enumerate}/\item template.

Could someone maybe give me some hint? Thank you very much!

LaTeX gets rendered outside Tinderbox – usually from a plain text file – so you might consider using the “Code” prototype for your notes inside Tinderbox, to ensure that there are no extraneous rich-text encodings in the content. Do not use HTML tags in your notes. Then use File > Export > as Text and save the document with a .tex extension.

(There are other approaches – but the basic idea is to produce the plain text export.)

Thank you, Paul! I believe I did not give enough context in my original post. I’ll try again.

I’m working on a complex software project for a client. I have a dedicated Tinderbox file for it. It contains many different types of notes: to-d0s, meeting notes, agendas, minutes, use cases, stakeholders, you name it. Most of those notes will eventually grow a fitting prototype.

I’d like to be able to export some of those notes as PDFs, via LaTeX, using the template-based export functionality. In that sense, I’m not using Tinderbox as a LaTeX editor. I believe your suggestion of using the “Code” prototype is based on that assumption—but again, I’m very lost right now, and it’s also likely that I’m simply not understanding anything at all.

So, my templates are taking care of that, and they have already produced some nicely formatted PDFs.

But—sometimes, and I just realized that not always, a typographic quote or a long dash are being escaped, which prevents further LaTeX processing.

And I would also like that Tinderbox’s native formatting, such as emphases and lists, translate into their LaTeX counterparts. This does not happen when it comes to lists: they are confused with HTML blockquotes and therefore wrapped inside \begin{quote} and \end{quote}.

I hope my problem is a bit clearer now. If your reply still applies, then I apologize for not having understood it properly.

Thanks a lot!

For clarity, if you could post a small sample file that both demonstrates what you are trying to do, and also reproduces the issues you mentioned, then others can help better. We can imagine what you are trying to do but we cannot see it.

If a sample is not feasible, then you’ll be better served sending your document to Eastgate support via email for a private look – to avoid the back-and-forth dithering that occurs in forums and doesn’t quickly resolve complex issues.

Did you try using the prototype. Sometimes actually using a method is easier than trying to imagine how it might work. The ‘Code’ prototype was a pragmatic feature added specifically for those users doing tasks like this where you don’t want Tinderbox’s export to do it’s usual (default) behaviour of assuming you want the export as HTML**. I suggesting also looking at this and this as I think it may help align your intuited assumptions about export with Tinderbox’s design intent. Tinderbox’s export is very powerful but apart for simple text or web export, the user defines all aspects of the export. This works against an assumption we all tend to acquire from use of utility-type apps where export is pre-configured by the app, though usually at lost of flexibility.

** Back in 2001 when the app was conceived, exporting a blog was one of the primary design intents of the app.

Also, if you’ve not seen it, you might find my note on LaTeX export of use. Indeed the term ‘LaTeX export’ is somewhat diffuse as there are so many possible steps to the final rendered output. (The latter point is informed by regular use of LaTex for academic paper writing).

$HTMLEntities controls translation of non-ASCII characters into entities.

On lists: use quick lists (paragraphs beginning with • or *) to describe lists in your text, not wysiwyg markup. Use $HTMLListStart/End and $HTNLListItemStart/End to define our markup elements.

Thank you all for your suggestions! Most of it seems to be working fine now. It turns out I had $HTMLEntities set to true for some notes, but it took me a while to discover. And @eastgate’s non-WYSIWYG-list tip is exactly what I was looking for.

A little detail remains. Even in notes with $HTMLEntities set to false, unicode characters are still escaped when referencing their ^title^ in a template. Is there a sort of $HTMLEntities for titles?

Thanks once more.

Note text is sourced from $Text. The note title comes from $Name. To insert a ‘plain’ title replace:

^title^

with

^value($Name)^

Creation of HTML entities has essentially become moot for most cases since the general adoption of UTF=-8 encoding of web pages and, since v6.0, Tinderbox’s export encodes text as UTF-8. Unlike with $Text having ^text^ and ^text(plain)^ export codes, there is no similar ‘plain’ option for $Name and ^title^.

Thanks, Mark. Sadly, also when using ^value($Name)^, there is some sort of transformation going on. A “Jörg” in a title turns into J&#xf6;rg.

I can’t replicate that. Can you post a small TBX (or link to one) that reproduces the issue on your Mac so we can test from a common baseline. There may be other factors at play here, though I’m not sure what.

My test. the source note:
tbx%202018-11-12%2013-11-22

The preview:
tbx%202018-11-12%2013-11-57

The HTML:

tbx%202018-11-12%2013-12-41

In this the top line uses ^title^ and the bottom ^value($Name)^

N.B. In the above $HTMLEntities is true (the default) and thus the entity in the output from ^title^

I do wonder if your template code is the issue…

Hey @mwra, thanks so much. It all renders correctly now—I’m not sure exactly what fixed it, but I believe the cause was an accidentally overridden HTMLEntities somewhere along the inheritance chain. So: mea culpa.

Many thanks to everyone!

1 Like