D20760: Okular Annotation: add support for line ending style for Straight Line tool

[Rajeesh K Nambiar]

knambiar added a comment.


  In D20760#455010 , @ngraham wrote:
  
  > Hey, that's pretty cool! Any chance you could include a little icon/preview 
of the visual style for each item in the combobox?
  
  
  That’s a good suggestion. I’ll see what I can do — may be easiest is to 
include some Unicode symbols in the string itself (I don't know how to 
otherwise include an icon in the combo box text).

REPOSITORY
  R223 Okular

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

To: knambiar, #okular, #vdg
Cc: ngraham, okular-devel, joaonetto, tfella, darcyshen, aacid

[okular] [Bug 406269] pdf document with empty signature field is claimed to be signed

[Nate Graham]

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

--- Comment #5 from Nate Graham  ---
(In reply to Albert Astals Cid from comment #4)
> (In reply to Nate Graham from comment #3)
> > Can they be legitimately used for any purpose?
> 
> Most probably not.
In that case, for such PDFs, I would say we probably should not display the
"This document is digitally signed" message widget.

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

[okular] [Bug 406237] PDFs get an added margin when printing

[Matthew Trescott]

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

--- Comment #7 from Matthew Trescott  ---
(In reply to Michael Weghorn from comment #6)

> For real CUPS queues, Okular defaults to the default paper size set for the
> given queue. Therefore, it defaults to A4 if A4 is set as the default paper
> size and e.g. to A6 if A6 is set as the default paper size (as can be done
> e.g. using the command 'lpoptions -p  -o PageSize=A6').
> I personally like this behaviour, since my printer only has A4 paper loaded,
> and I don't even have paper in US Letter size, so want to print documents in
> US letter size on A4 paper.
> I do understand that others may prefer another behaviour, though.

No, the behavior you described is perfect for printing with a physical printer.
But it doesn't actually work (see below).

> > - On physical printers, Okular seems to ignore the paper size setting in the
> > Printer Properties dialog.
> 
> Can you elaborate on this?
> In my case, selecting e.g. A5 as paper size in Okular will result in only
> the area of an A5 page being printed upon on the A4 paper, and the rest
> remaining blank.
> Choosing A4 will result in the A4 area being printed upon (except margins,
> depending on the scaling settings).

I just double-checked this to make certain. I turned off WiFi temporarily so
CUPS would hold my print job (it's a network printer), then printed my
Letter-size PDF. I double-checked the printer properties in Okular to make
sure that it was set to Letter (Letter is the default for the print queue
so the paper size was already correctly set). However, when I opened the
corresponding PostScript document in /var/spool/cups, it had the distinctive
sqrt(2) side ratio of A-size paper. This confirms the results I had when I
permitted the print jobs to go through previously and discovered this bug---I
just didn't want to waste paper this time.

Summary: the bug here is that Okular always prints in A4 to physical printers,
even when a different paper size has been selected.

> > - When using Print to PDF, Okular defaults to A4 even when the input
> > document size is Letter. Changing the paper size in Printer Properties
> > actually takes effect, however.
> 
> Without checking, I'd guess that this comes from the Qt print dialog which
> Okular uses.

But mightn't it be the responsibility of the application using the Qt print
dialog (Okular in this case) to tell Qt what paper size to default to for
"Print to PDF"? My wild guess at the internals of how this works is just that
the application provides a PDF which Qt forwards unmodified to the OS's print
server, along with the metadata needed to adjust the printer settings. I doubt
the Qt print dialog would be smart enough to parse the PDF it gets (if indeed
my theory of how it works is correct) to figure out what paper size to use.

Summary: the bug here is that the Printer Properties dialog for Print to PDF
defaults to A4 for the paper size, rather than the size of the document
being printed.

> > However, even when the paper size for Print to PDF is corrected (set to
> > Letter in my case), enabling "Force rasterization" produces incorrect
> > results when the following scaling settings are used:
> > 
> > - "Fit to printable area" results in the entire document being scaled down,
> > although the margins are already more than sufficient for printing.
> 
> As far as I understand, this "works as designed". Okular doesn't take into
> account the margins already in the document, but scales the whole document
> (including what you already see as margins) to fit into the printable area,
> i.e. the whole output paper size from which the printer margins (as set in
> the print dialog's "Properties" -> "Page" tab) are subtracted (which
> defaults to the printer's hardware margins for physical printers or some
> other minimum value e.g. for the "Print to PDF" case; I think that's from
> the Qt print dialog and nothing Okular-specific).
> 
> Does this work as expected if you manually set the margins there to 0?

Ah, yes. It does work, and it makes sense since PDF files don't seem to have
any semantic concept of margins. But in that case, "Fit to printable area"
should not be the default scaling setting, since it adds margins where most
PDFs will probably not need them.

Summary: the bug here is that that the "Fit to printable area" scaling
setting is the default, rather than "Fit to full page"

> > - "Print original size" shifts the entire document down and to the right.
> 
> I can confirm this with default margins set. Again: Does this still happen
> when you set all margins to 0? (no longer happens then in my case)
> This might need a closer look, not sure if it's supposed to work like this.

Indeed, setting margins to zero does cause it to be positioned correctly.
However, I would guess this setting should be called "crop to fit printable
area" and make the horizontal cropping equal between the left and right sides,
and the vertical cropping equal between top and bot

[okular] [Bug 406831] New: RFC compliant URL to specify page number not treated properly

[bugzilla_noreply]

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

Bug ID: 406831
   Summary: RFC compliant URL to specify page number not treated
properly
   Product: okular
   Version: unspecified
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: PDF backend
  Assignee: okular-devel@kde.org
  Reporter: kdebugs.grokc...@recursor.net
  Target Milestone: ---

SUMMARY

The URL RFC specifies that a specific page number in a PDF may be referenced
using a format like "file:///path/to/file.pdf#page=3".  This should bring the
viewer directly to page 3.

STEPS TO REPRODUCE
1. okular "file:///path/to/file.pdf#page=3"

OBSERVED RESULT

Viewer opens page 1.

EXPECTED RESULT

Viewer opens page 3.

SOFTWARE/OS VERSIONS

Debian stable is used.  Okular version is 0.26.1 in Debian stable.

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

[okular] [Bug 406237] PDFs get an added margin when printing

[Michael Weghorn]

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

Michael Weghorn  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 Status|REOPENED|NEEDSINFO

--- Comment #6 from Michael Weghorn  ---
Thanks for testing and sorry for closing the bug so quickly.

(In reply to Matthew Trescott from comment #5)
> Okay, this is NOT a duplicate. Please read it carefully and test it for
> yourself. The default settings still produce poor results, although it as
> now at least possible to get suitable output.

I have tested myself. All tests involving a real physical printer in the
following refer to printing on am HP Officejet 4620.
Tests were done using the current Okular development version (as of commit
1f08c4724520414611e3eb3d6719ff9ef1209d5f) on Debian testing (with Qt 5.11.3).

> The main problem seems to be that Okular defaults to A4 paper regardless of
> the paper size of the input document.

For real CUPS queues, Okular defaults to the default paper size set for the
given queue. Therefore, it defaults to A4 if A4 is set as the default paper
size and e.g. to A6 if A6 is set as the default paper size (as can be done e.g.
using the command 'lpoptions -p  -o PageSize=A6').
I personally like this behaviour, since my printer only has A4 paper loaded,
and I don't even have paper in US Letter size, so want to print documents in US
letter size on A4 paper.
I do understand that others may prefer another behaviour, though.


> - On physical printers, Okular seems to ignore the paper size setting in the
> Printer Properties dialog.

Can you elaborate on this?
In my case, selecting e.g. A5 as paper size in Okular will result in only the
area of an A5 page being printed upon on the A4 paper, and the rest remaining
blank.
Choosing A4 will result in the A4 area being printed upon (except margins,
depending on the scaling settings).


> - When using Print to PDF, Okular defaults to A4 even when the input
> document size is Letter. Changing the paper size in Printer Properties
> actually takes effect, however.

Without checking, I'd guess that this comes from the Qt print dialog which
Okular uses.

> However, even when the paper size for Print to PDF is corrected (set to
> Letter in my case), enabling "Force rasterization" produces incorrect
> results when the following scaling settings are used:
> 
> - "Fit to printable area" results in the entire document being scaled down,
> although the margins are already more than sufficient for printing.

As far as I understand, this "works as designed". Okular doesn't take into
account the margins already in the document, but scales the whole document
(including what you already see as margins) to fit into the printable area,
i.e. the whole output paper size from which the printer margins (as set in the
print dialog's "Properties" -> "Page" tab) are subtracted (which defaults to
the printer's hardware margins for physical printers or some other minimum
value e.g. for the "Print to PDF" case; I think that's from the Qt print dialog
and nothing Okular-specific).

Does this work as expected if you manually set the margins there to 0?


> - "Print original size" shifts the entire document down and to the right.

I can confirm this with default margins set. Again: Does this still happen when
you set all margins to 0? (no longer happens then in my case)
This might need a closer look, not sure if it's supposed to work like this.

> To summarize, the only settings that produce normal print output for a
> standard 8.5 x 11" document are either:
> 
> - Print to PDF with the paper size manually set to Letter instead of A4
> _AND_ "Force rasterization" disabled.
> - Print to PDF with the paper size manually set to Letter instead of A4
> _AND_ "Force rasterization" enabled _AND_ scaling set to "Fit to full page"
> 
> I don't mean to be the unhappy customer when I didn't pay for the software,
> but in the future it would be nice to have bug reports verified fixed before
> they're closed as duplicates. It would make reporting bugs so much easier if
> I didn't have to put this much effort into proving to developers that the
> bug exists. Thanks.

Sorry again. Anyway, to be honest, I didn't see much in your initial
description in addition to the bug I closed it as a duplicate of.

With the additional info above: Can you explicitly mention what of the
described behaviour you exactly to consider to be a bug? I think it might help
to later split things into separate bug reports if you think that there's
multiple issues, but let's first try to make sure there's a common
understanding.

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

D20760: Okular Annotation: add support for line ending style for Straight Line tool

[Nathaniel Graham]

ngraham added a reviewer: VDG.
ngraham added a comment.


  Hey, that's pretty cool! Any chance you could include a little icon/preview 
of the visual style for each item in the combobox?

REPOSITORY
  R223 Okular

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

To: knambiar, #okular, #vdg
Cc: ngraham, okular-devel, joaonetto, tfella, darcyshen, aacid

[okular] [Bug 326844] Feature request: Include option to resize window to fit page

[Albert Astals Cid]

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

Albert Astals Cid  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #15 from Albert Astals Cid  ---
1) Yes it is by design

2) That is also by design, this is a feature almost noone really needs, so the
ones that need it can add a shortcut, but adding it to the menu just pollutes
the menu for no reason.

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

[okular] [Bug 406728] Shutdown inhibited when multiple tabs are opened

[Øystein Steffensen-Alværvik]

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

Øystein Steffensen-Alværvik  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |INTENTIONAL
 Status|NEEDSINFO   |RESOLVED

--- Comment #2 from Øystein Steffensen-Alværvik  ---
(In reply to Nate Graham from comment #1)
> Doesn't the dialog have a "Don't show this again" checkbox? If so, you can
> check than and then in the future shutdown win't be inhibited when there are
> multiple tabs open.

You are right, that fixes it. I supposed I assumed that it wouldn't. Then this
must be intended behaviour; marking it as such.

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

[okular] [Bug 406713] Wrong rendering of stamp annotation added by some other program

[Nate Graham]

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

Nate Graham  changed:

   What|Removed |Added

Summary|Wrong PDF rendering |Wrong rendering of stamp
   ||annotation added by some
   ||other program

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

[okular] [Bug 406713] Wrong PDF rendering

[Nate Graham]

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

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 406728] Shutdown inhibited when multiple tabs are opened

[Nate Graham]

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

Nate Graham  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 CC||n...@kde.org
 Status|REPORTED|NEEDSINFO

--- Comment #1 from Nate Graham  ---
Doesn't the dialog have a "Don't show this again" checkbox? If so, you can
check than and then in the future shutdown win't be inhibited when there are
multiple tabs open.

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

[okular] [Bug 383651] Custom/image stamp annotations are not saved into the PDF file in a way that can be printed or that other readers can see

[Tobias Deiminger]

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

--- Comment #27 from Tobias Deiminger  ---
(In reply to Valentin Melot from comment #26)
> Hello, is there some news about this bug? It is still happening in version
> 1.6.3. Thanks in advance!
Afaikt there's no news, sorry.

@Nate, Kevin: You seem to focus on default appearances. I don't think they
would fix this bug, can you explain how?

For my understanding we need to extend poppler so that it can generate and save
appearance streams into the PDF file in a consistent way:
- either generate PDF operations from user image to draw image as paths
- or rasterize / convert user image to a sampled PDF image
- create AP structure, enter the generated image stream, enter additional
resources
- update all resource references throughout the document
- save new and dirty objects

That all has not much to do with default appearances. Even if poppler had hard
coded default appearances for stamps, non-Okular readers would not benefit from
them unless the appearance is saved into the file, which is currently not
possible and which is the toughest part to implement. And, "default" is quite
the opposite to "custom" (as in the bug title).

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

[okular] [Bug 396087] Okular stops rendering some pages, locks up at 25% CPU usage and won't die

[Marko]

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

Marko  changed:

   What|Removed |Added

 CC||cami...@gmail.com

--- Comment #8 from Marko  ---
Happens here too.

Opening Okular either directly by clicking a pdf in Dolphin or via web browser
does the same. After seemingly closing it it continues to run in the background
consuming your cpu. I wouldn't even have noticed if hadn't a lot of transcodes
running and they were going much slower than they should have been. After
manually killing the Okular processes the resources they were consuming are
released and everything works fine.

Arch Linux
KDE Plasma version: 5.15.4
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.3
Kernel Version: 5.0.9-1-ck-haswell
OS Type: 64-bit


i5 4460 cpu
32GB ram

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

[okular] [Bug 395497] Menubar - No text

[David Hurka]

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

--- Comment #16 from David Hurka  ---
I have the same issue in the titlebar menu button, but also appears in normal
menu bars.

KDE Neon 5.15.4
KDE Frameworks 5.57.0
Qt 5.12.0
Okular 1.7.0

Renaming shell.rc or both files solves the problem. Renaming only part.rc
doesn’t.

I already had this problem when I started to use KDE Neon & KF5, approximately
the same time as Evgenii.

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

[okular] [Bug 326844] Feature request: Include option to resize window to fit page

[Tristan Miller]

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

Tristan Miller  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #14 from Tristan Miller  ---
This feature is not working for me as expected:

1) The shortcut key combination works, but only when Okular is not in
continuous mode.  Is this by design?  (I suppose it might be difficult to
accommodate documents that have pages of different sizes.)

2) The command is not so easily discoverable.  You can set a shortcut for it,
but as far as I can tell it does not appear in any pull-down menu.  Please add
the command to the View menu.

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