Bug 342185

Hi!

Could you attach the backtrace of the crash for us?

I guess it's this line, is it? Thank you.

Application: Krita (krita), signal: Aborted

Er no -- do you have the debug packages installed? If not, please install those and then make the crash happen again. You should be getting a bug report window that includes a "backtrace" tab, which should contain a lot of text. We need all of it...

Created attachment 90115 [details]
Drop Caps + fixed line spacing value lower than 25.00, causes the crash of Krita - Backtrace

Drop Caps + fixed line spacing value lower than 25.00, causes the crash of Krita - Backtrace

Comment on attachment 90115 [details]
Drop Caps + fixed line spacing value lower than 25.00, causes the crash of Krita - Backtrace

Thanks!

Thank you. Incidentally, regarding the point 2 of the "Steps to Reproduce" above, I've better noticed that:

The checkbox isn't enough by itself to activate the drop caps. Besides that, one also has to increase the amount of "Number of lines it covers".

Could you check whether this is also fixed now? I cannot reproduce it anymore using the steps given.

Resolved with the new build. I had checked also a few days ago but the issue was still there. But now it's completely resolved. Thank you very much!

still happens - and i'm able to reproduce in calligra words too

On Fri, 30 Jan 2015, Alex Demko wrote:

> Although the submitter reported this bug resolved, I think it's still
> open, as I'm able to reliably reproduce it in the most recent
> calligra/2.9 branch. If I increase Drop Caps->Number It Covers to say
> 4, and then keep decrementing Indents/Spacing->Line Spaces->Fixes
> lower and lower, around 9 or so I can get it to crash. I assume it's
> all dependant on the font any ways.
>
> The bug triggers the assert in:
>
> void KoTextLayoutArea::setBottom(qreal bottom)
> {
>    d->boundingRect.setBottom(bottom + qMax(qreal(0.0),
> d->verticalAlignOffset));
>    Q_ASSERT_X(d->boundingRect.top() <= d->boundingRect.bottom(),
> __FUNCTION__, "Bounding-rect is not normalized");
>    d->bottom = bottom;
> }
>
> Which is understandable because bottom in my case is -9.57456e-13, aka
> -tiny. With top()==0 and bottom()==-tiny, it's not normalized. How did
> it become -tiny and not real 0? It seems in this bit of code:
>
> libs/textlayout/KoTextLayoutArea.cpp:1295:
>
>        d->neededWidth = qMax(d->neededWidth, line.naturalTextWidth()
> + d->indent);
>
>        if (!runAroundHelper.stayOnBaseline() &&
> !(block.blockFormat().hasProperty(KoParagraphStyle::HiddenByTable)
>         && block.length() <= 1)) {
> // d-> is -6 and maxLineHeight is 6
>            d->y += maxLineHeight;  // <---- the culprit
> // d->y is now -tiny
>            maxLineHeight = 0;
>            d->indent = 0;
>            d->extraTextIndent = 0;
>            ++numBaselineShifts;
>        }
>
>
> It seems -6 + 6 gives us -tiny, which is understandable as this all in
> real numbers and round off errors are expected.

Git commit 91cdb01d2aae13f7dfb67182913e75fa5166f699 by C. Boemann.
Committed on 30/01/2015 at 12:58.
Pushed by boemann into branch 'calligra/2.9'.

The dropcaps themselves should not be subjected to linespacing rules - only the actual lines of text should be

This bug resulted in a crash because the dropcap became smaller in height than it was displaced - effectively
painted completely above the paragraph - this resulted in a correct assert

M  +23   -19   libs/textlayout/KoTextLayoutArea.cpp

http://commits.kde.org/calligra/91cdb01d2aae13f7dfb67182913e75fa5166f699