Family Historian User Group

ColeValleyGirl wrote: ↑

12 Dec 2022 13:45

So I'd say we want an option to choose the default text type, but support entering both types at all times.

What effect does choosing the default text type have if both types can always be entered?

As has already been said, the Ctrl+V shortcut should not be changed from its usual meaning of pasting formatted text.

If a user wants to switch from using rich text to *only* use plain text, what happens to all the existing rich text?

I'm not clear what the "only use rich text" option implies. Does it mean that when a user enters data into the Rich Text Editor, it is automatically and permanently formatted to the current default font, and the "Automatic" option is not available? How would it work alongside Preferences > Property Box, which is the font shown on screen and as the default setting for unformatted text?

At its simplest, I think we only need a single check box, for "Enable rich text data entry" (on by default). If the user clears this option, the Rich Text Editor is not available, and data entry becomes similar to FH6.

A more comprehensive treatment would provide the ability to "unformat" text, perhaps as a button within the Rich Text editor, but as has been pointed out already, there would need to be clear guidance on how that affects rich features such as tables and links.

tatewise wrote: ↑

12 Dec 2022 15:12

If a user wants to switch from using rich text to *only* use plain text, what happens to all the existing rich text?

This is a good point. Even if it converted all the existing rich text into plain text users might be quite alarmed when they see what has happened having perhaps chosen this option without really understanding the implications. I guess to be safe it would really need to only apply to new notes/source text (etc.) that they create in the future.

If the user has deselected rich text,

• when entering new data into a blank field, it is automatically entered as plain text
• if the existing field contents are plain text, the rich text editor is not available
• if the existing field contents are rich text, the rich text editor is available (and includes a button to convert to plain text)

I think my preference is NOT to have a global "zap all rich text" option, for the reasons pointed out, but it should be an option to unformat the text that is visible on the screen in front of you.

Mark' 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.

I agree about not converting rich text to plain text automatically, although there should definitely be an option to do so as a one-off 'clean up' -- doing it case by case would be too onerous. (Presumably also when pasting formatted text using CTL-V into a plain text note).

There would be some potential complications for plugin authors having to cope with rich and plain text which might need plugin API changes.

We also have to be careful to avoid projects containing rich text becoming incompatible with users who have deselected rich text.

ColeValleyGirl wrote: ↑

12 Dec 2022 15:34

There would be some potential complications for plugin authors having to cope with rich and plain text which might need plugin API changes.

Does that follow? Plugin code for FH6 that processes plain text works in exactly the same way for unformatted FH7 text. That's for CP to sort though, as long as plugin compatibility is not affected.

Mark1834 wrote: ↑

12 Dec 2022 15:38

Does that follow? Plugin code for FH6 that processes plain text works in exactly the same way for unformatted FH7 text. That's for CP to sort though, as long as plugin compatibility is not affected.

Yes, it does follow. Prompting for rich text entry (via the FH API) will be a different UI (and code) from prompting for plain text entry (via IUP). Plus of course it would need to be possible to determine the user's preference but support both options on a case by case basis. And that's just off the top of my head... Parsing tokenised Text will become harder, I suspect. And there may well be other impacts.

The existing DEAs would need significant rewriting. I have three standard V6 plugins and a third underway which would all be made more complex -- I haven't yet converted the V6 standard plugins and had not intended to make the new versions backwards compatible because of the UI implications.

Note: I'm not arguing against the feature, just pointing out some of the implications.

Fair enough - maybe a plain text only option would make certain features that rely on formatting data inaccessible. IMO, that's not a reason not to do it, but as you say, CP would have to think through the consequences.

Mark1834 wrote: ↑

12 Dec 2022 15:32

but it should be an option to unformat the text that is visible on the screen in front of you.

A 'one-keystroke button' would work for me.

I am long experienced in handling and formatting text and there are circumstances where I am happy to use rich text in FH.

What has frustrated me are the 'teething problems' with rich text in FH (often when copying and pasting within FH). For example:

• Text set at Tahoma 10pt when copied takes on another font setting when pasted.

• My 'point 5, after upgrade' involving strange changes to font settings and where the font information is unreliable.

• Certain keystrokes causing my text to become emboldened (not at my desire).

• An extra 'line feed' is added (the cursor is placed on the line below the text, rather than at the end of the line of text).

As things stand, I have to repeatedly 'manually' remove the unwanted formatting. Simple to do but time-wasting.

Desperation has caused me to want to 'turn off' rich text as a solution to this.

This is my revised Wish List entry proposal from earlier ...
TITLE: Rich Text Formatted and Unformatted Plain Text Options
DESCRIPTION:
The objective is to allow users to opt out of the Rich Text formatting features.

Add an option to disable the Rich Text Formatting feature for new text, presumably in Tools > Preferences > Notes.
Ideally, that should be a per Project option.

The right-click options to Paste and Paste with Website Link are greyed out leaving Paste Unformatted Text.
The Edit > Paste command and the Ctrl+V shortcut perform an unformatted text paste.

The [...] button on the right of the Note and other long-text fields opens a plain text window as it did in FH V6, unless the field already contains formatted Rich Text whereupon it opens the Rich Text editor window as in FH V7.
The Rich Text Editor window needs an option to convert to unformatted plain text.
There needs to be an option to bulk convert all rich text to plain text.
When converting rich text to plain text complex data such as tables and links need careful consideration.
Those capabilities cater for existing Projects and imports from other Projects that already have formatted rich text.

Add a new keyboard shortcut to perform a Paste Unformatted Text operation, e.g. Ctrl+Shft+V.

I may be missing it, Mike, but where's the capability to mix the two text types in the same project? i.e. to create new text of either type?

tatewise wrote: ↑

12 Dec 2022 16:13

This is my revised Wish List entry proposal from earlier ...
Add an option to disable the Rich Text Formatting feature for new text, presumably in Tools > Preferences > Notes.
Ideally, that should be a per Project option.

Mike

Sorry I don't agree with this being per project. It needs to be per fact. IMHO some of the citation / notes etc I would like to be Rich Text other should be Plain Text. This should be an option on the Tool Bar (rich or plain) the way some other applications do this.

Helen & Colin, you both seem to be describing the existing FH V7 capability that is not changed if the proposed option is left ticked to allow Rich Text Formatting to be enabled.
i.e. Right-click in the Note or other long-text field and choose Paste or Paste Unformatted Text and as in the Wish List proposal the Ctrl+V or Ctrl+Shft+V shortcuts.

### EDIT - AHK script + attachment corrected ####

I was experimenting with pasting and I noticed that even with Right Click Paste Unformatted Text, if there are "Unusual Characters" (I suspect not ANSI), it still ends up with Rich Text with e.g. <font="Segoe UI Symbol",,1></font>. However FH removes a lot of other formatting.

Anyway, I am not holding my breath for FH updates, and accepting the above "irregularity" for options [1] and [2] below, my pasting workarounds are:

[1] Using AHK. Add this and use Ctrl+Shift+V: See attached for my current FH AHK script. #### EDIT Revised version later ####

[2] Use Arsclip clipboard manager. Under Configure you can add "Per-Program Option"
- Add program = fh.exe
- Paste Method = Mimic Typing

[3] To lose the Rich text completely,
- Paste into a Text Editor and use/convert to ANSI encoding
- edit as required
- then copy into FHv7.

Jim, if Paste Unformatted Text is not doing what it says then that is a fault in FH that should be reported.
The Wish List proposal includes an option that should correct such mistakes by adding a convert to plain text option in the Rich Text editor window.

I don't want to paste text. I want to type text in to a re-sizeable pop-up window and choose when I open that window whether I'm entering rich text or plain text (with the default being set in Preferences.)

I'm wary of creating too many distracting side issues while we are fine tuning the wish list wording, but I think there is a relationship between any new FH feature and fixing the existing bug of superfluous Segoe UI formatting. If the bug is fixed, it becomes a "nice to have" feature rather than essential to prevent further project corruption.

I never use Segoe UI deliberately, but there were 9 examples of it in my main project GEDCOM file - and that's with a user who has long been aware of the issue and looks out for it .

The only way to clear them was to manually find the record in FH that was referenced in the GEDCOM file, and manually reformat. Many of them were very difficult to spot, such as just a trailing space being in Segoe UI with the rest unformatted.

It's highly likely that there are a lot of FH7 projects out there that suffer from this "font contamination". A plugin that selectively removes just this font but leaves all other formatting unchanged sounds like a challenge, but do we need a fairly simple plugin that simply lists affected records so the user can work through them manually? Even if CP do fix the problem, they can't fix the damage it has done already.

I also do not use Segoe font and have 156 occurrences in my gedcom.

Bill

Only two occurrences in my GEDCOM, both in REPOsitory records added in 2021 using FH7.

1 NOTE <font="Segoe UI",,0><fs="+2">
2 CONT </font></fs>
2 _FMT 1

Ouch! Are you a heavy rich text user, Bill, or are they in fields that should be plain text? Removing all formatting is much easier than doing it selectively.

ColeValleyGirl wrote: ↑

12 Dec 2022 17:13

I don't want to paste text. I want to type text in to a re-sizeable pop-up window and choose when I open that window whether I'm entering rich text or plain text (with the default being set in Preferences.)

So whichever default is set in Preferences there will need to be an option in the opened window to change mode.
The Wish List proposes: "The Rich Text Editor window needs an option to convert to unformatted plain text."
Would that satisfy your requirement? The pop-up window would always be the Rich Text editor but choosing the plain text option would reduce it to the FH V6 style plain text editor box. Any text already in the field gets converted to plain text.

Jim, Bill, Peter, Mark: Would that feature also offer a way of fixing those erroneous rich text formatted Notes?
I realise it would only be one at a time, but quicker than the current workarounds.

Yes, I think it would work, alongside a “Segoe UI detector” that lists the records for fixing. The detector should be straightforward, so I’ll post a simple prototype here later today or tomorrow morning to save users from rummaging in their GEDCOM file.

Thanks, Mike, I've just deleted the two empty (but formatted) Note fields, which I'm quite sure I had never added in the first place.

Mark1834 wrote: ↑

12 Dec 2022 17:58

Ouch! Are you a heavy rich text user, Bill, or are they in fields that should be plain text? Removing all formatting is much easier than doing it selectively.

I am not a heavy user of rich text. I only use rich text for Individual Record links and Census grids. However, I do not use Seqoe for these.

For everything else I use plain text. I always do right click > paste unformatted text. As far as I can see all of the use of Seqoe are on what should be plain text fields.

Bill