Very interesting. I wondered if anyone would take this further - glad to see it happen. I'd agree on Graphviz vs. Omnigraffle. Indeed, I see Graphviz can export DOT. I've not tried but I suspect it might 'tidy' our learner DOT into something cleaner as it is reversing the graph as rendered to DOT regardless of the original source being DOT (worth a try!). Of course, OG offers scope for prettifying the final output.
Re your points...
1. Doing inline substitution via a command line in $HTMLExportCommand is not a big deal. My early demo didn't include that. The < > idea is neat but reviewing the docs you're using the HTML form of annotation (of which there are no clear examples) and that form should be XML compliant so you should either hard code < vice <, > vice > and & vice & or choose an action/export function that does that for you. Otherwise, as you scale your test to production level data unexpected things may happen. Pending TB offering support for format allowing both ' and " as
format() delimiters (don't know if it will) then a simple
tr or
sed call in $HTMLExportCommand should yield clean DOT data.
2. Yes,
much better! I was intending something like that but my test got bogged down in the mere basics. This label approach is much better. Don't bother with manually set note identity strings (too much for real would use!). Instead, make a sequential number user attribute. This will give all notes/agents/adornments including pre-existing ones a discrete number value. As at v5.0.2, aliases are an exception to this as sequential numbers aren't intrinsic; the issue has been raised though**.
3. Actually my digraph 'wapper' isn't so different from yours. the extra node/edge definition are effectively prototype info. It's the look nodes/edges will use unless altered at sub-graph or object level by further code.
4. I'm 99% certain this issue is the 'BOM' added to HTML export files as from v5.0.2 (and likely to go away again in subsequent releases***). My understanding is the Text Export shouldn't really use includes (due to the way Nakakoji view works) so I'd recommend sticking with HTML Ex[port for now. When your file is output, simply open in BBEdit or the like and check the file is UTF=8 with no BOM. If not, change to that mode and save; that
should solve the issue until BOM-less export returns.
5. Exporting list of links by type. you need to (manually, I'm afraid) tease out this:
$LinksOut=links().outbound..$NoteID;
to
$LinksOut1=links().outbound.agree.$NoteID;
$LinksOut2=links().outbound.disagree.$NoteID;
$LinksOut3=links().outbound."some label".$NoteID;
etc.
TB has no arrays or loops so you can't iterate all link type or an array of some link type names. Basically, you need one 'links out' construction per desired link type (a pain if you've lots!) then either
- simply include each them in your note template, perhaps in a if() clause so the data's only written if the attribute holds any value
- concatenate all the links data to one attribute and then call that in the template.
The former method may be better as it offer finer control. Also, in your digraph 'root' template - or in an include to it, predefine the look of each link type (bold, dotted, label, etc.) and remember to alter the individual link -> statements to indicate the correct link type for DOT to draw.
Quote:if Tinderbox had a feature to access the link label text
Indeed, this would offer a different approach. I sense the need is niche - in terms of engineering effort vs. the number of active users of the feature - so the above is the way to go for now. Of course, by all means make a feature request.
~~~~~~~~~~~~
** The answer is not necessarily as simple as giving an alias a discrete value. Aliases get created and deleted a lot, so using up sequential numbers are a massively faster rate than ordinary note creation. Anyway, if this issue affects your use, I'd suggest dropping a line directly to support explaining your problem/needs. It's probably a bit niche to warrant forum discussion.
*** BOM = Byte Order Marker. In theory a good thing and designed to help BOM-aware apps to get the correct encoding of a file. However, it seems real-world development took a different path and BOMs do more harm than good - for instance they make most HTML pages fail any common validation test. On balance, BOMs haven't helped and I believe will likely get dropped in the next release. Again, if people have particular desires in this context, email TB support direct outlining your issues (it's very techie stuff most users don't need to see/understand).