rjvbb added a comment.
> It's "KTextEditor", not "KCodeEditor". Yes, but look at the traditional meaning of a text editor, which typically means "plain text" editor. KTextEditor's design decision to use a single lineheight puts it squarely in that domain - to reply in style: `It's "TKextEditor", not "KRichTextEditor" (and even less "KWordProcessor")` ... > write CJK LaTeX articles in Kile Like it or not, TeX is code (or a universal language, depending on how you look at it). That's intentional (WYSIWIG vs. WYSIAYG and all that). And frankly, TeX code is the last place where I'd expect this kind of rendering problem: doesn't it give you US-ASCII canonical representations of every possible glyph? (I know that doesn't help manuscript readability, but hey, that's the choice you make :) ) One could also make the argument that maybe Kile should look for another rendering engine if they want to support something more advanced than KTextEditor can offer. There are Qt classes that have "rich text" support which might be more appropriate (if they offer editing support), and on the other end of the scale there's the Calligra project which probably has the required libraries. Anyway, serving a worldwide userbase isn't a new goal, but also shouldn't IMHO drag down usability to some lowest common denominator IMHO. Hence my firm request to make any chance that does have that effect optional, one way or another - I do agree with @sars . REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D25339 To: xuetianweng, #ktexteditor, cullmann, dhaumann, #frameworks, rjvbb Cc: sars, pshinjo, rjvbb, fakefred, anthonyfieroni, kde-frameworks-devel, kwrite-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, demsking, cullmann, dhaumann
