-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a line counter in Options for align text #397
Comments
yes, I remember about this issue - #397 |
Now there is a problem with implementing this issue. Before we had an IndexedDB support When we have IndexedDB support 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. 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. |
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>
.
|
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. |
I have found the problem with realizing variant - when text is added to the bottom without scroll. Also it is not so easy to add a column for part numbers, because parts could be mixed in one line. That's why I suggested some improvements for this case according to the variants we discussed on the meeting:
This change is uploaded to development environment - so would be glad to get your feedback. |
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 . |
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). |
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) |
It is much more difficult scenario, because:
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. |
Let’s discuss with issue #440 . Also it depends on time and priorities. Thanks |
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.
The text was updated successfully, but these errors were encountered: