D10415: Fix realDpi function for Mac

rjvbb added a comment. In D10415#203663 , @sbragin wrote: > It does work. The old one uses deprecated methods, doesn't work properly and can not be even compiled, in fact. How so? I have been building Okular on Mac for a long time (IIRC

D10415: Fix realDpi function for Mac

sbragin added a comment. In D10415#204390 , @rjvbb wrote: > In D10415#203663 , @sbragin wrote: > > > It does work. The old one uses deprecated methods, doesn't work properly and can not be even

D10415: Fix realDpi function for Mac

ltoscano added a comment. This is the list. Okular supports from Qt 5.8: https://doc.qt.io/qt-5.10/supported-platforms-and-configurations.html#qt-5-8 REPOSITORY R223 Okular BRANCH master REVISION DETAIL https://phabricator.kde.org/D10415 To: sbragin, #okular, rjvbb Cc: rjvbb,

[okular] [Bug 319625] Bookmarks lost for renamed documents, allow to manually specify document path

https://bugs.kde.org/show_bug.cgi?id=319625 Mariusz Libera changed: What|Removed |Added CC|

D10415: Fix realDpi function for Mac

cullmann added a comment. I would go for the Qt functions, as their results are consistent with what Qt itself will later use anyways. My only nitpick is why one goes over QScreen and not just asks the widget. REPOSITORY R223 Okular BRANCH master REVISION DETAIL

D10415: Fix realDpi function for Mac

sbragin added a comment. In D10415#204393 , @rjvbb wrote: > On a sideways related note: > I have at least one patch that improves Okular/Mac integration, allowing it to act as an alternative or complement to the native Preview.app . > >

D10415: Fix realDpi function for Mac

sbragin added a comment. In D10415#204401 , @cullmann wrote: > No, I meant: if the logical variant works for us here, the physical variant should work fine, too. > That they not give you the same results in all cases is clear, given they are

D10415: Fix realDpi function for Mac

rjvbb accepted this revision. rjvbb added a comment. This revision is now accepted and ready to land. On a sideways related note: I have at least one patch that improves Okular/Mac integration, allowing it to act as an alternative or complement to the native Preview.app . I've never

[okular] [Bug 336381] Directly save bookmarks to PDF

https://bugs.kde.org/show_bug.cgi?id=336381 Mariusz Libera changed: What|Removed |Added CC|

D10415: Fix realDpi function for Mac

rjvbb added a comment. Hi Sergio, > the old version was giving me some crap, while I was testing non-native resolutions. Well, deprecated code is probably not maintained beyond changes required to compile it, so may not function correctly with newer hardware or drivers. Other

[okular] [Bug 390135] PDF render is slow

https://bugs.kde.org/show_bug.cgi?id=390135 --- Comment #4 from Marcel --- (In reply to Henrik Fehlauer from comment #3) > Marcel: It would be great if you could add the version of Poppler in use. > You can check with "rpm -qi libpoppler-qt5-1". The Poppler version is

D10415: Fix realDpi function for Mac

cullmann added a comment. In our company we use the logicalDpiX()/logicalDpiY() on the widget we paint to, that works on macOS, too. I assume the physicalDotsPerInchY() should work the same. Sidenote: do we need to go over QScreen? We just use the function of the widget in question

D10415: Fix realDpi function for Mac

sbragin edited the summary of this revision. REPOSITORY R223 Okular BRANCH master REVISION DETAIL https://phabricator.kde.org/D10415 To: sbragin, #okular, rjvbb Cc: rjvbb, cullmann, aacid, kde-mac, ltoscano, #okular, michaelweghorn, ngraham

D10415: Fix realDpi function for Mac

cullmann added a comment. > I think they are not exactly the same. physicalDotsPerInchY() would give twice difference in the resolution depending on whether one uses the native or HiDPI mode. But logicalDpiX()/logicalDpiY() would return the same value in both cases. No, I meant: if the

D10415: Fix realDpi function for Mac

rjvbb added a comment. > Sorry, I didn't quite get what you mean. Your patch just makes realDpiX and realDpiY global, but the rest is the same. Am I missing something? Maybe I'm missing something because I took only quick glances at the code. I was thinking that my patch was simply

[okular] [Bug 207748] LTR languages searches text backwards

https://bugs.kde.org/show_bug.cgi?id=207748 --- Comment #20 from Fahad Al-Saidi --- I think I've found where is the problem. It is from TextPagePrivate::correctTextOrder(), it sorts words & characters to be LTR using theses compareTinyTextEntityY &

D10415: Fix realDpi function for Mac

rjvbb added a comment. > I agree that your patch is the minimal way to have Okular compiled on Mac. Not just that, it should result in the same code being used, with just the old code being included as inaccessible "junk DNA". No? Evidently that's not a proper fix for upstream

D10415: Fix realDpi function for Mac

sbragin added a comment. In D10415#204428 , @rjvbb wrote: > Do we agree that my patch is the minimum way of achieving the same thing your patch does? Not that I want to be lazy, but if it is I can already confirm that I have not noticed any

D10415: Fix realDpi function for Mac

sbragin added a comment. In D10415#204428 , @rjvbb wrote: > Did you verify the actual size at which elements are shown? If so maybe you can your test document and protocol so I can verify this on 10.9 (and maybe have it verified on 10.13 by one

D10415: Fix realDpi function for Mac

rjvbb added a comment. Curious, I cannot give a green light (too), please consider that done... REPOSITORY R223 Okular BRANCH master REVISION DETAIL https://phabricator.kde.org/D10415 To: sbragin, #okular, rjvbb Cc: rjvbb, cullmann, aacid, kde-mac, ltoscano, #okular, michaelweghorn,

[okular] [Bug 390293] New: PDF save does not save the content of all sticky notes. Some are blank notes when I open in other pdf viewers.

https://bugs.kde.org/show_bug.cgi?id=390293 Bug ID: 390293 Summary: PDF save does not save the content of all sticky notes. Some are blank notes when I open in other pdf viewers. Product: okular Version: 1.2.1

D10415: Fix realDpi function for Mac

aacid added subscribers: kde-mac, aacid. aacid added a comment. @kde-mac anyone that has a Mac can test/review this? If noone disagrees in a week i'll commit it. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D10415 To: sbragin, #okular Cc: aacid, kde-mac,

D10415: Fix realDpi function for Mac

sbragin added a comment. In D10415#204346 , @cullmann wrote: > In our company we use the logicalDpiX()/logicalDpiY() on the widget we paint to, that works on macOS, too. > > I assume the physicalDotsPerInchY() should work the same. I

[okular] [Bug 389668] Saving a pdf switches from thumbnail view in sidebar to contents view

https://bugs.kde.org/show_bug.cgi?id=389668 --- Comment #8 from Albert Astals Cid --- @Huon really you must be testing the wrong thing because any pdf file with Contents will switch to it if you're not there when saving. You can use https://bugs.kde.org/attachment.cgi?id=27458 as

D10249: Option to exit after printing

aacid added inline comments. INLINE COMMENTS > mainshelltest.cpp:215 > +QTest::newRow("print attach unique tabs") << file1 << optionsUnique << > true << contentsEpub[0] << 0u << false << false << false << true << 2u << > false << true; > +QTest::newRow("print attach unique tabs and

[okular] [Bug 390284] no such file errors

https://bugs.kde.org/show_bug.cgi?id=390284 Albert Astals Cid changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO

[okular] [Bug 389668] Saving a pdf switches from thumbnail view in sidebar to contents view

https://bugs.kde.org/show_bug.cgi?id=389668 --- Comment #10 from Huon --- @Albert I can reproduce the bug in the PDF you linked, however the following PDF does not produce this bug: https://bugs.kde.org/attachment.cgi?id=110552 -- You are receiving this mail because: You are

[okular] [Bug 389668] Saving a pdf switches from thumbnail view in sidebar to contents view

https://bugs.kde.org/show_bug.cgi?id=389668 --- Comment #9 from Huon --- Created attachment 110552 --> https://bugs.kde.org/attachment.cgi?id=110552=edit PDF that does not produce this bug -- You are receiving this mail because: You are the assignee for the bug.