Bug: Clippings and Text Editor in Beta 9

Dave Hooton said:

don't see why the editor can't be more adaptive or at least fix the truncation

Dave, I have identified the cause and I'm working on a fix.

However, I don't think the fix will make it into 5.1. So, please allow me to offer a short-term workaround and an explanation of the issue.

The issue is that the editor is trying to apply a hanging indent (i.e. negative first line indent) to a paragraph that doesn't have a corresponding margin. Typically, a paragraph with a negative first line indent will also have a margin in order to indent the rest of the paragraph. But, in this case, the margin is 0 so the first line hangs off the display.

As a workaround, you can place your cursor in the paragraph(s) affected and press the "clear formatting" button. This will reset the first line indent to 0. Alternatively, if you actually want the hanging indent, you can apply a margin to the paragraph using the "increase indent" button.

I hope that can help you in the short term until the fix can be implemented.

Dave Hooton said:

Alan Palmer (Logos) said:

As a workaround, you can place your cursor in the paragraph(s) affected and press the "clear formatting" button. This will reset the first line indent to 0. Alternatively, if you actually want the hanging indent, you can apply a margin to the paragraph using the "increase indent" button.

But why is this paragraph formatted OK when pasted into a Note following some RTL text (no truncation and citation is properly sized)?

I now find in RC1 that the truncation still occurs when pasted into a Clipping as described above but disappears after I leave the tab and then return. The behaviour is completely different if I paste into a clipping created with LTR text!

This is because the selection is actually a paragraph fragment (it doesn't actually include the beginning of the paragraph, i.e. the chapter number).

When creating a clipping, we accept paragraph fragments as complete paragraphs (treat them as if they aren't fragments). This behavior is intended to allow clippings created from partial paragraph selections to be formatted like the paragraph they come from. When pasting, fragments are merged with the paragraph they are pasted into.

Dave Hooton said:

Alan Palmer (Logos) said:

When creating a clipping, we accept paragraph fragments as complete paragraphs (treat them as if they aren't fragments).

My issue doesn't concern creating a clipping but if I use the fragment "not have much need for forgiveness. ..." (BKC) to create one there is no indentation. That only happens when I include the start of the paragraph. If i then paste the same selection it will be indented because of the previous formatting. 
So the issue really concerns pasting LTR text into a RTL formatted clipping. Why not simply recognise LTR and disregard the RTL "style" as seems to happen when pasting into a Note in the same circumstances?

Sorry I didn't originally understand. It sounds like you are saying pasting into a paragraph A in a clipping has a different result than pasting into paragraph A in a note? 

I'm not aware of a reason paste into clipping would be any different than pasting into a note.  The only difference I can think of that would matter is the context it is pasted into (i.e. the paragraphs are subtlety different). I will double check that assumption. 

Dave Hooton said:

Why not simply recognise LTR and disregard the RTL "style" as seems to happen when pasting into a Note in the same circumstances?

I took another look this morning. I believe the problem is that in the note it is pasting into an LTR paragraph. In the clipping it is pasting into an RTL paragraph. And this explains the reported difference.

[At least this was my experience following your steps.] If you don't mind, would you be willing to verify this by explicitly setting the text direction in your note to RTL (right control + right shift) and verify that it then acts the same as the clipping?

Truncation will also be fixed in 5.1 RC 2.