T10812: KDE Applications

[Luca Beltrame]

lbeltrame added a comment.


  In T10812#182255 , @ngraham wrote:
  
  >
  
  
  
  
  > e "GNOME" in their name (e.g. "GNOME Chess", "GNOME Photos", etc). Despite 
this, I see no indication that people confusedly think you can't use GNOME's 
apps without the GNOME DE itself. People seem to happily
  
  For KDE software it happend *so many times* over the course of the years:
  
  - "App XXX is cool but I don't want to install KDE"
  - "I don't need KDE, so I won't use App YYY"
  
  This was the first, real reason the rebranding was agreed upon. 
  And for example in openSUSE we have people that use KDE applications with 
totally different setups (e.g. XFCE).

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, lbeltrame
Cc: lbeltrame, ltoscano, cfeck, aacid, #yakuake, #okular, #dolphin, #kate, 
#spectacle, #konsole, #gwenview, #kde_pim, #kde_games, #kde_applications, 
ngraham

[okular] [Bug 406646] Okular Can not really change page color

[widon1104]

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

--- Comment #6 from widon1104  ---
Finally I find out a software support linux called foxit which can change
background color successfully.
You can download foxit reader in: https://www.foxitsoftware.com/pdf-reader/
After install this software you can use Edit->preference->General->Page
Background to change the background color to the document I upload

foxit reader satisfy my need, but this software no longger update for a long
time.

I still hope okular can fix this bug.

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

[okular] [Bug 406646] Okular Can not really change page color

[widon1104]

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

--- Comment #5 from widon1104  ---
Created attachment 119493
  --> https://bugs.kde.org/attachment.cgi?id=119493=edit
win10 adobe reader success change backgroud color

I use win10 adobe reader success change the same document background color to
green.

Please do not close this bug so quickly.

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

T10812: KDE Applications

[Nathaniel Graham]

ngraham added a comment.


  In T10812#182253 , @ltoscano wrote:
  
  > In T10812#182252 , @cfeck wrote:
  >
  > > Yes, we have been trying hard, but did we succeed? Would someone just 
stop using Okular, because it is shipped with the Plasma bundle instead of the 
KDE Applications bundle?
  >
  >
  > I fear it will happen, yes.
  
  
  In fact we don't have to fear or guess: we can just look at GNOME. They 
distribute their apps alongside GNOME itself. They share a release schedule and 
version numbering schema, and many of them even have "GNOME" in their name 
(e.g. "GNOME Chess", "GNOME Photos", etc). Despite this, I see no indication 
that people confusedly think you can't use GNOME's apps without the GNOME DE 
itself. People seem to happily use GNOME apps on whatever DE they want. 
Logically I think this makes sense because if you open up an app store app like 
Discover or GNOME Software, you generally see no indication of which parent DE 
an app is released alongside. If I crack open Discover and check out Simple 
Scan or GNOME Disks, nothing there tells me that I need all of GNOME to run it. 
So I don't think this is actually a problem.
  
  In T10812#182253 , @ltoscano wrote:
  
  > In T10812#182252 , @cfeck 
wrote:>>
  >
  > > Also, does "Discover" or "Bluedevil" really only work under Plasma?
  >
  >
  > That's what the Plasma team decided, and they can decide otherwise. They 
decided (with reasons) that those components are tightly integrated with the 
rest of Plasma. This can change, of course; other components were moved out of 
Plasma over time.
  
  
  To clear up a misconception, Discover doesn't depend on Plasma 
. In fact I believe it's 
being used in Lubuntu right now.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham
Cc: ltoscano, cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, 
#konsole, #gwenview, #kde_pim, #kde_games, #kde_applications, ngraham

D20678: Ensure compatibility with Qt <5.10

[A. Wilcox]

awilcox created this revision.
awilcox added a project: Okular.
awilcox requested review of this revision.

REVISION SUMMARY
  Qt::AA_CompressTabletEvents was added in Qt 5.10.  Use preprocessor check
  to avoid build failures on 5.9 LTS or 5.8 (the minimum version).

TEST PLAN
  Build against Qt 5.9 LTS and 5.12 LTS.  Both built successfully.

REPOSITORY
  R223 Okular

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

AFFECTED FILES
  shell/main.cpp

To: awilcox
Cc: okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid

T10812: KDE Applications

[Luigi Toscano]

ltoscano added a comment.


  In T10812#182252 , @cfeck wrote:
  
  > Yes, we have been trying hard, but did we succeed? Would someone just stop 
using Okular, because it is shipped with the Plasma bundle instead of the KDE 
Applications bundle?
  
  
  I fear it will happen, yes. Moreover, Plasma bits tend to update their 
dependecies on base libraries (Qt and Frameworks) at a faster pace than most of 
the other components. But more important than that it's the branding issue 
(which why I advocate a change of the name of the bundle).
  
  > Also, does "Discover" or "Bluedevil" really only work under Plasma?
  
  That's what the Plasma team decided, and they can decide otherwise. They 
decided (with reasons) that those components are tightly integrated with the 
rest of Plasma. This can change, of course; other components were moved out of 
Plasma over time.
  
  The discussion about LTS applications it's totally different. No one forces 
us to provide LTS releases, and from a resource point of view it does not make 
much sense: most of the applications per of the bundle are independent enough 
from each other and they don't bump their requirements frequently, so they 
could be updated by distributions should their policy allow that. But many of 
them can provide semi-official repositories with updates.
  Talking about CentOS, the direction there is clear: flatpak.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, ltoscano
Cc: ltoscano, cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, 
#konsole, #gwenview, #kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Christoph Feck]

cfeck added a comment.


  Yes, we have been trying hard, but did we succeed? Would someone just stop 
using Okular, because it is shipped with the Plasma bundle instead of the KDE 
Applications bundle?
  
  Also, does "Discover" or "Bluedevil" really only work under Plasma?

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, cfeck
Cc: ltoscano, cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, 
#konsole, #gwenview, #kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Luigi Toscano]

ltoscano added a comment.


  In T10812#182245 , @ngraham wrote:
  
  > In T10812#182242 , @cfeck wrote:
  >
  > > If you are asking for my personal opinion, I propose to split current KDE 
Applications into parts:
  > >
  > > - Base/essential applications (Dolphin, Ark, KCharSelect, KCalc, 
Kate/KWrite, Konsole, Spectacle, Gwenview, Okular, thumbnailers, more?). Ship 
them together with Plasma[1]. I really love the Fibonacci release cycles of 
Plasma for bug fixes. Also, Plasma developers sometimes decide to do an LTS 
release, and the base applications would also benefit from LTS support. All of 
them should use the same 5.x (later 6.x) version number.
  >
  >
  > I was actually going to suggest this myself, so I'm glad you did. :) I 
agree 100% with this as well as your other ideas about splitting up apps into 
different releases.
  
  
  We have been trying hard to sell those applications as not "part of KDE 
(Plasma)" (DE agnostic, OS agnostic). That would be a huge step back. Big -1.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, ltoscano
Cc: ltoscano, cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, 
#konsole, #gwenview, #kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Nathaniel Graham]

ngraham added a comment.


  In T10812#182242 , @cfeck wrote:
  
  > If you are asking for my personal opinion, I propose to split current KDE 
Applications into parts:
  >
  > - Base/essential applications (Dolphin, Ark, KCharSelect, KCalc, 
Kate/KWrite, Konsole, Spectacle, Gwenview, Okular, thumbnailers, more?). Ship 
them together with Plasma[1]. I really love the Fibonacci release cycles of 
Plasma for bug fixes. Also, Plasma developers sometimes decide to do an LTS 
release, and the base applications would also benefit from LTS support. All of 
them should use the same 5.x (later 6.x) version number.
  
  
  I was actually going to suggest this myself, so I'm glad you did. :) I agree 
100% with this as well as your other ideas about splitting up apps into 
different releases.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham
Cc: cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole, 
#gwenview, #kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Christoph Feck]

cfeck added a comment.


  I agree with Albert.
  
  The actual problem is that users still think that there is one "KDE version". 
They are looking at the "About KDE..." menu to find the version of the KDE 
(applications).
  
  If you are asking for my personal opinion, I propose to split current KDE 
Applications into parts:
  
  - Base/essential applications (Dolphin, Ark, KCharSelect, KCalc, Kate/KWrite, 
Konsole, Spectacle, Gwenview, Okular, thumbnailers, more?). Ship them together 
with Plasma[1]. I really love the Fibonacci release cycles of Plasma for bug 
fixes. Also, Plasma developers sometimes decide to do an LTS release, and the 
base applications would also benefit from LTS support. All of them should use 
the same 5.x (later 6.x) version number.
  
  - KDEPIM (Kontact, Akonadi, etc.). It's a separate big project that could 
benefit from either faster (for bug fixes) or smaller release cycles (for 
feature releases). With the huge amount of work that Laurent is doing, I 
sometimes feel he could better decide when he thinks a partical snapshot is 
ready for release. Rushed commits for Akonadi also sometimes make KDEPIM 
unstable. Reports on IRC that KDEPIM broke from one version to another 
accumulate. More time for stabilization would really help. Regarding version 
numbers, KDEPIM long used the 5.x versions. "Marketing" name could be "KDE 
PIM", "KDE Kontact", or whatever.
  
  - Maintained applications (such as Lokalize, Cantor, Kdenlive) get their own 
releases, decided by the maintainers[2]. If maintainers failed to do a new 
release within, say, 8 or 12 months, the project would move to "KDE Extras" 
(see below) and last known working branch would in turn get scheduled (bundled) 
maintainance updates. If someone steps up again to do separate releases, they 
remove it again from "KDE Extras" to avoid scheduled releases.
  
  - KDE Edutainment, all games and educational apps, which are all practically 
unmaintained, and could need a slower release cycle, maybe back to two or even 
one per year. Version numbers would be individual, but the bundle would be 
called "KDE Edutainment YY.MM".
  
  - KDE Extras (not to be confused with Extragear): Basically all the rest from 
KDE Applications, minus the already listed packages. These would include rarer 
stuff such as K3b, KWave, etc. In other words, everything else, which has no 
one to do releases. Again, they would be released twice or once per year, each 
one with their own version number, but the bundle called "KDE Extras YY.MM".
  
  The proposed juggle between maintained applications and unmaintained (but 
still useful and working) applications would also solve the "Extragear 
problem". Either an application has a maintainer doing separate releases (e.g. 
KMyMoney, LabPlot, Tellico), or they don't, and the project would automatically 
join "KDE Extras" (e.g. KTorrent or Choqok; they have no maintainer, but fixes 
are piling up).
  
  Footnotes:
  
  [1] I would even go as far and to also merge KF5 Frameworks - after all these 
years we have to admit that the "Frameworks idea" (people using them outside of 
KDE) has never materialized. All people currently doing Plasma, Apps, and KF5 
releases could turn around to do the new "Plasma" releases. Give users the "old 
KDE" back, but only with selected base applications.
  
  [2] When I was proposing to split KStars from the bundle, I really feared 
that the project would starve. What happened is the reverse: I see more 
phabricator requests for KStars than ever before. Cantor might also benefit 
from a separate release cycle. I believe the KDE Applications release cycle 
hindered Kdenlive development ("should we merge now or wait another four 
months?")

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, cfeck
Cc: cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole, 
#gwenview, #kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Nathaniel Graham]

ngraham added a comment.


  In T10812#182213 , @aacid wrote:
  
  > No, we just need to get users away from bad distros.
  
  
  I find this really insulting. :/ I think discrete release distros can be 
great.
  
  It's also unrealistic. The "bad distros" are the ones actually used by huge 
numbers of people. In my last job, almost all the engineers used Linux on their 
desktop. Did they use Arch? No. OpenSUSE Tumbleweed? No. They all used CentOS 
or Ubuntu LTS versions, because those are the distros that their enterprise 
customers are using. We can't increase our market penetration by ignoring these 
distros. Please correct me if I'm wrong, but one of the major reasons why we do 
releases in the first place is for the benefit of distros. If they wanted to, 
they could just package snapshots of our sources, right? We're already 
providing a nice-to-have service by even doing releases.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham
Cc: aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole, #gwenview, 
#kde_pim, #kde_games, #kde_applications, ngraham

[okular] [Bug 406646] Okular Can not really change page color

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 CC||aa...@kde.org
 Status|REPORTED|RESOLVED
 Resolution|--- |NOT A BUG

--- Comment #4 from Albert Astals Cid  ---
It does change the paper color, you can clearly see the paper color is now blue
https://i.imgur.com/7jEXLiu.png

What we can't change is the fact that there's a big white rectangle as part of
the page contents.

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

T10812: KDE Applications

[Albert Astals Cid]

aacid added a comment.


  In T10812#182201 , @ngraham wrote:
  
  > If you're suggesting that Kubuntu could change their versioning scheme, 
that's a tacit admission that you do think there's a problem (otherwise there 
would be no suggestion of a proposed change or solution). It's a problem from a 
user perspective for just the reason I gave: users confuse our app versions 
with Ubuntu's own version numbers. "Confused users" is a problem. I agree that 
it's not a huge issue but I think it //is// an issue. Maybe it's not worth 
fixing. But it's an issue.
  
  
  As i clearly said I don't think it's a problem, but if KUbuntu developers 
think it is, it is something they have the power to fix by themselves.
  
  > In T10812#182195 , @aacid wrote:
  > 
  >> > There are no LTS app versions the way there are with Plasma; distros 
that ship Plasma LTS get stuck with old apps versions that have bugs which have 
been fixed in later releases
  >>
  >> I personally disagree this is a problem. If distributions want bug fixes 
they can either
  >>
  >> - update to a new release
  >> - do the work of doing an LTS branch themselves.
  >> - give us money so we can hire someone to the work for them
  > 
  > 
  > Updating to a new release isn't an option for the discrete release distros, 
particular for their LTS releases. Asking them to do an LTS branch themselves 
or pay us to do it is unreasonable; it's our software and we define our release 
schedule. All I'm saying is that I think adding LTS versions of apps is 
something that would be really nice for the discrete release distros that ship 
our LTS Plasma versions. Right now they can continuously take our LTS Plasma 
bugfix releases to ensure that the Plasma they ship gets better and better over 
time, but they can't do this for our apps. This isn't just bad for their users; 
it's bad for us because we need to handle more time-wasting bugzilla tickets 
for issues that have already been fixed from people using versions of our 
software that could be 2 or more years old.
  
  No, we just need to get users away from bad distros. I'm 92.41% sure those 
distros don't have any issue updating to a new firefox or chrome when it comes 
out. But on the other hand they want **us** to do extra work for some weird 
rule, i say **NO**,  they are the problem and we have to fight back. 
Distributions decided they don't want to give users updates, they have to live 
with that. Users decided they want to use a distribution that doesn't give them 
updates, they have to live with that or change to a better distribution or use 
snap/flatpak (a story we have to improve at some point)
  
  >> If this comes from an application developer that wants to maintain 3 
branches (LTS, stable, devel) it'd be another thing. Do we know of any 
developer that would like to maintain such scheme for KDE Applications?
  > 
  > I mean, that's what we do for Plasma and it's not a problem.
  
  Comparing Plasma and KDE Applications is like comparing RedHat with 
BlueSystems, the amount of developer-power per line Plasma has compared to KDE 
Applications is probably several orders of magnitude bigger, so what works in 
one doesn't necessarily have to work in another case.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, aacid
Cc: aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole, #gwenview, 
#kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Nathaniel Graham]

ngraham added a comment.


  In T10812#182195 , @aacid wrote:
  
  > > Apps that are in the bundle have inconsistent versioning; most use the 
bundle's own versioning scheme, but others use their own
  >
  > I personally disagree this is a problem. It let's applications hop on and 
off the release and keep their versioning number intact.
  
  
  I'm using Dolphin 18.12.3, which comes from KDE Applications 18.12.3. But the 
bundle it also comes with Okular. Am I using Okular 18.12.3? Or Okular 1.6.3? 
The promo material says 18.12.3. The version number in my distro's packaging 
says 18.12.3. Discover, which uses the distro packaging metadata, says 18.12.3. 
But the About Okular window says 1.6.3. This is confusing and problematic from 
a user, packager, and promo perspective because it's not clear which version 
number they should use.
  
  In T10812#182195 , @aacid wrote:
  
  > > The bundle's YY.MM version numbering scheme happens to be the same as 
Ubuntu's versioning scheme, which causes users to confuse one with another (for 
example a user with Kubuntu 18.04 is actually using KDE Applications 17.12, not 
18.04)
  >
  > I personally disagree this is a problem. Ubuntu didn't invent the YY.MM 
versioning scheme, on top of that our scheme only overlaps with Ubuntu's 1/3 of 
the times. Maybe Kubuntu can just put some extra work and make sure that for 
the .04 release they ship our .04 release if they feel that it confuses their 
users. Or maybe they could change their versioning scheme.
  
  
  If you're suggesting that Kubuntu could change their versioning scheme, 
that's a tacit admission that you do think there's a problem (otherwise there 
would be no suggestion of a proposed change or solution). It's a problem from a 
user perspective for just the reason I gave: users confuse our app versions 
with Ubuntu's own version numbers. "Confused users" is a problem. I agree that 
it's not a huge issue but I think it //is// an issue. Maybe it's not worth 
fixing. But it's an issue.
  
  In T10812#182195 , @aacid wrote:
  
  > > There are no LTS app versions the way there are with Plasma; distros that 
ship Plasma LTS get stuck with old apps versions that have bugs which have been 
fixed in later releases
  >
  > I personally disagree this is a problem. If distributions want bug fixes 
they can either
  >
  > - update to a new release
  > - do the work of doing an LTS branch themselves.
  > - give us money so we can hire someone to the work for them
  
  
  Updating to a new release isn't an option for the discrete release distros, 
particular for their LTS releases. Asking them to do an LTS branch themselves 
or pay us to do it is unreasonable; it's our software and we define our release 
schedule. All I'm saying is that I think adding LTS versions of apps is 
something that would be really nice for the discrete release distros that ship 
our LTS Plasma versions. Right now they can continuously take our LTS Plasma 
bugfix releases to ensure that the Plasma they ship gets better and better over 
time, but they can't do this for our apps. This isn't just bad for their users; 
it's bad for us because we need to handle more time-wasting bugzilla tickets 
for issues that have already been fixed from people using versions of our 
software that could be 2 or more years old.
  
  > If this comes from an application developer that wants to maintain 3 
branches (LTS, stable, devel) it'd be another thing. Do we know of any 
developer that would like to maintain such scheme for KDE Applications?
  
  I mean, that's what we do for Plasma and it's not a problem. In practice all 
it means is that when you have a bugfix, instead of landing it on the stable 
branch and merging to master, you land on the LTS branch, merge to the stable 
branch, and merge that to master. And in the few cases where it doesn't apply 
cleanly to the LTS branch, you say, "ehh, too much work, stable or master only" 
and life goes on. :) It's really not that hard.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham
Cc: aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole, #gwenview, 
#kde_pim, #kde_games, #kde_applications, ngraham

T10812: KDE Applications

[Albert Astals Cid]

aacid added a comment.


  > Apps that are in the bundle have inconsistent versioning; most use the 
bundle's own versioning scheme, but others use their own
  
  I personally disagree this is a problem. It let's applications hop on and off 
the release and keep their versioning number intact.
  
  > The bundle's YY.MM version numbering scheme happens to be the same as 
Ubuntu's versioning scheme, which causes users to confuse one with another (for 
example a user with Kubuntu 18.04 is actually using KDE Applications 17.12, not 
18.04)
  
  I personally disagree this is a problem. Ubuntu didn't invent the YY.MM 
versioning scheme, on top of that our scheme only overlaps with Ubuntu's 1/3 of 
the times. Maybe Kubuntu can just put some extra work and make sure that for 
the .04 release they ship our .04 release if they feel that it confuses their 
users. Or maybe they could change their versioning scheme.
  
  > There are no LTS app versions the way there are with Plasma; distros that 
ship Plasma LTS get stuck with old apps versions that have bugs which have been 
fixed in later releases
  
  I personally disagree this is a problem. If distributions want bug fixes they 
can either
  
  - update to a new release
  - do the work of doing an LTS branch themselves.
  - give us money so we can hire someone to the work for them
  
  IMNSHO the only real problem is the name is not good (your bullet points 1 
and 3), we've known that for a long time, no one has been able to find a name 
that is better, I'll be happy if someone can find one :)

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, aacid
Cc: aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole, #gwenview, 
#kde_pim, #kde_games, #kde_applications, ngraham

[okular] [Bug 406646] Okular Can not really change page color

[Nate Graham]

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

Nate Graham  changed:

   What|Removed |Added

 CC||n...@kde.org

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

[okular] [Bug 406650] Doesn't show letters properly

[bugzilla_noreply]

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

sun...@hotmail.ru changed:

   What|Removed |Added

 Resolution|FIXED   |NOT A BUG

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

[okular] [Bug 406650] Doesn't show letters properly

[bugzilla_noreply]

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

sun...@hotmail.ru changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #6 from sun...@hotmail.ru ---
Sorry, did't see your messages before posting. Yes, installing ttf-ms-fonts
fixed the situation. Thank you all!

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

[okular] [Bug 406650] Doesn't show letters properly

[Luigi Toscano]

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

Luigi Toscano  changed:

   What|Removed |Added

 CC||luigi.tosc...@tiscali.it

--- Comment #5 from Luigi Toscano  ---
In File->Properties->Fonts, which fonts are used to replace Arial and
Arial,Bold?

Unfortunately the document does not embed the fonts.

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

[okular] [Bug 406650] Doesn't show letters properly

[bugzilla_noreply]

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

--- Comment #4 from sun...@hotmail.ru ---
Created attachment 119484
  --> https://bugs.kde.org/attachment.cgi?id=119484=edit
renders badly in Evince as well

So maybe it has something to do with fonts not available under Linux.

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

[okular] [Bug 406650] Doesn't show letters properly

[Yuri Chornoivan]

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

Yuri Chornoivan  changed:

   What|Removed |Added

 CC||yurc...@ukr.net

--- Comment #3 from Yuri Chornoivan  ---
Can you install Arial fonts (ttf-ms-fonts from AUR) and try again?

Thanks in advance for your answer.

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

[okular] [Bug 406650] Doesn't show letters properly

[bugzilla_noreply]

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

--- Comment #1 from sun...@hotmail.ru ---
Created attachment 119482
  --> https://bugs.kde.org/attachment.cgi?id=119482=edit
renders in Okular

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

[okular] [Bug 406650] Doesn't show letters properly

[bugzilla_noreply]

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

--- Comment #2 from sun...@hotmail.ru ---
Created attachment 119483
  --> https://bugs.kde.org/attachment.cgi?id=119483=edit
renders in Acrobar Reader

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

[okular] [Bug 406650] New: Doesn't show letters properly

[bugzilla_noreply]

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

Bug ID: 406650
   Summary: Doesn't show letters properly
   Product: okular
   Version: 1.6.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: PDF backend
  Assignee: okular-devel@kde.org
  Reporter: sun...@hotmail.ru
  Target Milestone: ---

Created attachment 119481
  --> https://bugs.kde.org/attachment.cgi?id=119481=edit
document that doesn't render text properly

SUMMARY
The document letters don't render properly.

STEPS TO REPRODUCE
1. Open attached document

OBSERVED RESULT
Look at strange symbols instead of text

EXPECTED RESULT
No symbols but an actual text is displayed

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
Operating System: Manjaro Linux 
KDE Plasma Version: 5.15.3
KDE Frameworks Version: 5.56.0
Qt Version: 5.12.2
Kernel Version: 4.14.111-1-MANJARO
OS Type: 32-bit
Processor: 1 × Intel® Celeron® M CPU 440 @ 1.86GHz
Memory: 1,5 GiB of RAM

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

[okular] [Bug 406646] Okular Can not really change page color

[Michael Weghorn]

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

Michael Weghorn  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 CC|m.wegh...@posteo.de |
 Status|NEEDSINFO   |REPORTED

--- Comment #3 from Michael Weghorn  ---
Thanks.

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

[okular] [Bug 406646] Okular Can not really change page color

[widon1104]

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

--- Comment #2 from widon1104  ---
Created attachment 119479
  --> https://bugs.kde.org/attachment.cgi?id=119479=edit
the pdf file

The pdf file attached.

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

[okular] [Bug 406646] Okular Can not really change page color

[Michael Weghorn]

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

Michael Weghorn  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 CC||m.wegh...@posteo.de
 Status|REPORTED|NEEDSINFO

--- Comment #1 from Michael Weghorn  ---
(In reply to widon1104 from comment #0)
> In attached file, I change the page color to green, but only left and right
> side change the color to green, the part has words do not change at all.

Can you please attach the actual file that you have opened in Okular in
addition (attachment shows the screenshot)?

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