Bug 409380

Summary:	Formatting by KSyntaxHighlighting::SyntaxHighlighter of normal text seems to be dropped partially (Qt >=5.13.0/5.12.4)
Product:	[Frameworks and Libraries] frameworks-syntax-highlighting	Reporter:	Friedrich W. H. Kossebau <kossebau>
Component:	theme	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	3ndymion, bugseforuns, mrgeekley, sk.griffinix
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://commits.kde.org/kio-extras/4ec12a850e258de49d2ed7103f82b468939164c1	Version Fixed In:
Sentry Crash Report:

Description Friedrich W. H. Kossebau 2019-07-01 16:54:12 UTC

So when we thought bug 406821 (Dark UI color theme breaks default LightTheme) was fixed, seems newer Qt fights back somehow and screws up things in some yet-to-be-understood way (given I could not see any code change on KDE side).

I am a bit puzzled as I had tested the patch applied as bbc465981bd55ca5449f5d22e972fccbe994e24f to syntax-highlighting to fix this bug and remember that I very well could confirm the behaviour to have been fixed.

But now that I run latest KF 5.59 and Qt 5.13.0, I see that the bug symptom seems to have reappeared somehow.

When I add "qDebug() << textDocument.toHtml();" to the textthumbnailer, the exported HTML does not contain any explicit foreground/text markup, here e.g. for a .txt file with the content "This is some example text."
--- 8< ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'Droid Sans'; font-size:9px; font-weight:400; font-style:normal;">
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">This is some example text.</p></body></html>
--- 8< ---
and as result the text color seems to be rendered again depending on the current UI palette color if drawing with a QPainter on a pixmap, like in the thumbnailer (https://cgit.kde.org/kio-extras.git/tree/thumbnail/textcreator.cpp)

Strange enough, when doing the same for printing (like with the https://cgit.kde.org/syntax-highlighting.git/tree/examples/codepdfprinter/codepdfprinter.cpp), we get black text in the PDF, despite the same UI color theme.

Sadly I do not remember exactly what it was before, but if asked before I would have said there was more explicit formatting in the generated HTML, and thus printing and pixmap rendering yield the same colors used. Not sure now.

Will see to do some closer look later this week.

Comment 1 Friedrich W. H. Kossebau 2019-07-01 17:18:19 UTC

And I meant the "formatting in the generated HTML" rather as indicator, not the cause, given this is also just "rendered" from the actual data.

Comment 2 Friedrich W. H. Kossebau 2019-07-01 19:57:31 UTC

Some more findings, without yet giving me a any clue (though also being a noop when it comes to QTextDocument & formatting):

Adding to the thumbnailer
qDebug() << textDocument.firstBlock().text() << textDocument.firstBlock().charFormat().foreground();
I get for the .txt file example above:
"This is some example text." QBrush(QColor(ARGB 1, 0, 0, 0),NoBrush)

Which rather looks like a formatting with which one should see the text rendered as black?
Strange enough I see the same QBrush output also with files of some formats where the highlighting yields proper results (qml, dot, xml, patch, json, cpp, rs)...

Comment 3 3ndymion 2019-07-02 14:15:43 UTC

Hi.  Sorry I took so long.  I think the most I could do to help here is to confirm what you already know.  It is indeed the color scheme that is related to this problem.

I always use Breeze Dark, but when I switched back to normal Breeze with the bright colors, I opened up a new Dolphin window, & suddenly, the text file previews work perfectly fine again.  Since I don't like looking into the sun, I put it back on Breeze Dark, & now, the text previews no longer work again.

Could it possibly be a case of trying to render white text on a white background somehow???

Comment 4 3ndymion 2019-07-08 23:56:11 UTC

I just realized... from looking at the screen close & at a different angle, I can see that the text preview actually is there.  It is indeed nearly white text on a white background.  I never realized that until just now.

But I guess that's what you were saying in your explanation.  My apologies, I had a bit of trouble understanding everything you wrote.

Comment 5 Patrick Silva 2019-09-07 02:15:30 UTC

*** Bug 411656 has been marked as a duplicate of this bug. ***

Comment 6 Ilia Kats 2019-12-11 20:13:12 UTC

Git commit 4ec12a850e258de49d2ed7103f82b468939164c1 by Ilia Kats.
Committed on 11/12/2019 at 20:08.
Pushed by iliakats into branch 'master'.

fix preview of plain text files when using dark theme
Related: bug 406821
Differential Revision: https://phabricator.kde.org/D25891

M  +3    -1    thumbnail/textcreator.cpp

https://commits.kde.org/kio-extras/4ec12a850e258de49d2ed7103f82b468939164c1

Comment 7 Geekley 2020-10-24 22:42:03 UTC

Still happening: https://bugs.kde.org/show_bug.cgi?id=406821