[okular] [Bug 479070] Okular hangs when editing Chinese characters in inline note annotation

[Keyu Tao]

https://bugs.kde.org/show_bug.cgi?id=479070

--- Comment #20 from Keyu Tao <taoky1999 at gmail.com> ---
(In reply to Keyu Tao from comment #19)
> (In reply to Keyu Tao from comment #18)
> > (In reply to Albert Astals Cid from comment #16)
> > > Not an okular bug, but a poppler bug.
> > > 
> > > https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1482
> > 
> > https://gitlab.freedesktop.org/poppler/poppler/-/commit/
> > 8a9f1d3a84a9f3d66cd353b7fe1aef0b65a37c08 does not seem to have this fixed.
> > I compiled the latest master branch poppler locally, LD_PRELOADed when
> > running okular, 
> > and I could still easily reproduce this bug.
> > 
> > Going to try debugging after lunch.
> 
> Very weird: even when Okular is responding, I find that one thread is
> already in dead loop inside `drawMultiLineText()` (when it does not have
> enough space and you type in non-ASCII chars): 
> 
> In this case `textLayouter.consumedText` is 2 and `text.hasUnicodeMarker()`
> is true, thus it keeps `i += 0` and it could never leave the `while (i <
> text.getLength())`.

OK I have figured it out:

- `Annot::layoutText` first `*i = 2;` to skip UTF-16 BOM, then `*i += 2` in
while as it is unicode (UTF-16), and then as it meets new font needed, it `*i
-= unicode ? 2 : 1;`, thus finally `*i = 2`.
- In `HorizontalTextLayouter` constructor, `availableWidth` is a negative
number (as it is too small), so `consumedText` would just be `2` -- consumes
nothing but BOM.
- `drawMultiLineText` does not expect textLayouter eating no characters, thus
resulting a dead loop.

-- 
You are receiving this mail because:
You are the assignee for the bug.