Note-to-note links for Adornments

Very helpful, as always, Mark.

Thanks for taking the time to articulate these tips, explanations, perspectives, and cautions. They will surely help me in my future image insertions (and also help me have patience when I find it’s not working as I assume it should).

1 Like

[on re-reading my last, it might appear as if I was critiquing @beck’s input here. Suffice it to say, far from it!]

Part of the reason for explaining the status quo, and its possible quirks, is in case someone wants to make a feature request here; not me, as this isn’t my need and new features are best advocated by those with the need.

Although there are indeed some steps involved in importing pictures to notes, I think streamlining this much further potentially drags the app into image processing and presentation issues which seem a bit non-core to its central design premise of noting/hypertext/analysis and with ROI implications.

However, I did test if I could make a note title ($NameColor) invisible/transparent only to find that the attribute doesn’t support the ‘transparent’ special colour. This isn’t entirely surprising. Existing notions of note transparency were added towards a different purpose.

Here, with a ‘image note’, there is—for me—merit in allowing the user the option of a transparent title in map view. This avoids having title-less notes, which whilst possible and allowed are a gateway to problems of addressability in things like action code. With note’s where a start-of-$Text image acts as the note fill, the note title is always seen in the text pane when selected so isn’t, at the users choice, always needed as a visual label in map view.

ISTM allowing $NameColor to support the ‘transparent’ built-in colour would fix the latter issue. I think adding a build-in ‘picture note’ prototype is probably overkill. The prototype really only involves two attributes (as I covered in my last post) plus perhaps $NameColor is the suggested change is made. That’s sufficiently little configuration work that I wonder if it warrants a built-in prototype.

As regards image size/format, I think if the source app/process isn’t making the ‘right’ sort of image, then work flow should be expanded to source → image editor → Tinderbox. Or, check if the source app as any settings to control the nature and format of image data it places on the clipboard.

One last point re vector-vs.-bitmap images. It is true that vector images may give background transparency, but PNG bitmap images also do so. The format you get is essentially down to the way you the user generate the image and the context/app in which you do so.

Note to self, I think my aTbRef notes are wrong re images in $Text as some vector formats , eg.g PDF, are supported. When I’ve figured out the correct answer I’ll update those notes.

I hope that’s helped with a few of the wrinkles arising from @beck’s really interesting explanation of her workflow, for other seeking to borrow from it.