#365 closed defect (fixed)
linebreak (wrap) with insets boundaries
Reported by: | Juergen Spitzmueller | Owned by: | levon |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | lyxtext | Version: | 1.4.0cvs |
Severity: | minor | Keywords: | patch VERIFIED |
Cc: | jug@…, lasgouttes@…, winitzki@… |
Description
When using constructs like ([inset]), where [inset] might be e.g. citation or crossref, LyX allows linebreaks between inset and brackets (see screenshot). IMHO this should not be allowed.
Attachments (4)
Change History (15)
by , 22 years ago
Attachment: | linebreak.png added |
---|
comment:2 by , 22 years ago
No, this is only a plain cosmetic issue inside the LyXview. In the output, everything is o.k.
comment:4 by , 22 years ago
Version: | 1.2.0cvs → 1.2.0 |
---|
Mass move to 1.2.0 - grep out the bugspam with "Dharma ex one+one"
comment:5 by , 22 years ago
Cc: | added |
---|---|
op_sys: | Linux → AIX |
rep_platform: | Other → All |
Summary: | linebreak with brackets and insets → linebreak (wrap) with insets boundaries |
Another symptom is stuff like pre-$4x2$
This is a tricky problem I guess...
comment:6 by , 22 years ago
Cc: | added |
---|
A comment from Juergen V in method LyXText::nextBreakPoint
tells what happened.
we have to check this separately as we could have a
lineseparator and then the algorithm below would prefer
that which IS wrong! We should always break on an inset
if it's too long and not on the last separator.
Maybe the only exeption is insets used as chars but
then we would have to have a special function inside
the inset to tell us this. Till then we leave it as
it is now. (Jug 20020106)
Juergen, can you tell us more about why we need that?
comment:7 by , 22 years ago
Status: | new → assigned |
---|
It's easy if we have an inset which is _much_ larger then the screen it would
vanish on the right side of the text. If we want that (and I don't think so),
we would have to deactivate this code. Now the insets are behaving like normal
chars and that is IMO the right behaviour. Try to type a long line without space
and you'll see that the row breaks. What we could do is make the algorithm more
intelligent and instead of breaking only on the insetstart save also the last
break char position and see if the size of the inset and the whole chars since
the last break character is not longer than the WorkArea then we can break on
that spot otherwise we should break on the inset. Actuall this would be a good
idea IMO ;), so I would say go for it.
by , 21 years ago
Attachment: | lyxbreak_expanded.png added |
---|
linebreak problem, float expanded (but in same paragraph)
comment:8 by , 21 years ago
I have a similar problem, but its breaking in the middle of a word. I have a
finished sentence with a float at the end and am inserting a new sentence
between the two. The text gets broken at the last possible point, which happens
to be in the middle of 'The'; see screenshots. Breaking before 'The' would make
more sense to me.
Output is fine, problem only occurs in the gui.
comment:9 by , 21 years ago
Keywords: | patch added |
---|---|
Owner: | changed from | to
Status: | assigned → new |
Version: | 1.2.1 → 1.4.0cvs |
Juergen's explanation doesn't make much sense. I'm reworking this code now and
looking at getting this behaving sanely. If a word "word" won't fit entirely,
you should break before the w. '(' is not a separator. This applies to insets
as much as it does to normal characters. I have fixed this bug and have no
regressions wrt insets dissappearing off the side of the screen.
If we have a solid row with no breakpoints at all, then we can break just as
we do. I'd love to hear an explanation as to why insets are different at all
from Juergen.
Also, why on earth do we do these ->display(false) things here ? It's totally
the wrong place, this function should be entirely const.
William, no idea what to make of that, I can't reproduce it.
comment:10 by , 21 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed this. Juergen please test it.
Screenshot with wrong linebreak