https://bugs.documentfoundation.org/show_bug.cgi?id=153904
Eyal Rozenberg <eyalr...@gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eyalr...@gmx.com
--- Comment #4 from Eyal Rozenberg <eyalr...@gmx.com> ---
(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.
