[okular] [Bug 383301] New: Feature request: one click selection highlight color, split screen of the same document

[andresimi]

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

Bug ID: 383301
   Summary: Feature request: one click selection highlight color,
split screen of the same document
   Product: okular
   Version: unspecified
  Platform: Mint (Ubuntu based)
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: PDF backend
  Assignee: okular-devel@kde.org
  Reporter: andres...@gmail.com
  Target Milestone: ---

Hello everyone, I would like to make a feature request. 

1-  Okular has a lot of nice features but the highlight one isn't user
friendly. It would be nice if we could select color of highlights with just one
click.

2- It would be nice too if we could highlight separated passages without having
to click again in the highlight feature. I think pdfxchange has a functional
model of an interface with this aspects in mind.

3- Another feature would be the ability to split the screen and see different
parts of the same document at the same time. Like the text and the graphs on
the end of a scientific paper.

Okular is already great, but would be unbeatable with this features. Thanx

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

Re: What should okular background color be

[Albert Freeman]

I did this because I wanted to be able to set black as the background color.

On 9 Aug. 2017 11:15 am, "Albert Freeman"  wrote:

> I have added the ability for the background color in okular to be changed
> via the settings, but currently what I have done is set the default
> background color to the RGB value of QPalette::Dark since I don't think it
> is a good idea to construct a QPalette in conf/okular.kcfg just to access
> QPalette::Dark which is what is used for the background color currently in
> okular .
>
> Is this okay, what should the background color be?
>
> diff --git a/conf/dlggeneralbase.ui b/conf/dlggeneralbase.ui
> index cf4ebca0..fe373a71 100644
> --- a/conf/dlggeneralbase.ui
> +++ b/conf/dlggeneralbase.ui
> @@ -7,7 +7,7 @@
>  0
>  0
>  558
> -575
> +632
> 
>
>
> @@ -120,7 +120,7 @@
> 
>  
>   
> -  Display file name only
> +  Display file name only
>   
>   
>true
> @@ -130,7 +130,7 @@
> 
>  
>   
> -  Display full file path
> +  Display full file path
>   
>   
>false
> @@ -141,6 +141,29 @@
>   
>  
>  
> + 
> +  
> +   6
> +  
> +  
> +   0
> +  
> +  
> +   
> +
> + Background color:
> +
> +
> + Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter
> +
> +   
> +  
> +  
> +   
> +  
> + 
> +
> +
>   
>
> 4
> @@ -319,7 +342,7 @@
>
> 
>  
> - Overview columns:
> + Overview columns:
>  
>  
>   Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter
> @@ -345,7 +368,7 @@
>   Defines how much of the current viewing area will
> still be visible when pressing the Page Up/Down keys.
>  
>  
> - Page Up/Down overlap:
> + Page Up/Down overlap:
>  
>  
>   Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter
> @@ -439,6 +462,13 @@ For files which were opened before the previous
> zoom is applied.
> 
>
>   
> + 
> +  
> +   KColorButton
> +   QPushButton
> +   kcolorbutton.h
> +  
> + 
>   
>kiconloader.h
>   
> diff --git a/conf/okular.kcfg b/conf/okular.kcfg
> index 69ea8cf6..07113f87 100644
> --- a/conf/okular.kcfg
> +++ b/conf/okular.kcfg
> @@ -290,6 +290,9 @@
>
> false
>
> +  
> +  QColor(136, 142, 147)
> +  
>   
>   
>
> diff --git a/ui/pageview.cpp b/ui/pageview.cpp
> index 3d935a2e..8c6ac3ca 100644
> --- a/ui/pageview.cpp
> +++ b/ui/pageview.cpp
> @@ -3416,7 +3416,7 @@ QList< Okular::RegularAreaRect * >
> PageView::textSelections( const QPoint& start
>
>  void PageView::drawDocumentOnPainter( const QRect & contentsRect,
> QPainter * p )
>  {
> -QColor backColor = viewport()->palette().color( QPalette::Dark );
> +QColor backColor = Okular::Settings::backgroundColor();
>
>  // when checking if an Item is contained in contentsRect, instead of
>  // growing PageViewItems rects (for keeping outline into account), we
>
>
>

What should okular background color be

[Albert Freeman]

I have added the ability for the background color in okular to be changed
via the settings, but currently what I have done is set the default
background color to the RGB value of QPalette::Dark since I don't think it
is a good idea to construct a QPalette in conf/okular.kcfg just to access
QPalette::Dark which is what is used for the background color currently in
okular .

Is this okay, what should the background color be?

diff --git a/conf/dlggeneralbase.ui b/conf/dlggeneralbase.ui
index cf4ebca0..fe373a71 100644
--- a/conf/dlggeneralbase.ui
+++ b/conf/dlggeneralbase.ui
@@ -7,7 +7,7 @@
 0
 0
 558
-575
+632

   
   
@@ -120,7 +120,7 @@

 
  
-  Display file name only
+  Display file name only
  
  
   true
@@ -130,7 +130,7 @@

 
  
-  Display full file path
+  Display full file path
  
  
   false
@@ -141,6 +141,29 @@
  
 
 
+ 
+  
+   6
+  
+  
+   0
+  
+  
+   
+
+ Background color:
+
+
+ Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter
+
+   
+  
+  
+   
+  
+ 
+
+
  
   
4
@@ -319,7 +342,7 @@
   

 
- Overview columns:
+ Overview columns:
 
 
  Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter
@@ -345,7 +368,7 @@
  Defines how much of the current viewing area will
still be visible when pressing the Page Up/Down keys.
 
 
- Page Up/Down overlap:
+ Page Up/Down overlap:
 
 
  Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter
@@ -439,6 +462,13 @@ For files which were opened before the previous
zoom is applied.

   
  
+ 
+  
+   KColorButton
+   QPushButton
+   kcolorbutton.h
+  
+ 
  
   kiconloader.h
  
diff --git a/conf/okular.kcfg b/conf/okular.kcfg
index 69ea8cf6..07113f87 100644
--- a/conf/okular.kcfg
+++ b/conf/okular.kcfg
@@ -290,6 +290,9 @@
   
false
   
+  
+  QColor(136, 142, 147)
+  
  
  
   
diff --git a/ui/pageview.cpp b/ui/pageview.cpp
index 3d935a2e..8c6ac3ca 100644
--- a/ui/pageview.cpp
+++ b/ui/pageview.cpp
@@ -3416,7 +3416,7 @@ QList< Okular::RegularAreaRect * >
PageView::textSelections( const QPoint& start

 void PageView::drawDocumentOnPainter( const QRect & contentsRect,
QPainter * p )
 {
-QColor backColor = viewport()->palette().color( QPalette::Dark );
+QColor backColor = Okular::Settings::backgroundColor();

 // when checking if an Item is contained in contentsRect, instead of
 // growing PageViewItems rects (for keeping outline into account), we

D7212: Don't build kimgiotest unless BUILD_TESTING=ON

[Andreas Sturmlechner]

This revision was automatically updated to reflect the committed changes.
Closed by commit R223:862fd4f3e1d0: Don't build kimgiotest unless 
BUILD_TESTING=ON (authored by asturmlechner).

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7212?vs=17905=17910

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

AFFECTED FILES
  generators/kimgio/CMakeLists.txt

To: asturmlechner, #okular, kfunk
Cc: kfunk, aacid

D7212: Don't build kimgiotest unless BUILD_TESTING=ON

[Kevin Funk]

kfunk accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R223 Okular

BRANCH
  Applications/17.08

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

To: asturmlechner, #okular, kfunk
Cc: kfunk, aacid

D7212: Don't build kimgiotest unless BUILD_TESTING=ON

[Andreas Sturmlechner]

asturmlechner added a comment.


  actually ECM git master/KF-5.38 that is, sorry.

REPOSITORY
  R223 Okular

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

To: asturmlechner, #okular
Cc: kfunk, aacid

D7212: Don't build kimgiotest unless BUILD_TESTING=ON

[Andreas Sturmlechner]

asturmlechner created this revision.
Restricted Application added a project: Okular.

REVISION SUMMARY
  In >=KF-5.37 target kimgiotest is only built if BUILD_TESTING=ON,
  so subsequent target_compile_definitions will fail if OFF.

REPOSITORY
  R223 Okular

BRANCH
  Applications/17.08

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

AFFECTED FILES
  generators/kimgio/CMakeLists.txt

To: asturmlechner, #okular
Cc: kfunk, aacid

[okular] [Bug 315552] Allow save annotations directly to original pdf file

[CnZhx]

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

--- Comment #13 from CnZhx  ---
Thank you, Gregor, for your clarification. It seems I am exactly one of the
confused.

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

[okular] [Bug 315552] Allow save annotations directly to original pdf file

[Gregor Mi]

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

--- Comment #12 from Gregor Mi  ---
@CnZhx: Normally, Ctrl+S is the "Save" action. So, the usage of Ctrl+S for
"Save as..." (which is Ctrl+Shift+S by default) is a non-standard behavior that
can confuse users. This will be fixed.

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

[okular] [Bug 315552] Allow save annotations directly to original pdf file

[CnZhx]

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

--- Comment #11 from CnZhx  ---
Sorry for the mistake. But I can use Ctrl+s to save the document with
annotation as a new pdf file or replace the original one on following
environment:
```
openSUSE Tumbleweed: 20170628
KDE Plasma: 5.10.2
Qt: 5.9.0
KDE Frameworks: 5.34.0
Kernel: 4.11.7-1-default
Okular: Version 1.1.2
PDF Backend: Version 0.6.5
```
So I thought it's solved.

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

[okular] [Bug 315552] Allow save annotations directly to original pdf file

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 CC||aa...@kde.org

--- Comment #10 from Albert Astals Cid  ---
No, because we don't support Ctrl+S yet.

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

[okular] [Bug 383274] failure printing via CUPS when document name contains non-ASCII characters

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 CC||aa...@kde.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Albert Astals Cid  ---


*** This bug has been marked as a duplicate of bug 364809 ***

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

[okular] [Bug 364809] can't print file that contains invalid UTF-8 sequence

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 CC||ralf...@gmx.de

--- Comment #12 from Albert Astals Cid  ---
*** Bug 383274 has been marked as a duplicate of this bug. ***

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

Re: Review Request 130218: Print via QPrinter when rasterizing and printing annotations

[Oliver Sander]

> On Aug. 6, 2017, 3:17 p.m., Albert Astals Cid wrote:
> > Rasterizing usually makes stuff look quite bad (because the wrong 
> > resolution is chosen) , have you tried printing text or things with sharp 
> > lines?
> 
> Oliver Sander wrote:
> Yes I tried that, and it looks very good.  It looks so good I wasn't even 
> able to tell that it was rasterized before printing.  The resolution chosen 
> by the code adapts to the printer
> 
>  QImage img = pp->renderToImage(  printer.physicalDpiX(), 
> printer.physicalDpiY() );
> 
> and I guess it must be pretty large when printing to an actual printer.
> 
> Albert Astals Cid wrote:
> So we will kill cheap printers/computers by using lots of memory? Can you 
> try to see how much memory is used printing an A4 page? Also make sure that 
> printing N pages doesn't need N times the memory (i guess using heaptrack or 
> similar)

Quick first results: printer.physicalDpiX() returns a value of 1200, both for 
printing to my office printer and for printing to a file.  An A4 printout 
results in a 9921 x 14032 bitmap; the corresponding file size is 804 KB 
(greyscale).  Testing the actual memory consumption will take me a bit more 
time.

I don't actually care about the exact resolution.  If you say "bah, just 
hard-code 72dpi there" that's fine with me.


- Oliver


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130218/#review103569
---


On Aug. 4, 2017, 8:20 p.m., Oliver Sander wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130218/
> ---
> 
> (Updated Aug. 4, 2017, 8:20 p.m.)
> 
> 
> Review request for Okular.
> 
> 
> Repository: okular
> 
> 
> Description
> ---
> 
> When the users chooses to print with rasterization and annotations, it is 
> easy to print directly to a QPrinter, rather than converting to PostScript 
> and then using CUPS tools.  The code for it was already there, but it was 
> hidden behind an #ifdef Q_OS_WIN. This patch enables it for all plattforms.  
> If nothing else, it will make an interesting debugging tool, because it 
> allows to bypass the postscript & cups toolchain from the GUI. This may allow 
> to track down some of the numerous my-printer-settings-are-getting-ignored 
> bugs.
> 
> Incidentally, this patch does fix at least one bug for me: Without it, my 
> printer will happily ignore the 'print in grayscale' button.  With the patch, 
> that button is suddenly honoured.
> 
> This patch is a part of https://git.reviewboard.kde.org/r/130055/ .  I post 
> it here separately because I am not sure anymore whether the other stuff in 
> that larger patch is a good idea.
> 
> 
> Diffs
> -
> 
>   generators/poppler/generator_pdf.cpp 42ccb3a26 
> 
> Diff: https://git.reviewboard.kde.org/r/130218/diff/
> 
> 
> Testing
> ---
> 
> Printed a few test sheets, to a printer and a file.
> 
> 
> Thanks,
> 
> Oliver Sander
> 
>

[okular] [Bug 186677] Better PDF text comments for okular

[CnZhx]

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

CnZhx  changed:

   What|Removed |Added

 CC||z...@cnzhx.net

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

[okular] [Bug 358057] [Usability] Permanent/sticky annotation feature is hard to discover

[CnZhx]

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

CnZhx  changed:

   What|Removed |Added

 CC||z...@cnzhx.net

--- Comment #2 from CnZhx  ---
I was about to file a feature request before found this but saying there is a
hidden feature of double click to make the review tool sticky. Thank you guys
:)

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

[okular] [Bug 315552] Allow save annotations directly to original pdf file

[CnZhx]

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

CnZhx  changed:

   What|Removed |Added

 CC||z...@cnzhx.net

--- Comment #9 from CnZhx  ---
Should we mark this bug/feature solved as per the document here
https://docs.kde.org/trunk5/en/kdegraphics/okular/annotations.html

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

[okular] [Bug 383139] printing to cups printer silently failing (error on console - lpr: The printer or class does not exist)

[bugzilla_noreply]

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

--- Comment #11 from er...@mcalvin.com ---
I created a bug for this with openSUSE:
https://bugzilla.opensuse.org/show_bug.cgi?id=1052793

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

[okular] [Bug 383139] printing to cups printer silently failing (error on console - lpr: The printer or class does not exist)

[Yuri Chornoivan]

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

--- Comment #10 from Yuri Chornoivan  ---
Just for the reference, the similar bug in Mageia has been fixed by
cups-filters patching update.

http://advisories.mageia.org/MGAA-2017-0055.html

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

[okular] [Bug 383274] New: failure printing via CUPS when document name contains non-ASCII characters

[bugzilla_noreply]

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

Bug ID: 383274
   Summary: failure printing via CUPS when document name contains
non-ASCII characters
   Product: okular
   Version: 0.26.1
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: printing
  Assignee: okular-devel@kde.org
  Reporter: ralf...@gmx.de
  Target Milestone: ---

OS Opensuse 42.2 Leap, latest patches applied.
  rpm -q --whatprovides /usr/bin/okular
  okular-16.08.2-1.1.x86_64

  okular --version
  Qt: 4.8.6
  KDE Development Platform: 4.14.25
  Okular: 0.26.1

When a PDF document contains Umlauts in the print job name, printing via CUPS
fails with an error message in /var/log/cups/error_log:

Create-Job client-error-attributes-or-values-not-supported: Bad job-name value:
"job-name": Bad name value "Allgemeine Geschäftsbedingungen für den
elektronischen Geschäftsverkehr" - bad UTF-8 sequence (RFC 2911 section 4.1.2).
[Client 18] Returning IPP client-error-attributes-or-values-not-supported for
Create-Job (ipp://localhost:631/printers/kopierer) from localhost

The problem seems to be that the Umlauts in there are not UTF-8 encoded.
Since I have no control over the job name (filename is e.g. x.pdf)

Printing the same document via e.g. evince succeeds:
[Job 51] job-name="51 - Allgemeine Geschäftsbedingungen für den
elektronischen Geschäftsverkehr"

Here the Umlauts seem to be properly UTF-8 encoded.

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

Re: Review Request 130214: Simplify the drawing of buffered highlight rectangles

[Oliver Sander]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130214/
---

(Updated Aug. 8, 2017, 12:56 p.m.)


Status
--

This change has been marked as submitted.


Review request for Okular.


Changes
---

Submitted with commit 024d25cdeca11f9cd012b4e5099b1b4cb91826de by Oliver Sander 
to branch master.


Repository: okular


Description
---

Previously, they were drawn by modifying individual pixelsof the QImage.  
With this patch we simply use a QPainter. That makes the code a lot shorter.

This follows a suggestion from 
https://blog.hetzenecker.me/2017-06-30-gsoc-kdegraphics-okular/

The code that is removed by this patch is the sole consumer of the has_alpha 
variable.  Consequently the compiler now warns about an unused variable.  
Should I send another patch removing that variable?


Diffs
-

  ui/pagepainter.cpp ecfafa502 

Diff: https://git.reviewboard.kde.org/r/130214/diff/


Testing
---

Tested with pdf and odt documents, and different text colors, and I could not 
find any functional difference.  In particular, testing with pdf and odt makes 
sure that both branches of the if(has_alpha) conditional are tested.


Thanks,

Oliver Sander