All notes that are pulled into TBX from my “watch” folder on Devonthink have the note text font set to Helvetica. I want to change the default font, and have tried to do so in the “Imported from Devonthink” prototype, but seem unable to do so. Advice?
What attribute are you setting? My notes on DEVONthink here and here would suggest the watch-created note would use the current TextFont document default as set in the documents Document Settings. If you’ve been tinkering with text styles in an existing note, you may need to use the Style menu.
Hopefully some seasoned users who use this feature can chip in with a more experienced take on it.
I have just dragged some references from Bookends to Tinderbox, and I note that the text in the note is also defaulting to Helvetica in this case, despite my document settings being unaltered from the standard. It also seems that dragging a picture into a note has the same effect of setting the font to Helvetica. This is mildly annoying as I detest Helvetica as a screen font, but I can no doubt find a way to change it!
Out of interest what is the font of the DEVONthink source material?
This sounds like something getting lost in translation between DEVONthink and Tinderbox so may need to get raised with support rather than here. I doesn’t feel like an overlooked setting. No time to test as I’m just off to Hypertext 2002 for a few days (albeit virtually).
In my experience the font that documents have in DEVONthink has nothing to do with the font that Tinderbox uses to display the document contents. Tinderbox usually uses the same, monospace, font regardless of what DEVONthink uses. Also, DEVONthink documents may be rich text, plain text, PDFs, images, etc., in an unpredictable variety. So I suspect there is nothing that DEVONthink support can do about this issue – no harm asking them, of course.
@mwra - DT source font is a serif - Charter.
I can change individual notes in TBX with the Style menu, but the “Imported from Devonthink” prototype seems impervious to change. The prototype’s TextFont is set to Charter (which I’d like to use in TBX as well, for the sake of consistency), but imported notes all appear in Helvetica. I’m with @MartinBoycott-Brown on Helvetica’s utility as a screen font …
Ah - are the notes read only (see $ReadOnly)? I think some of the watch folders/groups do this (I don’t happen to use these features much in my own work). I vaguely recall the idea was that if you wanted to edit the watched not you’d move it elsewhere as the note in the watch container shows you the content of the watched asset.
The watch mechanism isn’t a two-way sync (or merge).
Yes, they are $ReadOnly by default.
Tried turning off the ReadOnly attribute in the “imported from Devonthink” prototype, setting the protoype’s TextFont to Charter, and then re-checking the $ReadOnly attribute. But imported notes still use Helvetica.
Yes, I do move all notes out of the Watched container, and I can then change the TextFont. It’s not a great hassle, but it just seems an anomaly for imported notes to be bound to a certain font that doesn’t occur anywhere else in TBX.
I wistfully hope for a robust two-way sync between TBX and Devonthink that allows edits in one piece of software to be mirrored in another. DT serves as my collection, storage and archive environment, TBX as my thinking environment, and having the two work in concert would make a perfect marriage. Right now they just have “friends with benefits” relationship, which is fine but not as ideal as it might be for raising a family of notes.
(I may have just strained that metaphor to the point of injury)
Beyond that, I’m not sure how best to handle the False Consensus Effect surrounding this. Given that the app can’t control we users’ initial inuition, where do we expect to look to find the information that clealy isn’t being easily found.
Tinderbox’s style is not to slam the user with modal warnings/conformations. But, perhaps users of the various ‘watch’ feature do need a warning of some sort by way of expectation management and assumption alignment?
I’m not suggesting anyone’s views are ‘wrong’ but looking for the best way to reduce the number of people coming here to report the feature (despite documentation otherwise) not working as they intuited? My question is quite genuine. I don’t know the answer but would like to find one.
In my ‘Admin’ hat, I’m closing this thread since repeated comments will not uncover new information and the core issue of the thread has run its course. Forum users can always start a fresh thread is the issue needs re-visiting or take detailed functional issue to tech support (as we users can’t fiddle under the hood of the app).