Table Cell Formatting Bug ?

Either I’m doing something wrong, or table cell formatting in DT has a bug…

Here’s what I’m doing:

  1. Create a new Rich Text note in DT.
  2. In the note, use Format > Table to create a new table with some rows/columns.
  3. Type some text into the table cells.
  4. Select a cell with text (double click the cell so it is highlighted).
  5. In the “Table” toolbox window (where it shows Rows, Columns etc), change the Cell Background to “Color Fill”
  6. Click the color swatch next to “Color Fill” and choose a color.
  7. Bug: The cell background color AND text color change to the selected color.

So you get (e.g.) red text on a red background. I’ve not found a way in DT to change only the cell background color. For comparison, the exact same operation in TextEdit works correctly (and in fact you can cut+paste correctly formatted table into DT from TextEdit and they look fine).

Note: This same problem also appears when trying to change the color of cell borders: the text color also changes.


Confirmed. Yes, TextEdit (on 10.11.5) does not have this problem.

For now – select the cell again – or even the whole table. Press ⌘T to open the Text format panel, where you can change the color of the text. Not ideal, but it will get you out of the current situation.

After double-clicking the cell, the text isn’t highlighted/selected over here and I can change the background color. But if I select also the text, then both colors are changed. Which versions of DEVONthink and OS X do you use?

(Sorry I should have said triple-click.)

I have OS X 10.11.5 and DT Pro 2.8.11, so I’m up-to-date on both.

Yes, if you don’t select any text, then it doesn’t change the text color, but it should not change the text color ever. The “double change” makes it impossible to change just the background color in a range of cells (by, for example, selecting the whole table).

Incidentally, if you double-click (not triple) in an empty cell, the cell is selected and again, both background and text colors are changed, which cause some fun when you try and type in text (it’s invisible).

As I noted, all this behavior differs from TextEdit (presumably the reference for expected behavior), and is certainly rather odd.