Add a line counter in Options for align text

[monzug]

Harry @abrasax agreed that we should add a line counter in Options for align text. the default would be not checked and the counter should add a line number every 5 rows.

[irina060981]

yes, I remember about this issue - #397
Will do later

[irina060981]

Now there is a problem with implementing this issue.

Before we had an IndexedDB support
I was going to do it easily - Add an additional column to each text, where row height is equal to text row height.
And add a counter from 1 to the end of the block. And hide 1-4 each row text.

When we have IndexedDB support
I couldn't add such a counter - because I don't know - what is the first number of the visible part.
Because I don't know how much lines are in each part. I know amount of tokens and characters - but amount of lines is dependent on the screen width. And there is now correct way to count it in the code.
The only way to define the first line number is to load all the text, render it on the screen (on this step only browser would render each character and defines how much characters are placed to the line), add line number to each line, and then again erase all the text that is from other parts.
So it would be very hard operation for the browser. And we add IndexedDB support, max characters and so on - to avoid such a behaviour.

Such line numbers could be applied to the text that is formatted to lines (as poetry) and we don't pay attention how browser would divide it to lines. Even if browser would render one line to two lines - we would consider it as a one line to numbers.
But in our case we don't have such limitations.

So I don't know how to solve this issue in our case. And I believe that it could take too much time and too much refactoring trying to solve it.
@monzug and @abrasax, I suggest to cancel this enhancement.

[abrasax]

I wonder whether there would be any value in displaying a counter with the number of the current alignment window- the first would be one, the next one two etc. It's arbitrary but might be of some help navigating among the successive windows, especially with the ability to jump to a specific one. Have to think about this a bit more and discuss it with Monica.

…

On Mon, Jul 5, 2021 at 12:59 PM Sklyarova Irina ***@***.***> wrote: Now there is a problem with implementing this issue. *Before we had an IndexedDB support* I was going to do it easily - Add an additional column to each text, where row height is equal to text row height. And add a counter from 1 to the end of the block. And hide 1-4 each row text. *When we have IndexedDB support* I couldn't add such a counter - because I don't know - what is the first number of the visible part. Because I don't know how much lines are in each part. I know amount of tokens and characters - but amount of lines is dependent on the screen width. And there is now correct way to count it in the code. The only way to define the first line number is to load all the text, render it on the screen (on this step only browser would render each character and defines how much characters are placed to the line), add line number to each line, and then again erase all the text that is from other parts. So it would be very hard operation for the browser. And we add IndexedDB support, max characters and so on - to avoid such a behaviour. Such line numbers could be applied to the text that is formatted to lines (as poetry) and we don't pay attention how browser would divide it to lines. Even if browser would render one line to two lines - we would consider it as a one line to numbers. But in our case we don't have such limitations. So I don't know how to solve this issue in our case. And I believe that it could take too much time and too much refactoring trying to solve it. @monzug <https://github.com/monzug> and @abrasax <https://github.com/abrasax>, I suggest to cancel this enhancement. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#397 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABK7KE76GGQX77GO76XYMY3TWGGAFANCNFSM45EYPOIA> .

[monzug]

I think it would be helpful specially when user goes to next page. it's difficult to know the exact location in the text as we are repeating a big chunk of lines from prev to next page. Right now, to help me navigating between pages, I do an alignment on the last word of the last line of the page, so when I go to next page I know where to start from. we should ask Bridget if she has any suggestion on how to approach this issue.

[irina060981]

I have found the problem with realizing variant - when text is added to the bottom without scroll.
It doesn't execute scrolling if we simply add the text by next.
But when we add text and remove previous, then text changes its position not because of scrolling - but because of changing the top.

Also it is not so easy to add a column for part numbers, because parts could be mixed in one line.
And it is not easy to define the place.

That's why I suggested some improvements for this case according to the variants we discussed on the meeting:

• added division by font-weight for neighbour parts
• added visual parts navigation (similiar to Perceids) - but it would be always on one line.

This change is uploaded to development environment - so would be glad to get your feedback.

[monzug]

I really like the design. my question is related to #440: why do we need to show two parts on screen (1,2 then 2,3 then 3,4 etc.)? I also like that the text of a part is in red and the next part is in bold red, it's very helpful visually .

[irina060981]

We need to show it for the case when we have to align a group of tokens in both parts (for example one sentence is divided to two parts).
I could show only one part - but we could have situations when a user won't be able to create an alignment group.

[monzug]

Would it be possible to identify the sentence and carry over only the sentence? if not, would it be possible to carry over only one line (or max two lines) from previous text? the latest would be my prefer solution (related to #440)

[irina060981]

It is much more difficult scenario, because:

1. Sentence could be very big and even bigger than a part (Harry told this fact about Arabic texts)
2. I store segments, parts and tokens. We don't save separately sentences.
3. We could have a group inside more than 1 sentence.
4. Prev/Next click behaviour becomes much more difficult and unclear.

If we would decide to spend time for implementing such a scenario - I need a detailed explanation - how exactly it should work to reduce redoing it.

About lines - I could not manipulate lines - because we don't know any information about amount of lines before they are rendered on the current screen. And also it doesn't avoid the problem - when a user doesn't have enough words for the alignment group.

The easiest solution here is to show only one part at a time and make a user to click prev/next each time they want to return.
If you, @monzug, and Harry, @abrasax, think that it is more habitually for you and users. Let's do it.

[monzug]

Let’s discuss with issue #440 . Also it depends on time and priorities. Thanks