Ability of setting a max. length to "comment" field

[mgaillard]

Hello Chaley,

I use Calibre Companion for about three years now, mostly in "booklist" configuration, with the "comment" tag displayed in third line of additional informations.
Somme comments are much more longer than others and, therefore, much more higher than the cover display, so I wonder if it could be possible to get the option of truncating (in this view) this particular field to an optional length, just as it is done for the "Author" field.

An other way could be to be able to fix a "line max length" for each "column" of the book customization added information.

for your attention

Maxime

[chaley]

@mgaillard: there are some complications here.

An "additional information" box can contain multiple fields, each beginning on its own line. This makes setting a max height tricky. In theory, the max height of a box should not be less than the number of fields contained in that box, otherwise some fields will never be shown. In addition, if there are two fields being displayed, if the max height is set to 2, and if the first field takes two lines, then the second field will be hidden.

One could work around the hidden field problem using scroll bars, but unfortunately that doesn't work. The outer book list is intercepting the scroll events.

Applying limits on a field-by-field basis isn't practical.

Also note that setting a limit on either middle box must imply the same limit on the other middle box.

Given the above, the following seems possible.

• I add a max height in lines to the top box, the pair of middle boxes, and the bottom box.
• The number of lines actually displayed will depend on the amount of information. If the maximum is 10 and the number of lines to display is 3 then 3 lines will be used.
• If the number of lines to display exceeds the maximum then the "excess" information will not be visible. The field will not be scrollable.

Does that solve your problem?

Comments from other users?

[mgaillard]

Thanks, Chaley, for your answer !
And...Yes, you get it !
(actualy, no need for a scroll bar as one could click for details page if need to get further info)

The option of setting a maximum height in lines for the boxes seems a perfect solution to get control of the text side so that it approximatively fits the cover height - and actualy do not spread along several screens when showing a long "comment" field.

But you already use "line" in the options text.
Would'nt it be best to say "top row", "middle row", "bottom row", and for each "max number of lines in the xx row (default 0 means no limit)"

Any comments from other users ?

[DoctorOhh]

I may not understand your solution, but anything implemented that prevents me from viewing the entire text in my comments area I would be against.

If what you are proposing is an optional limitation then I don't care because I won't check that option.

For me comments are my last field on my list so they never get in the way.

Edit: I was thinking Book Details, not Book List.

[chaley]

Originally Posted by DoctorOhh

I may not understand your solution, but anything implemented that prevents me from viewing the entire text in my comments area I would be against.

If what you are proposing is an optional limitation then I don't care because I won't check that option.

For me comments are my last field on my list so they never get in the way.

The proposal affects displaying information in the book list, not in book details, which is I think what you are referring to.

The problem mgaillard raises is a general one: what happens if a lot of information is displayed in one of the optional book list cells? Today CC will display all the info no matter how long it is, which can cause a single book list row (cover + info) to consume more than the space available on the screen. The specific problem being discussed is "comments" but the same thing could happen with tags (if there are 100s of them), extra author-like columns with lots of names, or single-value text columns that are long.

The proposal is to specify a maximum height in displayed lines for the optional cells. There would be three such max heights: top, middle (covering both left and right as they must be equal in height) and bottom. The maximum would be adjusted up if needed to be at least as large as the number of fields displayed in that cell. Not setting a maximum would leave behavior as it is today.

[chaley]

Originally Posted by mgaillard

But you already use "line" in the options text.
Would'nt it be best to say "top row", "middle row", "bottom row", and for each "max number of lines in the xx row (default 0 means no limit)"

I need to be very careful about changing existing text. Every time I touch something all the translations should be changed, and changing vocabulary creates confusion.

Assuming this gets built, the title might be something like "Maximum height of XXX line" where XXX is "top", "middle", or "bottom". The subtext would "The maximum height of the customizable line, measured in rows of text. Enter zero for unlimited. Current value: N".

[Purple Lady]

I probably wouldn't use this, but why wouldn't you just have a maximum number of characters instead of line height? This is what you do with the author list. Maximum number of lines depends on a lot of different variables - font size, screen size, resolution.

[DoctorOhh]

Originally Posted by chaley

The proposal affects displaying information in the book list, not in book details, which is I think what you are referring to.

Well... errr... nevermind, my mistake.

Originally Posted by chaley

The proposal is to specify a maximum height in displayed lines for the optional cells. There would be three such max heights: top, middle (covering both left and right as they must be equal in height) and bottom. The maximum would be adjusted up if needed to be at least as large as the number of fields displayed in that cell. Not setting a maximum would leave behavior as it is today.

Seems like providing this ability for the book list makes a lot of sense.

[chaley]

Originally Posted by Purple Lady

I probably wouldn't use this, but why wouldn't you just have a maximum number of characters instead of line height? This is what you do with the author list. Maximum number of lines depends on a lot of different variables - font size, screen size, resolution.

Two parts to the response: number of characters in authors and number of lines in the custom book list info.

Number of characters in authors:

I just went back over the discussions in the wish list about author length. Rather a tortured history.

The initial decision to use number of characters came about because at the time the series information was included on the "second" line, which is authors except when sorting by author. This made the computation of lines rather difficult.

The topic came up again after series got its own line. You and kaufman suggested interpreting the value as lines if it was less than 25, otherwise characters. I did a test implementation of this, and the performance was very slow so I dropped it.

Since then the custom information stuff was added to the book list. The first implementation made scrolling horrible so I completely redid how the book list information was computed. Because of this change I could easily do the "25 line" suggestion. So ...

Is "number of characters" what you really want for authors? Or would number of lines be better? Note: if number of lines then the last author name could be cut somewhere in the middle, something that doesn't happen today with the number of characters.

Number of lines in custom info boxes:

Controlling the length of info in the custom boxes as number of characters would be hard, primarily because a box can contain more than one information field. Should the number be per field in the box? Total length, even though some fields are short? Or something else? Making it a line count eliminates all of this, and is also easier to do.

[Purple Lady]

Originally Posted by chaley

Two parts to the response: number of characters in authors and number of lines in the custom book list info.

Number of characters in authors:

I just went back over the discussions in the wish list about author length. Rather a tortured history.

The initial decision to use number of characters came about because at the time the series information was included on the "second" line, which is authors except when sorting by author. This made the computation of lines rather difficult.

The topic came up again after series got its own line. You and kaufman suggested interpreting the value as lines if it was less than 25, otherwise characters. I did a test implementation of this, and the performance was very slow so I dropped it.

Since then the custom information stuff was added to the book list. The first implementation made scrolling horrible so I completely redid how the book list information was computed. Because of this change I could easily do the "25 line" suggestion. So ...

Is "number of characters" what you really want for authors? Or would number of lines be better? Note: if number of lines then the last author name could be cut somewhere in the middle, something that doesn't happen today with the number of characters.

Number of lines in custom info boxes:

Controlling the length of info in the custom boxes as number of characters would be hard, primarily because a box can contain more than one information field. Should the number be per field in the box? Total length, even though some fields are short? Or something else? Making it a line count eliminates all of this, and is also easier to do.

Number of lines probably would be better. I was just curious because I remember authors was done as characters. I don't remember agreeing with kaufman about interpreting depending on the number entered. On my phone I have number of characters set to 5 and it doesn't do 5 lines. I hate when an app tries to figure out what I want because it usually gets it wrong. I would much rather specify what I want.

[chaley]

Originally Posted by Purple Lady

Number of lines probably would be better. I was just curious because I remember authors was done as characters. I don't remember agreeing with kaufman about interpreting depending on the number entered. On my phone I have number of characters set to 5 and it doesn't do 5 lines. I hate when an app tries to figure out what I want because it usually gets it wrong. I would much rather specify what I want.

The suggestion was to change to lines. The post I was referring to is here, but I overstated the level of your agreement.

Making the change opens the question: what do I do with existing values? The referred-to discussion suggested that:

• the number be in lines
• the text in the options be changed to lines
• the number of lines be limited to 25
• if a number is encounted that is larger than 25 then it assumed to be legacy and is a number of characters.

TBH I don't feel a pressing need to change this. Leaving it as it is makes for less work for me and for the translators.

[theducks]

I like the idea of a Line Limit, with some sort of indicator if it is invoked (A brick wall icon? Old time speed governor )

[Purple Lady]

Originally Posted by chaley

The suggestion was to change to lines. The post I was referring to is here, but I overstated the level of your agreement.

Making the change opens the question: what do I do with existing values? The referred-to discussion suggested that:

• the number be in lines
• the text in the options be changed to lines
• the number of lines be limited to 25
• if a number is encounted that is larger than 25 then it assumed to be legacy and is a number of characters.

TBH I don't feel a pressing need to change this. Leaving it as it is makes for less work for me and for the translators.

In that post I was agreeing that having lines would have been easier than characters - it took me a bunch of tries to get what I wanted. At this point I don't think you should change authors to lines. It could mess up what people currently have. Like my phone set to five characters so I only have one line.

[chaley]

Originally Posted by theducks

I like the idea of a Line Limit, with some sort of indicator if it is invoked (A brick wall icon? Old time speed governor )

My problem: CC has no idea if the line limit is reached.

I tried setting the Android "ellipsis" feature but it has problems, sometimes showing characters after the ... . This happens because the "read" indicator is sometimes there and sometimes not. Seeing "asd asd asd ... a" just looks strange.

Probably I will let Android cut the output however it wants, without ellipsis or other indicators.

[mgaillard]

Originally Posted by chaley

My problem: CC has no idea if the line limit is reached.

Probably I will let Android cut the output however it wants, without ellipsis or other indicators.

Well, as the default shall be 'no limit, I think the user will remember that he choosed to trukate, so a full box should mean >more to read.
A work around could be putting somewhere a little sign indicating that trunkating is active. It could even be an on/off function, but this could be confusing for the user who shall first fix the limit and then activate or de-activate it 'on the fly'.

Have a good day !