Windows Support?

Hello Razi,

Am 16.07.2014 20:37, schrieb S. Razi Alavizadeh:
> New question #251738 on qpdfview:
> https://answers.launchpad.net/qpdfview/+question/251738
>
> Dear dev team
> Thanks for your great job.
> Do you try to build qpdfview under Windows?

We did build and test on Windows internally quite some time ago (I think
using something like version 0.2.x.) but did never publish any binaries.
Basically everything works, but you have to disable several integration
points like Unix signals and CUPS printing. Especially the fallback
printing support will be rather slow and does not support any of the
layout options available in the print dialog.

However qpdfview is regularly built on OS/2 resp. eComStation whose API
is somewhat close to Win32. But I am not sure how useful this is on a
modern Windows machine...

> Is there a binary package avalable for Windows?

Since nobody is currently willing to maintain it, there are no Windows
binaries available. (There is a port of qpdfview for the Cygwin
emulation environment available at [1].)

> Is there anything special about building it on Windows

If you have managed to collect the necessary tool chain and
dependencies, there should be nothing special w.r.t. building itself
except for some compile-time options to disabled several libraries and
the necessity to adjust various variables and paths (usually by adding
directives to "qpdfview.pri"). In any case, we have not yet done any
specific platform integration on Windows like launcher or file associations.

If you give it try and encounter problems, feel free to share more
specific questions here as well. I can't promise anything since I don't
have access to a machine running Windows, but I'll try to help.

> Thanks,
> Razi

Best regards, Adam.

[1] http://sourceware.org/cygwinports/

Thanks for your answer.
I successfully compile it on Windows 8.1 using Qt-4.8.4 (0.4.11Beta1), Indeed I disabled all things except DJVU plugins and did some hacks into code.

The debug output is here (just a small part of it, they were repeated on each page draw) [1] (Maybe they come from libDjVuLibre? but libDjVuLibre was bundled with DjView-4.9 [2] and it works good with DjView4).

Also scrolling through document was very slow (maybe related to above issue)
This is my patch against version 0.4.11 [3]

Dose QPDFView has a git repository? I'm a git user and (unfortunately) I don't know anything about bazar.
When I have free time I try to test PDF plugins, too.

[1] http://pastebin.ubuntu.com/7831029/
[2] http://pastebin.ubuntu.com/7831536/

Edit: Sorry, wrong references:

[1] http://pastebin.ubuntu.com/7831029/
[2] http://djvu.sourceforge.net/djview4.html
[3] http://pastebin.ubuntu.com/7831536/

Comments are not editable?!

Hello Razi,

yes, comments on Launchpad are currently not editable. AFAIK nobody currently mirrors qpdfview's code using Git repository but other than mapping a few terms, basic usage of Git and Bazaar is quite similar.

Concerning the debug output [1], it looks like Qt's painting system isn't properly initialized. It also looks suspiciously like bug #1345551 and hence might be an issue within qpdfview we don't understand yet and it could also be responsible for the slow scrolling speed. I suppose you use the prebuilt Qt SDK from the Qt project? Further information on where the initialization of the QPainter fails would be very much appreciated.

W.r.t. to the patch [3], the changes to "application.pro" should be unnecessary since you can just set those variables (*_PLUGIN_NAME) within "qpdfview.pri" overwriting the defaults. (Not sure why zlib is a problem on Windows?) And does invocation of "system" make the build fail? The actual code changes look like problems with an old compiler or one not supporting the GNU extensions of ISO C++?

Best regards, Adam.

Hello Adam,
Yes I'm using the prebuilt Qt SDK from Qt project.

> Further information on where the initialization of the QPainter fails would be very much appreciated.
I found somethings:
All thoese debug messages are printed when painter is used within "qpdfview::TileItem::paint()"
and the path of calls is:
PaintItem::paint() in pageitem.cpp calls PaintItem::paintPage()
and PaintItem::paintPage() [in line 1002: m_tileItems.first()->paint()] calls TileItem::paint()

> Not sure why zlib is a problem on Windows?
There is no z.dlll and z.lib on Windows, their names are (at least the version installed on my computer) zlib1.dll and zdll.lib.

> And does invocation of "system" make the build fail?
Nope, just I want skip errors when running qmake and it's safe because *.desktop files are not used on Windows and Mac.

> The actual code changes look like problems with an old compiler or one not supporting the GNU extensions of ISO C++?
Well, I'm using M$ VC++ :-D

Best Regards,
Razi

Hi Adam
I think I found the source of painting issue. The problem is with painting SVG icons.

Hello again,

definitely interesting! Do the problems occur because the SVG icons
are missing or because they are available but produce errors on
drawing them? Are the problems avoided by just remove the two icons in
question from the build or commenting out the calls to draw them in
TileItem::paint?

Best regards, Adam.

Am 22.07.2014 19:26, schrieb S. Razi Alavizadeh:
> Question #251738 on qpdfview changed:
> https://answers.launchpad.net/qpdfview/+question/251738
>
> S. Razi Alavizadeh posted a new comment: Hi Adam I think I found
> the source of painting issue. The problem is with painting SVG
> icons.
>

Hello,
They are available and painted as action's icon.
And commenting out the calls to draw those icons fix the problem (also slow scrolling is fixed).
Moreover, using QPainter::drawPixmap(QIcon::pixmap()) removes the debug outputs but nothing is painted (maybe iconRect should be modified?)
But I think you should use QSvgRenderer, it works but it needs the filenames.

Best Regards,
Razi

Hello again,

Am 22.07.2014 20:32, schrieb S. Razi Alavizadeh:
> Question #251738 on qpdfview changed:
> https://answers.launchpad.net/qpdfview/+question/251738
>
> S. Razi Alavizadeh posted a new comment:
> Hello,
> They are available and painted as action's icon.
> And commenting out the calls to draw those icons fix the problem (also slow scrolling is fixed).
> Moreover, using QPainter::drawPixmap(QIcon::pixmap()) removes the debug outputs but nothing is painted (maybe iconRect should be modified?)

If you QIcon::pixmap() for an SVG-only icon, this should just create a
painter itself and draw to it. Hence you might not see the debug output
of the main painter, but the results should be identical.

> But I think you should use QSvgRenderer, it works but it needs the filenames.

I am not sure where the difference to using QIcon is and I suspect it
uses QSvgRenderer internally. In any case, I do want to draw the
platform-supplied icons which often are pixmaps and I use the SVG icons
as fallbacks only.

I'll look at the Qt source code what QIcon actually uses to draw onto a
QPainter. Have you tried to use QSvgRenderer directly? (Maybe using a
resource path like ":/icons/image-loading.svg".)

> Best Regards,
> Razi
>

Best regards, Adam.

> Have you tried to use QSvgRenderer directly? (Maybe using a resource path like ":/icons/image-loading.svg".)
Yes, and as I said it works, but it renders icon scaled to page rect.

Hello,

Am 22.07.2014 20:51, schrieb Adam Reichold:
> Question #251738 on qpdfview changed:
> https://answers.launchpad.net/qpdfview/+question/251738
>
> Adam Reichold proposed the following answer:
> Hello again,
>
> Am 22.07.2014 20:32, schrieb S. Razi Alavizadeh:
>> Question #251738 on qpdfview changed:
>> https://answers.launchpad.net/qpdfview/+question/251738
>>
>> S. Razi Alavizadeh posted a new comment:
>> Hello,
>> They are available and painted as action's icon.
>> And commenting out the calls to draw those icons fix the problem (also slow scrolling is fixed).
>> Moreover, using QPainter::drawPixmap(QIcon::pixmap()) removes the debug outputs but nothing is painted (maybe iconRect should be modified?)
>
> If you QIcon::pixmap() for an SVG-only icon, this should just create a
> painter itself and draw to it. Hence you might not see the debug output
> of the main painter, but the results should be identical.
>
>> But I think you should use QSvgRenderer, it works but it needs the
> filenames.
>
> I am not sure where the difference to using QIcon is and I suspect it
> uses QSvgRenderer internally. In any case, I do want to draw the
> platform-supplied icons which often are pixmaps and I use the SVG icons
> as fallbacks only.
>
> I'll look at the Qt source code what QIcon actually uses to draw onto a
> QPainter. Have you tried to use QSvgRenderer directly? (Maybe using a
> resource path like ":/icons/image-loading.svg".)

As suspected, QSvgIconEngine uses QSvgRenderer internally, c.f. [1]. It
even uses the QPainter::drawPixmap(QIcon::pixmap()) idiom internally to
achieve caching. So I don't think this would solve the problem.

Best regards, Adam.

[1]
https://qt.gitorious.org/qt/qt/source/5049696cafe6eb9b75966930e5058fd98fa8d18f:src/plugins/iconengines/svgiconengine/qsvgiconengine.cpp

Best regards, Adam.

>> Best Regards,
>> Razi
>>
>
> Best regards, Adam.
>

Hello
The QSvgIconEngine::paint() uses "pixmap(rect.size(), mode, state)" and the strange problem occurs here:
s_settings->pageItem().progressIcon().isNull() returns false
s_settings->pageItem().progressIcon().pixmap(iconRect.toRect().size()).isNull() returns true!
s_settings->pageItem().progressIcon().availableSizes() returns empty list!!!

Best Regards,
Razi

Hello again,

I think it sounds sensible enough:

"isNull() == false" means that there is valid icon.

"pixmap().isNull() == true" means it could not be rendered at the requested size.

"availableSizes().isEmpty() == true" just means that QSvgIconEngine does not implement that method. (That's what I infer from the code at least. There is a funny ABI-compatibility shim involved.)

Using the SVG icons directly really isn't an option because it doesn't provide platform icon theme integration. Mym main question is why the code from lines 168 to 187 in qsvgiconengine.cpp which is basically nothing more than using QSvgRenderer to render to the whole device plus pixmap caching fails?

Best regards, Adam.

Hello,
Oh... you are right the source of problem is not here! The computed rectangle is wrong:

iconRect= QRectF(0,0 0x0)
iconRect.toRect= QRect(0,0 0x0)
topLeft= QPointF(0, 0)
m_rect= QRect(0,0 0x0)
iconExtent= 0

Best Regards,
Razi

Hello again,

you're right, we tested the tiling code paths so much for release 0.4.11 that we didn't notice this problem in the non-tiling path, i.e. m_rect is a null rectangle since that means "render the whole page" but of course it is not useful for position of the icons (or for obsolete pixmaps which is also broken without tiling).

Could you try out trunk revision 1631 if that solves the problems? (You can get an archive here [1] if you don't want to use Bazaar.)

Best regards, Adam.

[1] http://bazaar.launchpad.net/~adamreichold/qpdfview/trunk/revision/1631?start_revid=1631

Hello Adam,
Thank you, now it's fixed.
But I hope you consider to support VC++, for example:
I have this error that I had fixed it in my patch (comment#2)

error C2864: 'qpdfview::PageItem::proxyPadding' : only static const integral data members can be initialized within a class

Best Regards,
Razi

Hello again,

somehow comment #16 did not reach my inbox. And yes, I merged the source code changes to support MSVC into trunk revision 1632. (I chose a slightly different solution for the proxy padding, could you verify that it compiles cleanly?)
Hopefully bug #1345551 is also resolved by this change, but I am still waiting for feedback there.

Best regards, Adam.

Hello,
> somehow comment #16 did not reach my inbox.
Also for me comments #15-#17 did not email to me.

>And yes, I merged the source code changes to support MSVC into trunk revision 1632.
Thanks, it compiles successfully.

Best Regards,
Razi