Bug: Paragraph Style doesn't apply the right font family if you highlight text going from top-to-bottom.

Scrivener Windows Beta (Archived)
1

Oddly specific, I know, but noticed it while trying to create elaborate tables for a Character Sheet template. As title says, I’ve created a few custom format styles, one called TableSubTitle. If I highlight text in a column going from bottom-up, and choose the TableSubTitle style, everything is as it should be. However, going top-down, the final text highlighted will apply the format rules (it will align, be correct size, color etc.) but it won’t apply the font family that is saved with that style.

Windows 10 Pro v. 1909
OS.Build - 18363.959
Scrivener v2.9.9.8 Beta (984254) 64-bit.

2

Hi, this should be in the beta forum. https://www.literatureandlatte.com/forum/viewforum.php?f=57

If you want the devs to see it, PM a mod and ask them to move it.

Best,
Jim

3

Thank you, I’ve PMed an Admin.

4

Verified strange behavior of down-up selection of a column vs up-down selection of a column. In my case, I made a simple table. 3 columns, 4 rows.

I normally use Noto Serif for text. I created a new style, and used another style I had already made for emphasizing certain lines.

I used Segoe Print for the new font in the new style (oddly named SegoePrintTable), and the other style uses Noto Serif Bold Italic.

Here are the results:
Table 1: raw.

ScrivTable_001.JPG
ScrivTable_001.JPG1223×176 20.4 KB

Table 2: Bottom up selection, Emphasis style added. Note: I only selected the 1st column.
ScrivTable_002.JPG
ScrivTable_002.JPG1223×225 29.9 KB

Table 3: Top down selection. Change of font. Again, all the 1st column selected., nothing else.
ScrivTable_003.JPG
ScrivTable_003.JPG1223×252 26.4 KB

Note, the last line is no style. It was selected, but the style was not applied to the last row, first column.
I can’t put any more pictures in this post, but something else strange happens when I assign “No Style” to the table. More in next post.

5

So, that looks like several bugs at once. But what’s a little odd: after reassigning “No Style” to the entire table (selected all), this happens:

ScrivTable_004.JPG
ScrivTable_004.JPG1230×269 22.9 KB

I have nonprinting characters shown for a reason, and there are two pilcrows in the 1st cell. Note that except for the last line, the pilcrows are NOT in NotoSerif. Selection order doesn’t matter; I tried both ways, and the results were the same.

So… Something strange is going on with tables and fonts. I’d call it a bug. This is not necessarily the bug the OP reported, but it’s related.

  1. The behavior should be the same when selection is top-bottom as when it’s bottom-up.
  2. When applying any style (and “no style” is not a style) to a selection, no part of the selection should revert to “No style.”
  3. When applying any style to a selection in a table, no other part of the table should change style, should it?
  4. When applying any style to a selection, all of the selection should change to the font in the style, if there’s a font in the style.
  5. When reverting to “No Style”, the formatting markers should also change also (that is, the pilcrows and other non-textual characters should not remain in the former style), and line-height, it seems to me, should follow the font size, other factors allowing.

There may be more bugs present, but those are the ones I see. And all five may be related to the Selection algorithm, and how tables behave, and the interaction between those.

At any rate, strange table behavior and direction of selection is verified as rather odd.