https://bugs.kde.org/show_bug.cgi?id=488612
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=452340
--- Comment #11 from Jack Hill ---
Can no longer reproduce since I updated to Android 13
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.kde.org/show_bug.cgi?id=407547
Jack Hill changed:
What|Removed |Added
CC||594156...@qq.com
--- Comment #9 from Jack Hill
https://bugs.kde.org/show_bug.cgi?id=456480
Jack Hill changed:
What|Removed |Added
CC||jackhill3...@gmail.com
Resolution
https://bugs.kde.org/show_bug.cgi?id=407547
Jack Hill changed:
What|Removed |Added
CC||asefshahria...@gmail.com
--- Comment #8 from Jack
https://bugs.kde.org/show_bug.cgi?id=451826
Jack Hill changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=442763
Jack Hill changed:
What|Removed |Added
CC||jackhill3...@gmail.com
Resolution
https://bugs.kde.org/show_bug.cgi?id=407547
Jack Hill changed:
What|Removed |Added
CC||random1123581321@protonmail
https://bugs.kde.org/show_bug.cgi?id=452340
--- Comment #7 from Jack Hill ---
Created attachment 148845
--> https://bugs.kde.org/attachment.cgi?id=148845=edit
ADB log
log from ADB
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.kde.org/show_bug.cgi?id=452340
Jack Hill changed:
What|Removed |Added
CC||jackhill3...@gmail.com
--- Comment #6 from Jack
https://bugs.kde.org/show_bug.cgi?id=450334
Bug ID: 450334
Summary: "Search for... in this document" item in Text
Selection context menu does not truncate new lines
Product: okular
Version: 21.12.2
Platform: Other
https://bugs.kde.org/show_bug.cgi?id=450333
Bug ID: 450333
Summary: Area selection header is trimmed for big enough
selection sizes
Product: okular
Version: 21.12.2
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=436388
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=382863
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=431849
Bug ID: 431849
Summary: Small Imperfections of Font Rendering
Product: okular
Version: 20.12.1
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity:
https://bugs.kde.org/show_bug.cgi?id=431848
Bug ID: 431848
Summary: Broken "backend selection dialog"
Product: okular
Version: 20.12.1
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
https://bugs.kde.org/show_bug.cgi?id=431847
Bug ID: 431847
Summary: Slow Rendering of PDFs (comparing to other rendering
engines).
Product: okular
Version: 20.12.1
Platform: Archlinux Packages
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=423560
Jack changed:
What|Removed |Added
CC|ostroffjh@users.sourceforge |
|.net
https://bugs.kde.org/show_bug.cgi?id=418758
--- Comment #9 from Jack ---
I haven't had time to try anything on Windows yet, but by creating a shell
script called okular, and placing it earlier in my path, and invoking it by
clicking on the file in Dolphin, it seems to not encode the # in any way
https://bugs.kde.org/show_bug.cgi?id=418758
--- Comment #7 from Jack ---
I can now confirm this. I'll guess it has something to do with how Windows
Explorer passes the file name to Okular, and how Okular then processes it. If
I have two pdf files name "test#test.pdf" and "test
https://bugs.kde.org/show_bug.cgi?id=418758
--- Comment #5 from Jack ---
Have you diagnosed what is happening in a debugger, or are you assuming? In my
case, on both Windows and Linux, it is able to open a file with # in the name,
using the File/Open dialog, or when launced by command line. so
https://bugs.kde.org/show_bug.cgi?id=423560
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=418758
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=422856
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=422626
--- Comment #8 from Jack ---
There are two separate issues here.
1) Windows only allows a single page or range, Linux allows multiple. (MacOS?)
That limit seems clear to me from the note on the print dialog. If the
limitation is really
https://bugs.kde.org/show_bug.cgi?id=422626
--- Comment #5 from Jack ---
I finally tested both. On Windows (package is 19.12.2, help/about says 1.9.2)
the print dialog explicitly says to enter single page or single page range. As
in Comment 2, I don't know if this is an Okular on Windows
https://bugs.kde.org/show_bug.cgi?id=422626
Jack changed:
What|Removed |Added
CC||ostroffjh@users.sourceforge
https://bugs.kde.org/show_bug.cgi?id=421421
Jack changed:
What|Removed |Added
Summary|Pond in filename or |Pound sign in filename or
|directory
https://bugs.kde.org/show_bug.cgi?id=418679
Jack changed:
What|Removed |Added
Status|NEEDSINFO |REPORTED
Resolution|WAITINGFORINFO
https://bugs.kde.org/show_bug.cgi?id=418679
Bug ID: 418679
Summary: Okular does not show file name if title not available
(PDF)
Product: okular
Version: 1.8.3
Platform: Compiled Sources
OS: Linux
ostroffjh added a comment.
Thanks again. I understand the danger of using jargon, but there are lots of
descriptions of programs and menu items out there which are correct, but
completely useless to the user who doesn't already know. Hopefully, by the
time this actually hits distros, a
ostroffjh added a comment.
ervin: Thanks. Would it then be worth mentioning KPurpose plugins instead
of just "system settings?" I understand that text should stay concise, but if
a user is trying to find out what that menu item does, the description should
point to where it can be
ostroffjh added a comment.
I don't see this entry at all in my version of Okular 1.2.2 (17.08.2). Is
it new, or does it's presence depend on whether there would be any entries?
Also, do the entries depend on the system settings (as in what can be set
with the app of that name) or do
33 matches
Mail list logo
