LibreOffice calculates line height based on aspects of the font(s) used for the characters on the line. However, occasionally, you may want to keep the line height uniform despite the line containing a couple of characters in another language, with the computed line height being different. You may not want those characters to result in a discrepancy in the line height - even at the cost of there being less space between the top of those characters and the bottom of the previous line. I would like to be able to mark such characters to be ignored for line height computation.
I'm sorry, but I don't like it when every user's idea could become a new development. Apart from this case seems to be of rather limited use. I prefer not to imagine the implications on the code for its development, with the risk of new bugs that it may cause. For me, clearly -1 (wontfix)
Can see the utility to this, but not clear ODF can accommodate. We're already wrestling with issues like bug 71080 and bug 136448 for Drop caps handling, seems excluding characters/word text runs within a paragraphs line height metrics would require similar. Kind of complex though, as not just the line height but also the text width for the span would need to be tracked to avoid overrun and place correctly. We currently can place draw shape text boxes to provide this kind of layout (wrap and anchor). But in-line as "ignored" paragraph text could be of use--think writing mixed polyglot content in line.
(In reply to V Stuart Foote from comment #2) > Can see the utility to this, but not clear ODF can accommodate. > > We're already wrestling with issues like bug 71080 and bug 136448 for Drop > caps handling, seems excluding characters/word text runs within a paragraphs > line height metrics would require similar. > > Kind of complex though, as not just the line height but also the text width > for the span would need to be tracked to avoid overrun and place correctly. > > We currently can place draw shape text boxes to provide this kind of layout > (wrap and anchor). But in-line as "ignored" paragraph text could be of > use--think writing mixed polyglot content in line. s/71080/bug 70180/
(In reply to m.a.riosv from comment #1) > I'm sorry, but I don't like it when every user's idea could become a new > development. 1. This is a disingenuous way to treat bug reports / feature requests. These are opened by a single user, but typically regard usage scenarios encountered by a large number of users. 2. If a user has a good idea, their report should be confirmed. That does not mean developers are supposed to place it high on their priority list - that's a different kind of decision. > Apart from this case seems to be of rather limited use. That's the only relevant argument. But - I disagree. Why do you believe that there is limited use for embedding one/a small number of different-language-group words in a paragraph?
(In reply to Eyal Rozenberg from comment #0) > LibreOffice calculates line height based on aspects of the font(s) used for > the characters on the line. However, occasionally, you may want to keep the > line height uniform despite the line containing a couple of characters in > another language, with the computed line height being different. For that purpose you can set the line space to a fixed value.
(In reply to Eyal Rozenberg from comment #0) > I would like to be able to mark such characters to be ignored for line > height computation. This could have been a solution but... (In reply to Regina Henschel from comment #5) > For that purpose you can set the line space to a fixed value. => INVALID
Confirm that yes you can set the Paragraph line spacing height to a *Fixed* value (as pts, in, cm) rather than the other *Proportional/Percentage* spacings. And that text runs inserted into a paragraph with differing fonts at differing font metrics or pt size will be picked up as Text runs discrete from the Paragraph text in the resulting document XML. But we eliminate any font metric derived proportional PS line spacing and any ability to register true against a proportionally spaced reference paragraph. The ask of retaining proportional spacing for an entire paragraph via PS but excluding from line height calculation text spans by selection (including CS) or input method seems like reasonable UI. Ask is to honor font metric of some PS base font as proportional but to allow the resulting XML to encode text spans with alternate metrics without disrupting the proportional line spacing. No different than done with Fixed line spacing now. Just requires UI to accomplish beyond DF of a fixed line height.
(In reply to V Stuart Foote from comment #7) > No different than done with Fixed line spacing now. > Just requires UI to accomplish beyond DF of a fixed line height. What exactly do you have in mind that needs to be added in addition to the line spacing options we have (the "At Least" option sounds very close to the request) being either defined in the format or required in addition by many users?
No reply, resolving ISD
(In reply to Heiko Tietze from comment #8) > What exactly do you have in mind that needs to be added in addition to the > line spacing options we have (the "At Least" option sounds very close to the > request) being either defined in the format or required in addition by many > users? Nothing needs to be added to the line spacing option. It's true that if the line spacing is "exactly 123", then this feature would have no effect - but setting an exact spacing is not the use case here. The spacing will change depending on what happens on each line - and it might not even be the same between lines, who knows. Or if the paragraph style changes. Or if other characters' DF changes. etc. What I had in mind is a per-character setting. It's a bit like "hidden", except that only the height aspect is hidden. (In reply to V Stuart Foote from comment #2) > Kind of complex though, as not just the line height but also the text width > for the span would need to be tracked to avoid overrun and place correctly. No different tracking should be necessary for width than what's happening now; I only want to suppress line-height accounting. > We currently can place draw shape text boxes to provide this kind of layout > (wrap and anchor). That seems like overkill; a textbox is "expensive" in many ways; and I don't want it to feel like anything other than inline characters.
Still favor this request, there is utility if the ODF can hold the "selected" spans with "ignored" height chars without clobbering PS.
Obviously we have yay and nay camps. Keeping the ticket for volunteers/ODF change.