Due to productivity I write my notes in tbx usually in markdown text with images (if any) pasted into the note.
I’m wondering if there is a way to export the notes as a markdown file (.md) putting the image(s) in a separate folder (e.g. /img) and replacing the image in the markdown file with the path to the image (e.g. .
Any help appreciated!
HTML export can be rigged to do almost all of this — for example, by setting HTMLBoldStart/End to ** instead of and .
Tinderbox will still export the images as <img…> tags, but a very simple script can automatically clean that up.
Can you be more specific?
So far, I use ^value($Text)^ in the html export template to keep my text exported as markdown. But how can I handle the image export part?
That will not export (I just tested) images in $Text. Bear in mind that a note’s content is rich/styled text, even if you only type in Markdown code. But ^value($Text)^ finds and processes the plain text of the note that, of course, can’t include non-textual info like embedded images.
Alternatively, exporting ^text^ with $HTMLMarkdown set to true, the Markdown code in $Text is not turned into HTML but inline images are ignored (I tested in v9.7.1).
If you export using normal HTML export with ^text^with $HTMLMarkdown set to false, the embedded images export as <img... tags but the Markdown markup is not respected and # signs may e interpreted as the Tinderbox quickest markup for numbered lists.
I think your use needs feature request raised that makes the $HTMLMarkdown true mode export inline images using Markdown mark-up style.
TL;DR, I don’t think what you want is possible as at v9.7.1.
Actually, I did a video on this:
Yes, I watched your video. Thanks for sharing. Unfortunately, it does not deal with image export.
I was actually hoping there might be some export code where we have more control about images. But as Mark said this is probably a feature request.
Till then I need to work with external stored images. Its just slowing down my workflow as I copy and paste a lot of screenshots in tbx notes.
Ah, sorry, I missed that part of your need. Yes, controlling the export of controlled images is a challenge.
Another thing for us to consider is that it would be great if we could have Tinderbox recognize the Image height/with an extension with Markdown. Actually, it is not as much a Tinderbox issue but the choice of which markdown rendering engine to use. The default engines supported by TBX, commonMark and Markdown, don’t recognize these extensions, pandoc does. There really is no right or wrong answer. You just have to find the workflow that works fo you.
{height=150px}
^){height=^value($ImageHeight)^
With $HTMLMarkdown the notes Markdown is preserved but the inline export code is still evaluated.
I’ll clarify here, having had a question on the side.
Image file path. My code above presumes, Becker-style, that the location of the image may be task/project dependent, so we use an user String-type attribute $ImagePath. Alternatively, if not bothering with such dynamic path calculation we could use $File.
Image height. As images vary in size in makes sense no to hard-code the height (or width) so we read that from a user attribute (number or string type) $ImageHeight—and $ImageWidth if also setting width.
N.B. The setting of image (display) size in Markdown is dependent on the ‘flavour’ of Markdown in use, and not controlled by Tinderbox. Different flavours do this mark-up differently, some not at all. That part is left as an issue for the user to resolve having checked the flavour they have chosen.
@Dirk, during my morning meditation, your project popped into my head a few times. The inspiration I had is that I think you might want to consider a different approach to how you’re handling media in Tinderbox.
It is my hope that these ideas can inspire you and the rest of the community.
We reviewed much of this in today’s meetup (will get published by tomorrow). In the meetup, you’ll see I ran into a couple of snags near the end, most of which I’ve solved. The one item I’ve not solved is how to covert the HTML in an included image
Don’t store media (e.g., images, audio, video) that you may want to reuse outside of an individual note; keep the image on your hard drive.
For me, this is very important. There is nothing wrong with pasting an image into a note. However, when doing so, I find it difficult to reuse the VERY VALUABLE ASSET, i.e., the image, elsewhere, i.e., across the TBX file of focus, across all TBX files, let alone in any other app or project that I am working on now or in the future.
My approach is to have a media directory on my hard drive. In this Media directory, I have sub directories for various types so of files: images for prices, images, videos, and audio files. Or, I have a media file in the specific hierarch of a project-specific file. NOTE: I’ve toyed with storing these images in DEVONthink, but the DEVONthink file path makes it nearly impossible to source the image back into Tinderbox (this is not a TBX issue, but rather DEVONThink; i can explain this later if you’re interested)
Again, why do I do this? To maintain optimal flexibility and reusability of my media assets.
My assumption, working model, is that the media note, e.g., an image, is one that I will want to reuse across projects. Moreover, I may want to do many things with it: include it with full resolution, include it with partial resolution, include a short reference (e.g., Figure 1), include a long reference (e.g., Figure 1: Tinderbox Logo), automatically renumber the captions based on their position in the outline and where or to they’re in an appendix or not, suppress the title, add citations to the captions, dynamically change the path (sometimes I move or copy the media asset from my generic assets folder to a project-specific folder once the project gets big enough to warrant this or if it is client specific and I need to maintain a record of the media in both places (generic or client).
In other words, for my future self to have the most flexibility, I break everything down into its attributes. At a minimum, in my media prototype ($Prototype=“pMedia”), I have the following attributes:
$ShortTitle (string)
$Type (set)
$MediaPath (string)
$MediaDir (string)
$MediaFileName (string)
$MediaHeight (string)
$MediaWidth (string)
$CaptionPrefix (set)
$CaptionLabel (set)
$CaptionNo (string)
$Caption (string)
$CrossRefShort (string)
$CrossRefLong (string)
$MediaPrefix (set)
$CaptionNote (string)
$CitationKey (string)
$Attribution (set)
$URL (URL)
$IsNoShowText (boolean)
$IsNotShowTitle (boolean)
$IsNoShowChild (boolean)
I maintain a TBXConfig file that holds the defaults to the genetic assets $MediaPath and $MediaDir on my hard drive; in my template, I have every note use these global values unless I override the local on an individual note.
Note: I won’t get into it here, but my media prototype enables me to be dynamic with all types of media, images, audio, and video (local or embedded from different providers). For now, I’ll stick to images; we can discuss the other media type handling later.
Now that my media is on a separate note, there are tons of things I can do. I can include them in the hierarchy of an outline and have them placed exactly where I want when I export. I can use '^incude()^ to insert them inline within a note $Text. I can $Cross reference them using ^include()^ across note $Text, and so much more. Also, I can output everything in HTML, Word, Markdown, or whatever output format I want.
Let’s stick with outputting to Markdown for this example.
I won’t explain all that I do here, but here is the high-level. I’ve been a lot of affordances for myself with the use of booleans. These allow me to suppress $Name, $Text, $Children, and other elements when exporting. Also, I’ve created an autonumbering scheme so that the root of a report starts at the selected note, and then headings cascade down from this root, rather than everything having to start from the root of the TBX file. These and several other treatments I use create a ton of flexibility, but we won’t go into this now. For now, let’s assume we have a single project at root. I’ve included some of the boolean ideas in the sample file here, but not the other ones.
TBX L - Markdown Text and Image Export.tbx (577.7 KB)
Note: there are ways to deal with the whitespace in the export. Also, I’ve tried to create a template that lets you process any export code you have in a note’s text and keep the output as pure markdown. It works up to a point. I ran into a snag where I needed to reformat a processed image. Right now, as you’ll see in the demo, in the case of an include in text, the image is HTML formatted and not markdown formatted. I don’t have the time today to resolve this bit. I will require some post-processing replacements.
I don’t have time today to go over this. But, if you need to move or copy the images from a general directory to a specific project directory, I’ve developed some command line scripts to do this.
Actually, the problem is not inserting the value. The problems that commonMark or Markdown don’t recognize {width= } or {heigh= } extensions, while pandoc does. In other words, not all markdown rendering tools are the same.
Too many machinations. Pandoc is overly complicated.
I use Fletcher Penney’s MultiMarkdown which supports height and width attributes. (See MultiMarkdown syntax.)
The parser software can be downloaded at the above link, installed at
'/usr/local/Cellar/multimarkdown/6.7.0/bin/multimarkdown'
and invoked in Tinderbox as
I have a default personal prototype for MultiMarkdown that I use rather than the built-in CommonMark $HTMLPreviewCommand.
Yup, great options. I use Markdown in several places too. I don’t disagree that pandoc has a lot of overhead, but it does service several good purposes if you need them. If you don’t, as you point out, there are alternatives.
since most markdown engines out there support HTML - I use:
<img src="^value($MediaFileName)^" alt="^value($Name)^" style="vertical-align: top; margin-top: 5px;" width="300px">
If I need to specify attributes of the exported image element.
You are right, many engines are flexible, but I interpreted the original ask as having pure markdown, not a mix of HTML and markdown, so that is what I was going for. When the rubber his the road, however, I to have found a hybrid approach to provide the most flexibility.
