[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 --- Comment #5 from Eyal Rozenberg --- Finally, I believe this is a dupe of 46023, since it suggests a specific kind of implementation rather than a different feature. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 Eyal Rozenberg changed: What|Removed |Added CC||eyalr...@gmx.com --- Comment #4 from Eyal Rozenberg --- (In reply to ajlittoz from comment #0) First let me ask about the motivation. I can see two kinds: 1. Limitation of the text adopted for indices/tables/bookmarks; 2. Implementation of inline lists (and this would require some more description which you have not provided) Is there something else? Now, about how such paragraphs would work: > - Line break is suppressed. > - Space below of run-in style is ignored Don't you mean constrained to 0? > - Bottom border is suppressed (though it is expected users won't request > borders) How is that expected? Wouldn't the user expect a border below the part of the inline paragraph on the bottom line? Or perhaps, for there to be a border if continuing paragraph doesn't have one? Also, what about different line spacing values for this paragraph and the next one? Or multiple inline paragraphs on the same line? > - In case of justification, last line justification is suppressed to revert > to left (adapt for RTL) What if the inline paragraph is RTL, and the next paragraph is LTR? For that matter, what if you have inline paragraphs on the same line with Left, Center and Right alignment? > - Left indent is used as usual because it defines the starting position of > the line No it doesn't, at least not necessarily. Suppose I have two LTR inline-paragraphs within the same line. The first one is right-aligned, the second one is left-aligned. And, for that matter, what happens with the overlaps? How do you order overflow from these two paragraphs on the next line? ... and what do you do when you have 3, or 4, inline paragraphs on the same line? > - Right indent is pointless because we know we have a partial line (A run-in > paragraph is allowed to span several lines; only the last line receives > special handling). As discussed above, not true. > - By definition of run-in, the base line is the same for the run-in > paragraph and the subsequent one. What if the "run-in" is in English, with baseline at the bottom, while the next paragraph is in Devangari, with baseline at the top? > The new paragraph text is laid out immediately after the end of the run-in > paragraph at a distance defined by the "spacing" parameter of the option. > Start of paragraph actions are suppressed. > > - Spacing above is suppressed. > - Top border is suppressed. That would be unexpected by the user. If they specified spacing above or a border, they expect to have them. This is not like the run-in paragraph's style, for which you can assume the user knows in advance not all properties are to be respected. > - First line indent is ignored (because text is considered a continuation of > run-in para). > - Left indent is ignored on first line but becomes active for second and > subsequent lines. > - Right indent is used as usual. As discussed above, you can't assume where on the first line the run-in paragraph is to be placed. > - First line alignment is honoured just the same as the other lines > Note: for the purpose of alignment, run-in paragraph last line can be > regarded as a mini-frame and its bounding box passed as such to the layout > algorithm if possible. > Such a run-in paragraph style keeps all the other properties of paragraph > styles So, here's the thing. Actually, what you describe necessarily must loses essentially all properties of a paragraph: * Spacing (and probably indentation) * Border * Direction * Alignment * (Tabs - probably) * Drop Caps - by your suggestion There's almost nothing remaining that's not character properties, except perhaps list item association, and even that's not trivial because of positioning and spacing. With this in mind, I don't think these can properly be described as inline paragraphs. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 --- Comment #3 from Eyal Rozenberg --- (In reply to Regina Henschel from comment #1) Note that in CSS, marking an object with display: inline makes it not-a-block-object, so that all those style aspects regarding block objects don't apply to it. In other words, it's like saying "this paragraph is not really a paragraph, it's basically like an HTML span or other inline elements.. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 --- Comment #2 from ajlittoz --- (In reply to Regina Henschel from comment #1) > Created attachment 185685 [details] > Inline heading by CSS in HTML > > Do you look for something like display:inline as known from CSS in HTML? > (See attachment) I think the closest would be display:inline-block but it is not exactly the same. My proposal describes modifications to the raw CSS behaviour. In CSS, boxes are drawn independent from each other once their z-ordering has been determined. Here, I'd like some sort of merging between the two boxes (if this makes sense). If however you think that implementing some equivalent to display:inline[-block] is easier, why not? I nevertheless want to point out that the feature must remain consistent with the notion of text flow (or rather reading order). If "inline" implementation is based on frame engine, wrap mode must be forced to After so that no subsequent text is place at left of heading. Similarly, no subsequent text must be found above the heading. These two constraints coarsely guide where the block is positioned, with the additional factor that baselines must be aligned as much as possible. Your suggestion even allows the "drop caps" effect but user must be particularly careful in style configuration if such a layout is desired. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #1 from Regina Henschel --- Created attachment 185685 --> https://bugs.documentfoundation.org/attachment.cgi?id=185685=edit Inline heading by CSS in HTML Do you look for something like display:inline as known from CSS in HTML? (See attachment) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 ajlittoz changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||7452 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 ajlittoz changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=48 ||459 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153904] [ENHANCEMENT] Allow for inline (= run-in) paragraph styles
https://bugs.documentfoundation.org/show_bug.cgi?id=153904 ajlittoz changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=46 ||023 -- You are receiving this mail because: You are the assignee for the bug.
