Suggestion: work in RTL mode

isaacbh · 02-27-2021, 10:38 AM

I mainly work with Hebrew text, and I wish there was a way of adjusting Sigil for it. I'm not referring to producing right-to-left books, that can easily be accomplished with the code, but to the code view itself. Specifically 2 things:

- Upon selecting "rtl mode", right-align everything (at least everything inside <body>). That is, visually align right, do not add "text-align" properties. This should also fix the placement of punctuation.

- Have the cursor move predictably: currently, pressing the left arrow key moves the cursor to the right , and vice-versa, when going over Hebrew letters. Maybe it will fix itself with the above change (?)

Obviously this will make it easier to work with Arabic too and any other rtl script.

KevinH · 02-27-2021, 10:45 AM

Happy to incorporate patches changes and pull requests related to this but since I do not work in RTL I would be shooting in the dark. As for visual text alignment of code, where there is no alignment per se, I truly do not understand exactly what you are referring to.

A couple of images showing what you are looking for in a similar code editor that works the way you want, would be helpful.

Also if you do have a separate code editor that works the way you want, you may want to set it under "open with" in Sigil so you can more easily edit things with your editor of choice.

KevinH · 02-27-2021, 11:29 AM

FWIW, CodeView is a QPlainTextEdit widget that uses a QTextDocument widget to hold the text being edited. A web search says that a QTextDocument has a method:

setDefaultTextOption(const QTextOption &option);

And one of the options allowed is text alignment. Setting that for Arabic and Hebrew to right to left might do what you want but I am not sure.

We can add that easily as Sigil subclasses QTextDocument. But would every person using Hebrew and Arabic want that changed? If not, and if it does what you want, we could allow an environment variable to control if it is used or not.

isaacbh · 02-27-2021, 12:19 PM

Yes, this should be explicitely selected by the user, in whichever way you think is appropriate.

Doitsu · 02-27-2021, 12:50 PM

Quote:

Originally Posted by isaacbh

- Have the cursor move predictably: currently, pressing the left arrow key moves the cursor to the right , and vice-versa, when going over Hebrew letters. Maybe it will fix itself with the above change (?)

AFAIK, if you use dir="rtl" attributes, the cursor will automatically move in the way that you described.
At least it works like that with my test epub.
For example, if you click between Bet (ב) and Resh (ר) in the right-most word (בראשית), and press the right arrow key, the cursor will move to the left, which, IMHO, is the correct direction, if you're assuming the same logic that is applied to LTR text where pressing the right arrow will move the cursor to the next letter. (In Hebrew, the next letter is the letter left of the cursor.)

In MS Word, there's a Cursor movement option that allows users to switch between logical and visual cursor movement.

Is that what you want KevinH to implement?
If so, the current behavior would be "logical cursor movement" and what you want is "visual cursor movement."

*I added text in parentheses for the benefit of KevinH.

isaacbh · 02-27-2021, 01:23 PM

Quote:

Originally Posted by Doitsu

In MS Word, there's a Cursor Movement option that allows users to switch between logical and visual movement.

Is that what you want KevinH to implement?
If so, the current behavior would be "logical cursor movement" and what you want is "visual cursor movement."

Indeed, the "visual" mode sounds right to me. It's really confusing pressing left arrow and watching the cursor move to the right. But would it still behave normally with English text and with numbers? (Sorry, I don't have Word installed).

KevinH · 02-27-2021, 01:26 PM

I still would love a screen shot of what CV in right align should look like and a xhtml file with Hebrew or Arabic in it to test with.

FWIW, I would be basing all of this on the **User-Interface**language selected and NOT on the language of the specific epub being edited as this would be a user interface feature.

Does that make sense or am I misunderstanding?

KevinH · 02-27-2021, 01:28 PM

FWIW for documents with mixed languages, I could overwrite the key mapping to reverse them but I can not do that on a language/word basis within a single document. So you may have to live with what Qt supplies.

isaacbh · 02-27-2021, 01:37 PM

Does that mean it can be disabled at least for non-xhtml files like stylesheets, content.opf etc? These do not have to have their behavior changed.

KevinH · 02-27-2021, 01:43 PM

Not easily as they would all share the same QTextDocument class. If it is more correct for xhtml, why would it not be correct for the opf, and the ncx?

Again, it would really help to see a screenshot of any code editor editing xhtml that does the alignment the way you are suggesting. If none exist, this is probably not a change I am willing to make as it would be a change only one user would benefit from as opposed to a whole class of users.

Doitsu · 02-27-2021, 01:45 PM

Quote:

Originally Posted by KevinH

I still would love a screen shot of what CV in right align should look like and a xhtml file with Hebrew or Arabic in it to test with.

I've included a link to a test epub in my post.

He probably wants the second line in the screenshot to be right-aligned:

I.e., אלהים את השמים ואת הארץ</p> should be right-aligned.
(Currently, it's rendered like the multi-line <h4> LTR text above it.)

Quote:

Originally Posted by KevinH

FWIW, I would be basing all of this on the **User-Interface**language selected and NOT on the language of the specific epub being edited as this would be a user interface feature.

That's how it currently works in MS Word.

KevinH · 02-27-2021, 01:54 PM

But that text is blocked in by tags on both ends. There is no whitespace used to align anything in that line. Just a start and end being the open and close tags. Are you saying the closing p tag on that line that wraps should be moved right up to that line's wrap point?

02-27-2021, 10:38 AM	#1
isaacbh Connoisseur Posts: 60 Karma: 201178 Join Date: Mar 2015 Location: Israel Device: Kobo Aura H20, Kobo Forma	Suggestion: work in RTL mode I mainly work with Hebrew text, and I wish there was a way of adjusting Sigil for it. I'm not referring to producing right-to-left books, that can easily be accomplished with the code, but to the code view itself. Specifically 2 things: - Upon selecting "rtl mode", right-align everything (at least everything inside <body>). That is, visually align right, do not add "text-align" properties. This should also fix the placement of punctuation. - Have the cursor move predictably: currently, pressing the left arrow key moves the cursor to the right , and vice-versa, when going over Hebrew letters. Maybe it will fix itself with the above change (?) Obviously this will make it easier to work with Arabic too and any other rtl script.

02-27-2021, 10:45 AM	#2
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	Happy to incorporate patches changes and pull requests related to this but since I do not work in RTL I would be shooting in the dark. As for visual text alignment of code, where there is no alignment per se, I truly do not understand exactly what you are referring to. A couple of images showing what you are looking for in a similar code editor that works the way you want, would be helpful. Also if you do have a separate code editor that works the way you want, you may want to set it under "open with" in Sigil so you can more easily edit things with your editor of choice. Last edited by KevinH; 02-27-2021 at 10:50 AM.

02-27-2021, 01:26 PM	#7
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	I still would love a screen shot of what CV in right align should look like and a xhtml file with Hebrew or Arabic in it to test with. FWIW, I would be basing all of this on the User-Interfacelanguage selected and NOT on the language of the specific epub being edited as this would be a user interface feature. Does that make sense or am I misunderstanding? Last edited by KevinH; 02-27-2021 at 01:28 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Suggestion: Search mode - open tabs	Vanguard3000	Sigil	13	06-16-2020 10:31 AM
Is paged mode supposed to work this way?	knghcm	Library Management	5	03-24-2014 12:05 AM
How does the panel view mode of the Kindle Paperwhite work?	Shadowlord	Amazon Kindle	4	11-04-2012 05:50 PM
PRS-T1 Recovery Mode doesn't work anymore	bookp	Sony Reader Dev Corner	2	07-13-2012 06:13 PM
Suggestion: Work with multiple databases	drMerry	Library Management	5	04-21-2011 07:11 PM

02-27-2021, 11:29 AM	#3
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	FWIW, CodeView is a QPlainTextEdit widget that uses a QTextDocument widget to hold the text being edited. A web search says that a QTextDocument has a method: setDefaultTextOption(const QTextOption &option); And one of the options allowed is text alignment. Setting that for Arabic and Hebrew to right to left might do what you want but I am not sure. We can add that easily as Sigil subclasses QTextDocument. But would every person using Hebrew and Arabic want that changed? If not, and if it does what you want, we could allow an environment variable to control if it is used or not.

02-27-2021, 12:19 PM	#4
isaacbh Connoisseur Posts: 60 Karma: 201178 Join Date: Mar 2015 Location: Israel Device: Kobo Aura H20, Kobo Forma	Yes, this should be explicitely selected by the user, in whichever way you think is appropriate.

02-27-2021, 01:28 PM	#8
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	FWIW for documents with mixed languages, I could overwrite the key mapping to reverse them but I can not do that on a language/word basis within a single document. So you may have to live with what Qt supplies.

02-27-2021, 01:37 PM	#9
isaacbh Connoisseur Posts: 60 Karma: 201178 Join Date: Mar 2015 Location: Israel Device: Kobo Aura H20, Kobo Forma	Does that mean it can be disabled at least for non-xhtml files like stylesheets, content.opf etc? These do not have to have their behavior changed.

02-27-2021, 01:43 PM	#10
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	Not easily as they would all share the same QTextDocument class. If it is more correct for xhtml, why would it not be correct for the opf, and the ncx? Again, it would really help to see a screenshot of any code editor editing xhtml that does the alignment the way you are suggesting. If none exist, this is probably not a change I am willing to make as it would be a change only one user would benefit from as opposed to a whole class of users.

02-27-2021, 01:54 PM	#12
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	But that text is blocked in by tags on both ends. There is no whitespace used to align anything in that line. Just a start and end being the open and close tags. Are you saying the closing p tag on that line that wraps should be moved right up to that line's wrap point?

Advert

Advert