[Okular-devel] [Bug 170748] file crashes okular (repeatably)
http://bugs.kde.org/show_bug.cgi?id=170748 --- Comment #3 from Neal Becker ndbecker2 gmail com 2008-09-10 13:01:17 --- rpm -q poppler-qt4 poppler-qt4-0.8.1-1.fc9.x86_64 -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 170748] file crashes okular (repeatably)
http://bugs.kde.org/show_bug.cgi?id=170748 --- Comment #4 from Pino Toscano pino kde org 2008-09-10 13:31:25 --- If you cannot reproduce this, Correct, I cannot reproduce this with poppler-qt4 0.8.6. That's why I need a backtrace from you. poppler-qt4-0.8.1-1.fc9.x86_64 Update (if available) is highly suggested. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 151614] store annotations with documents
http://bugs.kde.org/show_bug.cgi?id=151614 --- Comment #48 from Markus Grabner grabner icg tugraz at 2008-09-10 15:08:24 --- Created an attachment (id=27349) -- (http://bugs.kde.org/attachment.cgi?id=27349) store annotations in a file named after the file's MD5 sum -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 151614] store annotations with documents
http://bugs.kde.org/show_bug.cgi?id=151614 Markus Grabner grabner icg tugraz at changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #49 from Markus Grabner grabner icg tugraz at 2008-09-10 15:15:58 --- (In reply to comment #9) It'd be great if rather than associating the annotations to filenames, okular could install associate XML files with PDFs based on hashes (e.g., sha-1, md5, etc.) of the PDF. I have a similar usage scenario in mind and did a quick hack to do just this (see comment #48). It works nicely in several ways: *) Annotations keep associated with the file after renaming it. *) It also works for non-local URLs (http://...) since we don't need to care for mapping the URL to some valid file name. *) Annotations keep associated with the file after downloading it from the web and opening a local copy (possibly under a different name). A cmake module to detect the mhash library (or complain if it's not available) should probably be written. BTW (to submit my vote :-), I very much like the idea of having separate files for storing annotations since this makes it possible to merge annotations from different people. Nevertheless, I would also love to see the option to store annotations directly in the file (at least for file formats which support this, such as PDF). Kind regards, Markus -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 151614] store annotations with documents
http://bugs.kde.org/show_bug.cgi?id=151614 Ivo Anjo knuckles gmail com changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #50 from Ivo Anjo knuckles gmail com 2008-09-10 15:19:51 --- Very nice idea Markus. Although you should probably try to use the QCryptographicHash class (that supports doing md4, md5 and sha1), instead of depending on an external library. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 151614] store annotations with documents
http://bugs.kde.org/show_bug.cgi?id=151614 --- Comment #51 from Pino Toscano pino kde org 2008-09-10 15:22:30 --- @Markus Grabner: Please do not hijack this bug with something else. This bug is about storing the annotations with the document, not changing the way the internal information is saved. If you have ideas, please join our mailing list (okular-devel), and start proposing them there. Thanks. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] md5 hash for annotation file name
Hi!
It has been discussed (http://bugs.kde.org/show_bug.cgi?id=151614) to use
a hash function to determine the name of the annotation file created by
okular. The attached patch implements this behaviour (thanks Ivo for pointing
me to QCryptographicHash - I looked for such a thing but somehow missed it).
It works nicely in several ways:
*) Annotations keep associated with the file after renaming it.
*) It also works for non-local URLs (http://...) since we don't need to care
for mapping the URL to some valid file name.
*) Annotations keep associated with the file after downloading it from the web
and opening a local copy (possibly under a different name).
Kind regards,
Markus
--
Markus Grabner - Computer Graphics and Vision
Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria
Phone: +43/316/873-5041, Fax: +43/316/873-5050
WWW: http://www.icg.tugraz.at/Members/grabner
Index: okular/core/document.cpp
===
--- okular/core/document.cpp (Revision 859478)
+++ okular/core/document.cpp (Arbeitskopie)
@@ -18,6 +18,7 @@
// qt/kde/system includes
#include QtCore/QtAlgorithms
+#include QtCore/QCryptographicHash
#include QtCore/QDir
#include QtCore/QFile
#include QtCore/QFileInfo
@@ -1367,11 +1368,7 @@
// determine the related xml document-info filename
d-m_url = url;
d-m_docFileName = docFile;
-if ( url.isLocalFile() )
-{
-QString fn = url.fileName();
-document_size = fileReadTest.size();
-fn = QString::number( document_size ) + '.' + fn + .xml;
+ QString fn = QString(QCryptographicHash::hash(fileReadTest.readAll(), QCryptographicHash::Md5).toHex().constData()) + .xml;
fileReadTest.close();
QString newokular = okular/docdata/ + fn;
QString newokularfile = KStandardDirs::locateLocal( data, newokular );
@@ -1387,7 +1384,6 @@
}
}
d-m_xmlFileName = newokularfile;
-}
}
else
{
___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 155696] Portrait prints as a landscape, and vice versa
http://bugs.kde.org/show_bug.cgi?id=155696 Jouk Jansen joukj hrem nano tudelft nl changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #4 from Jouk Jansen joukj hrem nano tudelft nl 2008-09-10 16:36:43 --- Got this problem with all my PDF files on Fedora 9 systems. I reported this bug to the Fedora comunity: https://bugzilla.redhat.com/show_bug.cgi?id=461562 It still persists in version 7.4.1.0-5.fc9 which was released today. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] md5 hash for annotation file name
Am Mittwoch, 10. September 2008 schrieb Albert Astals Cid: A Dimecres 10 Setembre 2008, Markus Grabner va escriure: Hi! It has been discussed (http://bugs.kde.org/show_bug.cgi?id=151614) to use a hash function to determine the name of the annotation file created by okular. The attached patch implements this behaviour (thanks Ivo for pointing me to QCryptographicHash - I looked for such a thing but somehow missed it). It works nicely in several ways: *) Annotations keep associated with the file after renaming it. *) It also works for non-local URLs (http://...) since we don't need to care for mapping the URL to some valid file name. *) Annotations keep associated with the file after downloading it from the web and opening a local copy (possibly under a different name). It works not nicely in several ways: *) Md5 sucks, use Sha1 I don't see any serious security threat by using a weak hash function at this point. All an attacker could do would be to create a modified file for which the same annotations would be displayed as for the file the annotations were initially created for. I like Ivo's proposal to use QCryptographicHash, which supports MD4, MD5, and Sha1, so these are natural candidates. *) Reading the whole file sucks, i don't want the 100MB of my pdf file to be piped though a hash, it't probably take *some* time Just tried it on my ancient AMD64 2GHz machine and found the following computing times for a 500MB file: MD4: 1.3 seconds MD5: 2 seconds SHA1: 4 seconds Loading the file from a local hard disk takes considerably longer, so I'm not very much concerned about the hash computation time. However, the readAll() definitely has to be replaced by reading smaller chunks and processing them sequentially, that was just for the proof of concept. so reading up to 1MB as much would be much better imho. If an annotation refers to a typo on the last page of a huge document, and this gets fixed, the same annotation would still be displayed for the corrected file if the correction appears after the portion of the file for which the hash value is computed (at least for uncompressed formats such as PostScript). BTW, the current implementation in okular has the same problem since changing a single character in a PostScript file usually doesn't change its size. Kind regards, Markus -- Markus Grabner - Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria Phone: +43/316/873-5041, Fax: +43/316/873-5050 WWW: http://www.icg.tugraz.at/Members/grabner ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] md5 hash for annotation file name
A Dijous 11 Setembre 2008, Markus Grabner va escriure: Am Mittwoch, 10. September 2008 schrieb Albert Astals Cid: A Dimecres 10 Setembre 2008, Markus Grabner va escriure: Hi! It has been discussed (http://bugs.kde.org/show_bug.cgi?id=151614) to use a hash function to determine the name of the annotation file created by okular. The attached patch implements this behaviour (thanks Ivo for pointing me to QCryptographicHash - I looked for such a thing but somehow missed it). It works nicely in several ways: *) Annotations keep associated with the file after renaming it. *) It also works for non-local URLs (http://...) since we don't need to care for mapping the URL to some valid file name. *) Annotations keep associated with the file after downloading it from the web and opening a local copy (possibly under a different name). It works not nicely in several ways: *) Md5 sucks, use Sha1 I don't see any serious security threat by using a weak hash function at this point. All an attacker could do would be to create a modified file for which the same annotations would be displayed as for the file the annotations were initially created for. I like Ivo's proposal to use QCryptographicHash, which supports MD4, MD5, and Sha1, so these are natural candidates. It's not an attacker, it's you having two files that collide and gets you annotations from one to another. *) Reading the whole file sucks, i don't want the 100MB of my pdf file to be piped though a hash, it't probably take *some* time Just tried it on my ancient AMD64 2GHz machine and found the following computing times for a 500MB file: Calling a AMD64 2Ghz ancient makes me think what an EeePC is, prehistory? MD4: 1.3 seconds MD5: 2 seconds SHA1: 4 seconds Loading the file from a local hard disk takes considerably longer How much is that? , so I'm not very much concerned about the hash computation time. However, the readAll() definitely has to be replaced by reading smaller chunks and processing them sequentially, that was just for the proof of concept. So can you see if splitting the read gives us an improvement, 4 seconds on an AMD64 2GHz seems a lot to me. so reading up to 1MB as much would be much better imho. If an annotation refers to a typo on the last page of a huge document, and this gets fixed, the same annotation would still be displayed for the corrected file if the correction appears after the portion of the file for which the hash value is computed (at least for uncompressed formats such as PostScript). BTW, the current implementation in okular has the same problem since changing a single character in a PostScript file usually doesn't change its size. You have a point here Albert Kind regards, Markus ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] md5 hash for annotation file name
Am Donnerstag, 11. September 2008 schrieb Albert Astals Cid: A Dijous 11 Setembre 2008, Markus Grabner va escriure: I don't see any serious security threat by using a weak hash function at this point. All an attacker could do would be to create a modified file for which the same annotations would be displayed as for the file the annotations were initially created for. I like Ivo's proposal to use QCryptographicHash, which supports MD4, MD5, and Sha1, so these are natural candidates. It's not an attacker, it's you having two files that collide and gets you annotations from one to another. Ok, it's a tradeoff between collision probability and speed, I don't see a clear winner now. Have MD5 collisions been observed under normal conditions (i.e., without injecting some binary code into one of the files)? *) Reading the whole file sucks, i don't want the 100MB of my pdf file to be piped though a hash, it't probably take *some* time Just tried it on my ancient AMD64 2GHz machine and found the following computing times for a 500MB file: Calling a AMD64 2Ghz ancient makes me think what an EeePC is, prehistory? Do you really want to work with a 500MB file on an EeePC :-? MD4: 1.3 seconds MD5: 2 seconds SHA1: 4 seconds Loading the file from a local hard disk takes considerably longer How much is that? 24 seconds for the first time, then 11 seconds when the file is cached. It's a Seagate ST3300622A SATA drive. So the hash computation overhead is moderate on this system. Kind regards, Markus -- Markus Grabner - Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria Phone: +43/316/873-5041, Fax: +43/316/873-5050 WWW: http://www.icg.tugraz.at/Members/grabner ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
