[konsole] [Bug 364992] [Feature request] Add an option to disable the embedded "drawLineChar" mechanism

[Yi Yang via KDE Bugzilla]

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

--- Comment #4 from Yi Yang  ---
It's amazing to see some code written 11 years ago which fixes a bug reported
13 years ago can still work.

However, as I have argued, the available fonts have changed, and the available
screen resolutions have changed. Maybe it's time to revisit this patch.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 349350] Some monospaced fonts missing in the fonts menu

[Yi Yang via KDE Bugzilla]

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

--- Comment #3 from Yi Yang  ---
Also, Konsole is actually sophisticated enough to handle double width
characters. No reason to keep the users from actually using such a font.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 349350] Some monospaced fonts missing in the fonts menu

[Yi Yang via KDE Bugzilla]

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

Yi Yang  changed:

   What|Removed |Added

 CC||ahyan...@gmail.com

--- Comment #2 from Yi Yang  ---
A problem with auto-detecting monospace fonts is, some monospace fonts are not
really monospace, and they might have a good reason to do so.

Horacio Sanson has a good reason: he wants to use Japanese characters. Nobody
would make the kanas and especially kanjis as wide as latin letters. Instead,
these are "double width" letters that occupy as much space as two latin
letters. Consequentially it doesn't satisfy the usual definition of "monospace"
fonts.

I see it a deficit of the definition rather than a deficit of the font or the
user. After all, whoever made that definition probably had absolutely no
knowledge of how East Asian Typography works.

China+Japan+Korea has about 1.6 billion population, and there are also oversea
users. Please, do something so that CJK users aren't completely ed by a
overly pedantic definition of "monospace".

I'd say please add an option that says "I know what I am doing and please let
me choose from all system fonts". That will satisfy everyone.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 364992] [Feature request] Add an option to disable the embedded "drawLineChar" mechanism

[Yi Yang via KDE Bugzilla]

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

--- Comment #2 from Yi Yang  ---
Created attachment 99796
  --> https://bugs.kde.org/attachment.cgi?id=99796=edit
Screenshot showcasing worst-case scenario for the built-in line drawing
mechanism

The command was
echo -e '╫\033[01m╫'
and as you can see, one can barely see it's two lines, and it's impossible to
tell it in bold style.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 364992] [Feature request] Add an option to disable the embedded "drawLineChar" mechanism

[Yi Yang via KDE Bugzilla]

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

--- Comment #1 from Yi Yang  ---
This should be fairly easy to implement:

In TerminalDisplay.cpp, method TerminalDisplay::drawCharacters, there is a
if-clause calling isLineCharString(text) to decide whether to draw something
with built-in line drawing mechanism or to draw it with the chosen font.

Probably one could add an option that forces one to draw with the chosen font
there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 364992] New: [Feature request] Add an option to disable the embedded "drawLineChar" mechanism

[Yi Yang via KDE Bugzilla]

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

Bug ID: 364992
   Summary: [Feature request] Add an option to disable the
embedded "drawLineChar" mechanism
   Product: konsole
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: font
  Assignee: konsole-de...@kde.org
  Reporter: ahyan...@gmail.com

Currently, for certain box drawing characters, Konsole hardcode their shapes
disregarding the font used. This has a few consequences:
* When using a high quality font fine tweaked for use in a terminal, the
quality becomes lower. The designer might have chosen better line widths, or
different corner styles, which are all lost.
* When using a high resolution screen, the pixel level line drawing done by
Konsole produces unrecognizable characters. The problem worsens when
double-line box drawing characters and bold font are involved.

So I'm not asking to remove this line drawing feature, since it's still useful
when one uses an inadequate terminal font. However, since nowadays high quality
terminal fonts are much easier to come by, with all kinds of license from open
source to free-of-charge to commercial, at least we should allow the user to
use their box-drawing characters from their fonts.

While this is a feature request, it's also a bug report, in the sense that the
letter "╫", in bold style, is rendered insanely poorly, to the point that it's
simply impossible to tell it's actually double vertical line and single
horizontal line.

Reproducible: Always

Steps to Reproduce:
Copy the following character to Konsole: "╫".
For worse result, set the font to bold.
For worse result, use a high resolution screen.
Grab quality free fonts, and set them. You will find the shape of "╫" does not
change.

Actual Results:  
You will see the glyph "╫", always drawn with lines of width of exactly one
pixel. If you set it to bold, the vertical lines becomes two pixels wide, and
the gap between the two vertical lines completely disappears.

if you use a high resolution screen, you might not be able to spot it's two
vertical lines without a magnifier.

When you resize the terminal fonts, the line width of "╫" does not change,
causing style inconsistency with your console font.

Expected Results:  
Since this is a feature request, I wish we could have an option to simply use
the box drawing glyphs built in the console font I chose.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #13 from Yi Yang  ---
Hi all,

I upgraded to Plasma 5.6 today. It seems to be handling hi-res screens in a new
way (by handling font DPI better it seems), so that the "scale display" option
is no longer needed in most common cases. Therefore, even if the Okular bug
still exists, its severity becomes even lower.

I'm not sure if this means this bug should be closed. I leave that to your
decision. But I think it's my duty to report on the progress. Thank you for all
your hard work, people ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #12 from Yi Yang  ---
Relevant documentations:
relevant flags: http://doc.qt.io/qt-5/qt.html
QScreen and QPixmap with their new addition in Qt 5.5 or 5.6:
http://doc.qt.io/qt-5/qscreen.html
http://doc.qt.io/qt-5/qpixmap.html

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #11 from Yi Yang  ---
By reading more documents and doing more experiments, things are now clear.

Qt 5.6 introduces a new option, called "High DPI Scaling", which is both
controllable form environment variables and application-wise options
(Qt::AA_EnableHighDpiScaling and Qt::AA_DisbleHighDpiScaling). This gives us
solution A: temporarily force Qt::AA_DisbleHighDpiScaling. This solution does
uglify menus and icons, though.

The more complex solution B needs more code refactoring. The key is to realize
that you are using "device-independent geometry" while the pixmap inside
QPixmap are using real physical values. You need to get this magical value from
QScreen::devicePixelRatio() and set them to QPixmap::setDevicePixelRatio().
This step might be simplified by "Qt::AA_UseHighDpiPixmaps". I'm not sure, the
documentation here isn't clear.

But the even harder part is you need to rewrite the image rotation and cropping
code, since now you are cropping the image to (widget size *
devicePixelRatio()). It's a bit tricky and many code in different locations
made the assumption that widget size = the pixmap size in it, which no longer
holds and thus broken code is scattered everywhere.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #8 from Yi Yang  ---
OK, I digged the source code a bit more.

The DPI calculation code at core/utils.cpp line 63-81 returned (93.6, 93.6),
while my actual DPI, as reported by Xorg.log, is (187, 189). Apparently
QScreen::physicalDotsPerInchX() and QScreen::physicalDotsPerInchY() are
returning something not quite physical, when Plasma 5 "scale display" gets
enabled.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #7 from Yi Yang  ---
OK. I tried KDE Plasma 4 + Kdelibs4/Okular. There were no render resolution
problem.

That said, there were no "scale display" option in systemsettings in this
setup. So this might indeed be the difference.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #6 from Yi Yang  ---
Every application is, in principle, independent of the desktop environment I
use.

However, when I'm reporting a bug, I'm trying to include information about my
DE. I think this makes sense. In principle they are independent. But when you
have a bug, you are no longer so sure.

Anyway, I'll definitely try KDE Plasma 4 + KDElibs4/Okular & KDE Plasma 5 +
KDElibs4/Okular some time later and report back. Last night (as in GMT+8
timezone) I had less free time than expected, so sorry no experiment results
for now.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #4 from Yi Yang  ---
Luigi, yes, I am using the Frameworks version of Okular. To be sure this bug is
still around I even git pull'ed and compiled it again. So to be precise I'm
reporting the newest version of frameworks branch is still having this
resolution problem.

I will try the kdelibs4 version of Okular and report back. I don't remenber my
KDE SC 4 comes with "scale display" option though. Maybe I need a full system
upgrade or something.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

--- Comment #3 from Yi Yang  ---
To be honest, your terminology change from KDE 3 to KDE SC 4 to {Insert a
myriad names here} 5 is absolutely terrible. I have no idea how to even call
it.

And, yes, i checked and it is Plasma 5. I didn't know systemsettings is part of
Plasma instead of kdelibs or KF. It's kind of counterintuitive. Why should I,
as a user instead of a KF/Plasma/Kdelibs developer, know about this though? :|

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 362856] New: [Frameworks] Wrong render resolution, possibly caused by KDE 5 "Scale Display"

[Yi Yang via KDE Bugzilla]

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

Bug ID: 362856
   Summary: [Frameworks] Wrong render resolution, possibly caused
by KDE 5 "Scale Display"
   Product: okular
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: ahyan...@gmail.com

KDE 5 includes a new feature, "scale display", for better support for high
resolution screens. To enable it, go to settings > Display and Monitor >
Display Configuration > Scale Display.

I use a 4K screen and I enabled 1.5x scale display.

I noticed that all PDFs are rendered in a way that looks extremely bad. A
closer look reveals that the PDF is somehow rendered in a way, so that the
rendered bitmap consists of 2x2 regions of the same color. In other words,
Okular rendered PDFs with 1/2 of actual resolution.

I tried to dive into the source code. Apparently, the render resolution is
decided  then sent to the PDF module via a PixmapRequest. Therefore, I guess
this is not only a PDF problem, but a global one, hence the general component
instead of PDF backend in this bug report.

The geometry sent in PixmapRequest comes from uncroppedWidth() &
uncroppedHeight(), which in turn come from m_uncroppedGeometry. The calculation
of m_uncroppedGeometry looks somewhat magical, which is where I stop looking at
the code and decide to write a bug report instead...

The KDE5 Scale display feature is the most possible cause of this problem.
However, I'll happily give you more information if that's needed for diagnosing
this bug. 

Reproducible: Always

Steps to Reproduce:
1. Enable KDE 5 scale display.
2. Open Okular, open a PDF.
3. Look at how text is rendered (other things are also affected, but text is
more important and ubiquitous)

Actual Results:  
Okular renders at half of actual resolution, then scale the result, producing
poor results.

Expected Results:  
Okular renders at actual resolution.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 359223] [framework] okular cannot open files with spaces in path or name (both from terminal and from dolphin)

[Yi Yang via KDE Bugzilla]

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

Yi Yang  changed:

   What|Removed |Added

 CC||ahyan...@gmail.com

--- Comment #3 from Yi Yang  ---
Same for me. This is actually one of the more annoying bugs for me, since most
of my files reside on paths with spaces in it, making Okular nearly unusable.
Worse, it seems to try to expand symlinks so I can't even use symlinks to
circumvent this bug.

-- 
You are receiving this mail because:
You are watching all bug changes.