D25339: update lineHeight if boundingRect indicates a larger value.

[Xuetian Weng]

xuetianweng marked an inline comment as done.
xuetianweng added a comment.


  In D25339#665432 <https://phabricator.kde.org/D25339#665432>, @rjvbb wrote:
  
  > With "we've ever seen" you do mean that lineheight only changes when a line that requires it scrolls into view?
  >
  > >   Though line height won't shrink during the edit phase, it will back to the actual value upon save.
  >
  > Have you tried to reset the max. lineheight on each redraw (I presume the scrollbars could give you a signal that a view scroll/jump was initiated, if need be). 
  >  Something tells me that it'd be nicer if lineheight always is as small as possible. Imagine you're using a smallish window to edit a document that just has some of these "offending", much higher characters at the bottom. If it gets into view only once, lineheight increases and it's as if you lose a lot of screen estate until you save the document. Now I mustn't be the only one who often doesn't save for a while, esp. when doing things like moving blocks of text around, and it's exactly in that kind of scenario where having to save to get a more space-efficient rendering back can be very annoying.
  >
  > As long as you can determine the max. lineheight required for the view that's about to be drawn before the view is actually drawn there should be no glitches. You'd just see a jump in lineheight and there would probably be an interesting problem to tackle with edge cases where the higher glyphs fall outside the view area because of the increased lineheight, but that's something your current implementation cannot avoid completely either. As to the changing lineheight: I think users will understand why it happens and get used to it. It's comparable to what you see in graphics programmes that show cursor co-ordinates next to the cursor; that indicator has to jump when it would get "pushed out" of the view, and that doesn't even feel weird.
  >
  > I presume your new approach would work not just for CJK characters, but also for anything else that changes the lineheight. That's and advantage but could also lead to regressions for some (who never use CJK characters or who, like me, wouldn't care how they display because they can't read them anyway). Emoticons come to mind; here too I don't really care if they get cut off. Scrap that, I *really* don't care if they are...
  
  
  To be honest,  I didn't see issue about color emoji (until select them). My "fill" gap code seems can't make color emoji bitmap transparent.... The fill gap code is indeed a hack.
  
  Probably when I get time I might try to make it able to render view with different height...
  
  As for higher line, it might not as bad as you thought as it actually might improve readability for many people.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D25339

To: xuetianweng, #ktexteditor, cullmann, dhaumann, #frameworks, rjvbb
Cc: brauch, sars, pshinjo, rjvbb, fakefred, anthonyfieroni, kde-frameworks-devel, kwrite-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, demsking, cullmann, dhaumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20200507/31b0b075/attachment.htm>