* Plain Text Only setting

[tatewise]

Helen, maybe I have misunderstood, but earlier you were insisting the Wish List should specify both the FH V7 Rich Text editor window and the FH V6 plain text editor box, that were chosen by a preference setting, especially when creating new text fields. You seem to have stepped back from that requirement.

If current features reliably produce plain text when no formatting options have been chosen then the Wish List can be simplified to a keyboard shortcut for pasting unformatted text and an option in the Rich Text window to clear all formatting.
I'll leave it to others to formulate the words and step away.

[ColeValleyGirl]

Sounds as if we should add to the elements of the Wish List item:

MANDATORY: A one-off mechanism to remove formatting errors introduced by the bug(s) in the Rich Text functionality that introduce unwanted/unexpected rich text elements. We will need a list of the known problems.

(As an aside, now that a plugin author has started to grasp this nettle, the pressure on CP to do so is very reduced -- you may view this as a good or a bad thing.)

Issues where it may not do what users expect - documentation clarification as a minimum, but possibly system issues to fix.

Not sure what you mean by this. If users have misunderstood documentation in the past (as is very easy to do with CP documentation) , that's been 'on them' to fix -- why should this be different? And do you have specific documentation improvements in mind?

[davidf]

(with the short-cuts available for people that like shortcuts - "the WordStar / WordPerfect generation"?)

Shortcuts are an accessibility requirement, not a generational preference.

Very true

We have identified a Ctrl-Shft-V (paste unformatted) short-cut requirement (together with matching Edit and Context Menu options). I suspect this is a need even for non-rich text notes, where (V6) I sometimes find some very odd extraneous characters (usually showing as a square) getting pasted into fields.

Are there other accessibility requirements that might be usefully included - or should this be a "one-off" Wish List Request? My inclination is that Ctrl-Shft-V should be a non-controversial item that we might hope would be addressed in a dot-upgrade.

Short-cuts are an issue for non-mouse users (due to preference or otherwise), but I imagine that some aspects of diagrams are hard to drive from the keyboard. (I notice and use the fact that cursor keys can change the diagram box selection - but getting the initial selection (other than the diagram root on initial creation) requires a mouse?)

My previous lap top had "a context menu" key, which I used to find very useful - but I think that is more a hardware/OS issue than expecting applications to provide a key-binding (often Shft-F10 - shift-menu) that has that effect.

Are there visual issues that are not addressed? Sizing, contrast?

Do we start an "Accessibility Topic" to act as "click-bait" to catch accessibility issues. Searching FHUG for "Accessibility" seems to bring up a lot of discussion about accessibility of the Knowledge Base rather than about accessibility of FH.

[davidf]

Issues where it may not do what users expect - documentation clarification as a minimum, but possibly system issues to fix.

Not sure what you mean by this. If users have misunderstood documentation in the past (as is very easy to do with CP documentation) , that's been 'on them' to fix -- why should this be different? And do you have specific documentation improvements in mind?

I was trying to differentiate between "rich text issues" that we all agree are because the system is "doing it wrong" and other issues where we may be divided on what we expect. Expectations are often set by documentation (on screen literals, help systems etc.) and yes that would be for CP to fix - I suppose if we look on FH in the widest terms such documentation is "part of the system", so documentation issues are "bugs".

No, I don't have examples, but I was wanting to allow for cases where we disagree about something that happens in rich text fields.

[ColeValleyGirl]

Do we start an "Accessibility Topic" to act as "click-bait" to catch accessibility issues.

I'd support this -- I've had on my to-do list for a long time an article for the KB about FH Accessibility and a new topic would feed nicely into that.

I think the unformatted paste shortcut should be handled as part of the rich/plain text wish list request when it's finally formulated.

[ColeValleyGirl]

I was wanting to allow for cases where we disagree about something that happens in rich text fields.

The current documentation just outlines what the formatting buttons in the rich text editor do... there's not much scope for interpretation, but plenty of scope for assumptions about what isn't documented...

[ColeValleyGirl]

Helen, maybe I have misunderstood, but earlier you were insisting the Wish List should specify both the FH V7 Rich Text editor window and the FH V6 plain text editor box, that were chosen by a preference setting, especially when creating new text fields. You seem to have stepped back from that requirement.

If current features reliably produce plain text when no formatting options have been chosen then the Wish List can be simplified to a keyboard shortcut for pasting unformatted text and an option in the Rich Text window to clear all formatting.
I'll leave it to others to formulate the words and step away.

Thanks, Mike -- I just won a bet.

What I originally said on the subject was:

I think it's important that Calico Pie provide the option to default to plain text, and to convert rich text to unformatted text

We need to cater for 3 use cases:
Users who want to *only* use rich text
Users who want to *only* use plain text
Users who want to use both and choose at the time of entry
So I'd say we want an option to choose the default text type, but support entering both types at all times.

Mark's suggestion of 'enable rich text data entry' (on by default) might be the simplest way of meeting all the three use cases I outlined. Leave default behaviour as now, but allow users to opt out of rich-text either entirely or on a note-by-note basis.

Put very simply, choose a default preference in Tools > Preferences > Notes, but with the option to override or reinstate that preference when creating or editing any note text (rich or plain). The preference and per-note setting should both affect the editor interface and the format of the note, including (on a per-note basis) converting rich <-> plain text.

All of which seem consistent to me with:

MANDATORY/CURRENT BEHAVIOUR: Text formatting should only be introduced by the user (including by pasting formatted text from the clipboard or using formatted Autotext). If all visible text formatting is removed, the note should revert to plain text. (This seems to be the current design, but any bugs making this behaviour unreliable must be fixed)
MANDATORY: Keyboard shortcut should be provided for pasting unformatted text.
NICE TO HAVE: An option to revert to plain text only, hiding the rich text formatting capability in the editor.
NICE TO HAVE: A simple method of converting a rich text note to a plain text note. (The simple Select All-Cut-Paste Unformatted method exists already, which is why I've marked this NICE TO HAVE).

[davidf]

Are we getting "hung up" about the difference between

• Fields in the underlying file which are marked as "Rich Text", as opposed to Fields that are not
• Plain text that happens to reside in a "Rich Text" field

From what people have said before CP seems to have structurally decided that all (?) "Long Notes" shall be held as rich text fields, but "plain text" put into such fields seems to acquire unwanted formatting?

[ColeValleyGirl]

Are we getting "hung up" about the difference between

• Fields in the underlying file which are marked as "Rich Text", as opposed to Fields that are not
• Plain text that happens to reside in a "Rich Text" field

From what people have said before CP seems to have structurally decided that all (?) "Long Notes" shall be held as rich text fields, but "plain text" put into such fields seems to acquire unwanted formatting?

I don't care about the underlying format (except as a plugin author); a Note either contains rich text or it doesn't (in which case it's a plain text note) and it can be changed between the two states by the removal or addition of formatting/formatted text. We need the capability to generate Notes of both types, and convert a selected note between the types.

Where unwanted formatting is being introduced (which it is, apparently unpredictably, for some users), that's a definite bug.

[davidf]

I think we are now in danger of having a "vigorous agreement"!

[AdrianBruce]

I perhaps need to restate my use case to explain why I want what I asked for.

If I copy text from certain websites and paste it using Ctrl+V into a note in FH, the success is entirely problematic. The classic cases are FreeBMD and the GRO site BMD indexes. One works pretty much OK. The other comes up with a mess with data mixed up in 2 columns (?). (No I'm not able to confirm the exact circumstances right now). The fact that one ends up as a mess, is, I strongly believe, not something that CP can fix. It's a constraint put on the process by the way that the site was coded.

Because I can never remember which gives the idiotic results, I often do Ctrl+V and then 50% of the time, need to Undo that step before Right Click and choosing Paste Unformatted.

I have the same problems pasting into MS Word and long ago settled on altering the default for pasting using Ctrl+V to be paste unformatted. If it turns out that the source plays nicely with the target, then Right Click followed by Paste Formatted is there for me.

I simply want an equivalent facility in FH. It's not a question of making the paste formatted work correctly because it probably IS working correctly - it's just that, shorn of the rest of the HTML styling stuff, what ends up in the text box looks rubbish.

I don't see this as specifying How when I should be specifying What, because we're dealing in physical constraints.

Yes, I probably lose out half of the time by doing a Paste Unformatted when Paste Formatted would work but that's my decision how to deal with the text in question.

[ColeValleyGirl]

Adrian, I think we're all in vigorous agreement that Paste Unformatted is essential and needs a keyboard shortcut.

[AdrianBruce]

Couple of things to be explicit - I want the ability to alter the default for Ctrl+V and - whatever else Mike identified - not just the ability to choose at paste time. I hope that's already clear but if not...

Secondly, I do run into occasional issues where what I thought was a plain text note, acquired a typeface and size that I didn't set. (Maybe this happens mostly with an apparently empty text box?) Usually this happens long after the previous editting of that item so I can't decide how the issue arose but yesterday I did manage to mess things up deliberately when pasting in a special character, removing it but (it turned out) not removing the font setting in the Rich Text. I mention this just to emphasise that I'm not trying to say that my request is all that's necessary.

[AdrianBruce]

Adrian, I think we're all in vigorous agreement that Paste Unformatted is essential and needs a keyboard shortcut.

Except that... I don't mind Paste Unformatted having it's own shortcut. But I do want the ability to alter what Ctrl+V does, via the default setting proposed. Otherwise I gain nothing because I might just as well Right Click and choose the appropriate Paste Formatted or Paste Unformatted there. If that's agreed on, as per Mike's formulation, then fine. (Basically I use just 3 keyboard shortcuts, which is why I may sound concerned about another).

[ColeValleyGirl]

But I do want the ability to alter what Ctrl+V does, via the default setting proposed

Just thinking this through.

Say, I set my default to Rich Text, and therefore Ctrl-V pastes formatted text even in notes I intend to be plain text because that's it's default behaviour according to my setting. Not good...

I set my default to Plain Text, and the opposite happens (unformatted text when I want formatted, and no way to get formatted because Ctrl-V won't do it). Also not good.

For people who want to operate entirely in one mode or another, it would be fine. For those who want to mix and match, it seems problematic.

[davidf]

But I do want the ability to alter what Ctrl+V does, via the default setting proposed.

There, I am not with you. Many of us know Ctrl-V to mean "dump whatever is on the clipboard into the application and let the application sort out what it all means" - I would not want to change that.

Likewise, slightly less widespread, but widely accepted is that Ctrl-Shft-V means "dump whatever is on the clipboard less any formatting into the application".

By following convention we know what to expect - which is important when pasting from websites and the result is not what you expect - you know what you wanted.

(FreeBMD is an abomination due to the old style use of tables with rowspans and blank cells to get the appearance "right". The download option (straight into a text editor) allows cut and paste of a denormalised comma delimited string. GRO is simpler but they treat GRO Ref solely as a piece of data not as a heading and its own column of data. There is some useful CSS in the code if you want to try and use a browser add-in like Stylus to sort it out - to date I have baulked at doing that.)

Other Options. Different wish list requests for :

• A feature that allows you to determine your own key-bindings.
• Some form of plug-in functionality which allows us to say "this is FreeBMD tabular data, format it according to these rules" "this is a FMP Census tabulation, format it according to these rules". Possibly Ctrl-Alt-V (plus equivalent edit menu and context menu options) brings up a small pop-up where you tell it what it is receiving.

[davidf]

... I do run into occasional issues where what I thought was a plain text note, acquired a typeface and size that I didn't set. (Maybe this happens mostly with an apparently empty text box?) Usually this happens long after the previous editting of that item so I can't decide how the issue arose but yesterday I did manage to mess things up deliberately when pasting in a special character, removing it but (it turned out) not removing the font setting in the Rich Text. I mention this just to emphasise that I'm not trying to say that my request is all that's necessary.

(my emphasis)

This surely is a bug and needs to either be separately reported or collated with other "bugs" in a separate topic. If we cannot expect CP to "fix" these bugs, they probably can't fix a format switching option?

[NickWalker]

The way FH is meant to work currently is that rich-text is on when required. So Ctrl+v will paste formatted text and I think we're largely agreed we want Ctrl+Shift+v to paste unformatted text. I would expect this is a very simple enhancement that CP can make in the next update if they wish.

If there was a new mode to turn off rich-text then Ctrl+v and Ctrl+Shift+v would do the same thing because FH wouldn't deal with rich-text anymore so anything pasted is plain (just like it was in FH6) .

I don't really understand the concept of a 'rich text only' mode that has been discussed. Currently in FH (and ignoring any glitches/bugs for now) if I'm typing text into the rich-text box then that is plain text unless I add some formatting to it in which case it would become rich text. If there was a 'rich text only' mode what difference would that make to the text I just typed in? What's it going to do to it to suddenly force it to be rich?!

[ColeValleyGirl]

I don't really understand the concept of a 'rich text only' mode that has been discussed. Currently in FH (and ignoring any glitches/bugs for now) if I'm typing text into the rich-text box then that is plain text unless I add some formatting to it in which case it would become rich text. If there was a 'rich text only' mode what difference would that make to the text I just typed in? What's it going to do to it to suddenly force it to be rich?!

The status quo allows either rich or plain text (i.e. mixed) as the user chooses (by the way they use the editor). Some people will always use rich-text, and some of the options discussed have implied or specified changing the behaviour of the UI in this case.

However, if an option to enforce plain-text only node is implemented, then is the converse 'rich text only' or 'mixed'? If it's 'mixed' (which logically, it has to be -- as you point out, we can't have mandatory formatting! you will make this BOLD or the Spanish Inquisition will bring on the soft cushions and the comfy chair) then the option *mustn't* affect standard shortcut behaviour.

So, we'd have:

• Plain Text ON => Ctrl+V pastes plain text; Ctrl-Shft+V pastes plain text.
• Plain Text OFF => Ctl+V pastes formatted text; Ctrl-Shft+V pastes plain text.

i.e.. the OFF setting makes no difference to the current behaviour.

[Woodg]

So, we'd have:

• Plain Text ON => Ctrl+V pastes plain text; Ctrl-Shft+V pastes plain text.
• Plain Text OFF => Ctl+V pastes formatted text; Ctrl-Shft+V pastes plain text.

i.e.. the OFF setting makes no difference to the current behaviour.

If I might jump in ...

The list above seems right to me as it basically adheres to long-standing standard Windows keyboard shortcuts.

Glenn

[NickWalker]

I don't really understand the concept of a 'rich text only' mode that has been discussed. Currently in FH (and ignoring any glitches/bugs for now) if I'm typing text into the rich-text box then that is plain text unless I add some formatting to it in which case it would become rich text. If there was a 'rich text only' mode what difference would that make to the text I just typed in? What's it going to do to it to suddenly force it to be rich?!

The status quo allows either rich or plain text (i.e. mixed) as the user chooses (by the way they use the editor). Some people will always use rich-text, and some of the options discussed have implied or specified changing the behaviour of the UI in this case.

However, if an option to enforce plain-text only node is implemented, then is the converse 'rich text only' or 'mixed'? If it's 'mixed' (which logically, it has to be -- as you point out, we can't have mandatory formatting! you will make this BOLD or the Spanish Inquisition will bring on the soft cushions and the comfy chair) then the option *mustn't* affect standard shortcut behaviour.

So, we'd have:

• Plain Text ON => Ctrl+V pastes plain text; Ctrl-Shft+V pastes plain text.
• Plain Text OFF => Ctl+V pastes formatted text; Ctrl-Shft+V pastes plain text.

i.e.. the OFF setting makes no difference to the current behaviour.

It looks like we agree - it must be Christmas

[davidf]

I don't really understand the concept of a 'rich text only' mode that has been discussed. Currently in FH (and ignoring any glitches/bugs for now) if I'm typing text into the rich-text box then that is plain text unless I add some formatting to it in which case it would become rich text.

I agree, but I suspect it may depend on what we mean by gliches/bugs.

I would expect plain text "This is Plain Text" to be stored in the field as just that and would see anything else as a "glitch/bug". It is possible (I don't have V7) that if you enter such plain text into a rich text editor, as a minimum it gets a "RT wrapper" - which we might see as a departure from "plain text". FH could defend this as enabling future options, but ...

In HTML/CSS terms I might get "<span>This is Plain Text</span>" stored. the <span> tags do nothing unless you add styling to them - which could happen after the event - but in HTML/CSS that would be dynamic depending on the CSS file . An entry "span {color: red; font: cursive;}" in an appropriately located or referenced CSS file would render all text between span tags in red cursive font. Find the entry in the CSS file and delete it and everything returns to normal.

What is happening in FH-RT? If we look at the actual file holding a bit of plain text in a Rich Text field, what does it look like and is there any wrapper - or is the TAG behaving as a wrapper? If there is, perhaps (I am speculating - only CP would really know) we need to find whether that wrapper somehow acquires a format - different to the normal default format. If we can get that accepted as a "bug" we might be OK?

[ColeValleyGirl]

I would expect plain text "This is Plain Text" to be stored in the field as just that and would see anything else as a "glitch/bug". It is possible (I don't have V7) that if you enter such plain text into a rich text editor, as a minimum it gets a "RT wrapper" - which we might see as a departure from "plain text". FH could defend this as enabling future options, but ...

It is stored as just that:

Code: Select all

0 @N5@ NOTE This should be plain text
1 CONT 
1 CHAN
2 DATE 13 DEC 2022
3 TIME 10:17:01

whereas a rich text note is:

Code: Select all

0 @N6@ NOTE <fs="+4"><b>1841 UK Census</fs></b>
1 CONT 
1 CONT Place: 
1 CONT 
1 CONT <table="3905|1175|950|1730|5015">
1 CONT <row> Name | Sex | Age | Occupation | Where Born </row>
1 CONT <row>  |  |  |  |  </row>
1 CONT </table>
1 CONT 
1 _TEXT
2 _FMT 1
1 CHAN
2 DATE 11 DEC 2022
3 TIME 08:30:54

[tatewise]

What is happening in FH-RT? If we look at the actual file holding a bit of plain text in a Rich Text field, what does it look like and is there any wrapper - or is the TAG behaving as a wrapper? If there is, perhaps (I am speculating - only CP would really know) we need to find whether that wrapper somehow acquires a format - different to the normal default format. If we can get that accepted as a "bug" we might be OK?

If unformatted text is pasted into a field (and the Rich Text editor window is not opened) there is no wrapper or extra tags.

Once the Rich Text editor window is opened, whether on existing plain text or to enter plain text, then it is likely that a _FMT 1 tag gets appended. That changes the field from plain text to rich text as far as CP and Plugins are concerned. However, users will probably see no difference unless the field is included in a GEDCOM export to another product that may complain about the non-standard _FMT 1 tag.

Sometimes, white space such as blank lines can acquire a font format wrapper as well as the _FMT 1 tag. However, that is probably a bug.
Similarly, text that had been formatted rich text may have its formatting removed by the user editing the text. However, that may leave behind format wrappers on white space text and the _FMT 1 tag. Only a clear formatting option can comprehensively remove all format wrappers and the _FMT 1 tag to return the field fully to plain text.

Helen's code samples are for a Note Record but the format is similar for any rich text field such as a local Note or the Text from Source fields.
e.g.
Plain text local note:

Code: Select all

2 NOTE Connecting Ancestor FH Id: 2

Rich text local note:

Code: Select all

2 NOTE <i>Connecting Ancestor FH Id: 2</i>
3 _FMT 1

Local note with formatting removed:

Code: Select all

2 NOTE Connecting Ancestor FH Id: 2
3 _FMT 1

[davidf]

Thanks Helen (and Mike)

Thinking in "Bug hunting mode" rather than "Wish List Specifying mode"

Code: Select all

0 @N5@ NOTE This should be plain text
1 CONT 
1 CHAN
2 DATE 13 DEC 2022
3 TIME 10:17:01

We need to see if those having trouble have the troublesome notes in the above format - but possibly with some FT-RT tags included (which would be a bug), or whether their examples look more like Helen's second example (which I have changed to illustrate my point):

Code: Select all

0 @N6@ NOTE This should be plain text
1 CONT 
1 _TEXT
2 _FMT 1
1 CHAN
2 DATE 11 DEC 2022
3 TIME 08:30:54

(i.e. as Plain Text in a Rich Text field)

Which to me would indicate that for some reason FH has chose to save this note as a FH-RT note (a bug with potential consequences), but which might not be a problem if the

Code: Select all

1 _TEXT
2 _FMT 1

elements are benign and do nothing in respect of formatting - rather than impose some sort of FH-RT default formatting (a bug?) which itself may not matter if the default formatting happens to match the normal FH formatting defaults (for both screen display and printing).

... If unformatted text is pasted into a field (and the Rich Text editor window is not opened) there is no wrapper or extra tags.

Once the Rich Text editor window is opened, whether on existing plain text or to enter plain text, then it is likely that a _FMT 1 tag gets appended. ...

OK in replying to this I am struggling without specific screen shots and a copy of V7 (I am holding off until the indications are that Rich Text is working - and I think I have seen comments that it is problematic under WINE), but ...

I get the impression from the quote of Mike's post above that if you move into a "long note" (which has the potential to hold Rich Text) you are in the old "plain" editor unless you specifically take some action to "open the Rich Text Editor". This sounds like a kludgey interface issue.

Wouldn't a cleaner interface mean that whenever you put the focus on a field capable of holding Rich Text, you get the Rich Text toolbar and whatever you enter is saved as in my second code example above.

Code: Select all

0 @N6@ NOTE This should be plain text
1 CONT 
1 _TEXT
2 _FMT 1
1 CHAN
2 DATE 11 DEC 2022
3 TIME 08:30:54

Provided that imposes no formatting and the user has not used the formatting facilities, the user should not be able to tell the difference between that and

Code: Select all

0 @N5@ NOTE This should be plain text
1 CONT 
1 CHAN
2 DATE 13 DEC 2022
3 TIME 10:17:01

(A variation to store without the _TEXT and _FMT 1 tags if there is no formatting would seem superfluous - given that the export functionality can strip formatting out.)