If I understand correctly, kpdf uses xpdf as a base rendering engine. The xpdf code in the Trinity source tree uses 3.02 from February 2007, which has been patched for security reasons several times since then.
There also is a patch to improve a scrolling speed bug that is caused by more recent gcc versions.
The most recent version of xpdf is 3.03.
Many distros have these patches applied or use 3.03.
* Does compiling kpdf use an existing installed xpdf from the distro or does the build process only use the xpdf code that is in the kpdf source tree?
* If the latter, then should we be patching the Trinity version of xpdf? Or updating to the latest release of xpdf?
* If the latter, what is needed to change the build process to use an existing installed xpdf rather than the stale version in the Trinity sources?
Darrell
On 08/17/2012 01:05 PM, Darrell Anderson wrote:
- Does compiling kpdf use an existing installed xpdf from the distro or does
the build process only use the xpdf code that is in the kpdf source tree?
- If the latter, then should we be patching the Trinity version of xpdf? Or
updating to the latest release of xpdf?
- If the latter, what is needed to change the build process to use an
existing installed xpdf rather than the stale version in the Trinity sources?
Darrell
It's definitely building xpdf from the GIT tree. We need to apply all patches or pull the latest xpdf code. Note the numerous deprecation warnings associated with xpdf as well:
[ 32%] Built target kooka make -f kpdf/xpdf/goo/CMakeFiles/goo-static.dir/build.make kpdf/xpdf/goo/CMakeFiles/goo-static.dir/depend make[2]: Entering directory `/build/src/build' cd /build/src/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /build/src/tdegraphics /build/src/tdegraphics/kpdf/xpdf/goo /build/src/build /build/src/build/kpdf/xpdf/goo /build/src/build/kpdf/xpdf/goo/CMakeFiles/goo-static.dir/DependInfo.cmake --color= <snip> [ 32%] Building CXX object kpdf/xpdf/fofi/CMakeFiles/fofi-static.dir/FoFiBase.cc.o cd /build/src/build/kpdf/xpdf/fofi && /usr/bin/c++ -DHAVE_CONFIG_H -fpermissive -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/build/src/tdegraphics/kpdf/xpdf/fofi/.. -I/build/src/tdegraphics/kpdf/xpdf/fofi/../goo -I/build/src/build -I/opt/qt3/include -I/usr/include/tqt -fPIC -o CMakeFiles/fofi-static.dir/FoFiBase.cc.o -c /build/src/tdegraphics/kpdf/xpdf/fofi/FoFiBase.cc /usr/bin/cmake -E cmake_progress_report /build/src/build/CMakeFiles [ 32%] Building CXX object kpdf/xpdf/fofi/CMakeFiles/fofi-static.dir/FoFiEncodings.cc.o cd /build/src/build/kpdf/xpdf/fofi && /usr/bin/c++ -DHAVE_CONFIG_H -fpermissive -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/build/src/tdegraphics/kpdf/xpdf/fofi/.. -I/build/src/tdegraphics/kpdf/xpdf/fofi/../goo -I/build/src/build -I/opt/qt3/include -I/usr/include/tqt -fPIC -o CMakeFiles/fofi-static.dir/FoFiEncodings.cc.o -c /build/src/tdegraphics/kpdf/xpdf/fofi/FoFiEncodings.cc /build/src/tdegraphics/kpdf/xpdf/fofi/FoFiEncodings.cc:279:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] <snip more deprecation warning>
The CMake files could probably be changed to use xpdf libraries instead of the statically built xpdf libraries from the GIT tree. Well above my coding grade...
It's definitely building xpdf from the GIT tree. We need to apply all patches or pull the latest xpdf code. Note the numerous deprecation warnings associated with xpdf as well:
The primary issue then would seem to be that the internal Trinity xpdf is not being updated with security patches.
The CMake files could probably be changed to use xpdf libraries instead of the statically built xpdf libraries from the GIT tree. Well above my coding grade.
Likewise.
I'll write Yet Another Bug Report. Or two.
Darrell
It's definitely building xpdf from the GIT tree. We need to apply all patches or pull the latest xpdf code. Note the numerous deprecation warnings associated with xpdf as well:
The primary issue then would seem to be that the internal Trinity xpdf is not being updated with security patches.
I don't know why we need a copy of xpdf to be honest. This needs to be looked into with an eye towards using the system xpdf libraries.
Tim
The primary issue then would seem to be that the internal Trinity xpdf is not being updated with security patches.
I don't know why we need a copy of xpdf to be honest. This needs to be looked into with an eye towards using the system xpdf libraries.
Bug reports 1175 and 1176 filed.
Darrell
On 08/17/2012 03:21 PM, Timothy Pearson wrote:
I don't know why we need a copy of xpdf to be honest. This needs to be looked into with an eye towards using the system xpdf libraries.
Tim
I agree, how do we change the build so it uses the system xpdf? We can easily add xpdf as a dependency, but that doesn't mean the tdegraphics build will use it...
Cautionary!!!
kpdf is working VERY VERY well in both R14 and 3513-sru. It is a 'must have' app -- so please, please, DON'T BREAK IT :)
On 17 August 2012 16:19, Darrell Anderson humanreadable@yahoo.com wrote:
It's definitely building xpdf from the GIT tree. We need to apply all patches or pull the latest xpdf code. Note the numerous deprecation warnings associated with xpdf as well:
The primary issue then would seem to be that the internal Trinity xpdf is not being updated with security patches.
The CMake files could probably be changed to use xpdf libraries instead of the statically built xpdf libraries from the GIT tree. Well above my coding grade.
Likewise.
I'll write Yet Another Bug Report. Or two.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
On 08/17/2012 03:21 PM, Calvin Morrison wrote:
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
I don't think we can right now. All poppler-qt3 code was dropped from poppler, so you can't even build poppler-qt3 anymore. (may not be a total limitation, but that limitation is there...)
On 08/17/2012 03:21 PM, Calvin Morrison wrote:
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
I don't think we can right now. All poppler-qt3 code was dropped from poppler, so you can't even build poppler-qt3 anymore. (may not be a total limitation, but that limitation is there...)
-- David C. Rankin, J.D.,P.E.
Not a problem, we have and maintain poppler-tqt3 (in tdegraphics IIRC).
Tim
On 17 August 2012 17:14, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 08/17/2012 03:21 PM, Calvin Morrison wrote:
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
I don't think we can right now. All poppler-qt3 code was dropped from poppler, so you can't even build poppler-qt3 anymore. (may not be a total limitation, but that limitation is there...)
-- David C. Rankin, J.D.,P.E.
Not a problem, we have and maintain poppler-tqt3 (in tdegraphics IIRC).
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Or if need be Qt4 integration would resolve that problem anyway.
Calvin
On 17 August 2012 17:14, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 08/17/2012 03:21 PM, Calvin Morrison wrote:
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
I don't think we can right now. All poppler-qt3 code was dropped from poppler, so you can't even build poppler-qt3 anymore. (may not be a total limitation, but that limitation is there...)
-- David C. Rankin, J.D.,P.E.
Not a problem, we have and maintain poppler-tqt3 (in tdegraphics IIRC).
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Or if need be Qt4 integration would resolve that problem anyway.
Calvin
We want to keep Qt4 out of the core, as Qt4 still suffers from a performance hit on non-graphics-accelerated and embedded/low power systems.
Tim
On 17 August 2012 17:34, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 17 August 2012 17:14, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 08/17/2012 03:21 PM, Calvin Morrison wrote:
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
I don't think we can right now. All poppler-qt3 code was dropped from poppler, so you can't even build poppler-qt3 anymore. (may not be a total limitation, but that limitation is there...)
-- David C. Rankin, J.D.,P.E.
Not a problem, we have and maintain poppler-tqt3 (in tdegraphics IIRC).
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Or if need be Qt4 integration would resolve that problem anyway.
Calvin
We want to keep Qt4 out of the core, as Qt4 still suffers from a performance hit on non-graphics-accelerated and embedded/low power systems.
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Ok understood - Either way poppler is a good idea. We only use poppler now for afaik the previews for konqueror and other small things, nothing full fledged.
Cal
On Fri, Aug 17, 2012 at 10:37 PM, Calvin Morrison mutantturkey@gmail.comwrote:
On 17 August 2012 17:34, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 17 August 2012 17:14, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 08/17/2012 03:21 PM, Calvin Morrison wrote:
I would say instead file a bug report requesting that we port to poppler. That's what everyone else uses (and has for quite some time) and is designed specifically as a library instead of including xpdf
I don't think we can right now. All poppler-qt3 code was dropped from poppler, so you can't even build poppler-qt3 anymore. (may not be a total limitation, but that limitation is there...)
-- David C. Rankin, J.D.,P.E.
Not a problem, we have and maintain poppler-tqt3 (in tdegraphics IIRC).
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Or if need be Qt4 integration would resolve that problem anyway.
Calvin
We want to keep Qt4 out of the core, as Qt4 still suffers from a performance hit on non-graphics-accelerated and embedded/low power systems.
Not to say anything from the dismal performance that KPDF has always suffered from. The Gnome PDF viewer has been vastly superior performance for a very long time. KPDF basically tries to re-render most pages during scrolling, which is a very bad thing.
Best regards, Tiago
Tim
To unsubscribe, e-mail:
trinity-devel-unsubscribe@lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help@lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Ok understood - Either way poppler is a good idea. We only use poppler now for afaik the previews for konqueror and other small things, nothing full fledged.
Cal
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Not to say anything from the dismal performance that KPDF has always suffered from. The Gnome PDF viewer has been vastly superior performance for a very long time. KPDF basically tries to re-render most pages during scrolling, which is a very bad thing.
I agree. I always have been frustrated by KPDF and long ago concluded there was something fundamentally wrong about the KPDF design.
There does not seem to be a bug report specifically addressing that problem. Perhaps we need one?
Darrell
On Sun, Sep 16, 2012 at 1:31 AM, Darrell Anderson humanreadable@yahoo.comwrote:
Not to say anything from the dismal performance that KPDF has always suffered from. The Gnome PDF viewer has been vastly superior performance for a very long time. KPDF basically tries to re-render most pages during scrolling, which is a very bad thing.
I agree. I always have been frustrated by KPDF and long ago concluded there was something fundamentally wrong about the KPDF design.
There does not seem to be a bug report specifically addressing that problem. Perhaps we need one?
I would say so. Care to submit?
Tiago
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Not to say anything from the dismal performance that KPDF has always suffered from. The Gnome PDF viewer has been vastly superior performance for a very long time. KPDF basically tries to re-render most pages during scrolling, which is a very bad thing.
There does not seem to be a bug report specifically addressing that problem. Perhaps we need one?
I would say so. Care to submit?
Are there further technical details besides what you previously stated about rendering during scrolling?
Any clues how to resolve? There is an open bug report to convert KPDF to poppler (bug report 506). Possibly if just fixing the slow scrolling speed then KPDF users would be a magnitude happier, even if not converted to poppler.
Darrell
On Fri, 17 Aug 2012 11:05:04 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
If I understand correctly, kpdf uses xpdf as a base rendering engine. The xpdf code in the Trinity source tree uses 3.02 from February 2007, which has been patched for security reasons several times since then.
There also is a patch to improve a scrolling speed bug that is caused by more recent gcc versions.
The most recent version of xpdf is 3.03.
Many distros have these patches applied or use 3.03.
I attached a Gentoo xpdf upgrade patch from late 2009 to the first bug report. Does anyone have anything better?
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
Tiago Marques -
Timothy Pearson