Bug 35378

Summary: Poppler::Document::load() function fails on some MS-Windows configurations
Product: poppler Reporter: yoch <yoch.melka>
Component: qt4 frontendAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86 (IA32)   
OS: Windows (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: 0001-qt4-Use-PDFDoc-wchar_t-.-on-Windows.patch

Description yoch 2011-03-17 01:01:05 UTC
I,

I'm used poppler-qt4 with Qt (4.7) for displaying pdf documents.

Some users have encountered a bug: the documents are not displayed, because load() function fails on their system (it's works perfectly for me).

It seems that this is because those users use a system in Hebrew, but 
maybe is it something else (I'm using Vista and they are under Seven).

I replaced the call to load () function with a call to the function loadFromData () and everything works perfectly for everyone ...

Thanks...
Comment 1 Albert Astals Cid 2011-03-17 03:08:51 UTC
Unless you can provide precise examples of what is wrong i don't know how you expect us to fix anything.
Comment 2 yoch 2011-03-17 04:26:10 UTC
(In reply to comment #1)
> Unless you can provide precise examples of what is wrong i don't know how you
> expect us to fix anything.

The trouble is that it works for me... This bug occurs on Systems like MS-Windows Seven in hebrew, or MS-Windows Seven x64 in French, etc. The problem is clearly that the load() function fails on some systems, and that document is not initialized.

I looked at the sources of poppler-qt4, notament poppler-document.cc, and I think that the problem depends on the use of the function QFile:: EncodeName ()

In the documentation of Qt, section QString::toLocal8Bit(), it says:
"If this string contains"any characters encoded That Can not Be In The Local, The Returned byte array is undefined. Those characters suppressed Gold May Be Replaced by Another."

For example, you can solve this problem by calling loadFromData() since the load() function, like this :

Document *Document::load(const QString &filePath, const QByteArray &ownerPassword, const QByteArray &userPassword)
{
    QFile file(filePath);
    if (!file.open(QIODevice::ReadOnly))
        return NULL;

    QByteArray data = file.read( file.size() ); file.close();
    return loadFromData(data);
}
Comment 3 Albert Astals Cid 2011-03-17 04:37:27 UTC
QFile:: EncodeName () is correct, it is what you have to use when you pass QStrings to functions like fopen that are 8bit aware.
Comment 4 yoch 2011-03-20 02:36:54 UTC
(In reply to comment #3)
> QFile:: EncodeName () is correct, it is what you have to use when you pass
> QStrings to functions like fopen that are 8bit aware.

I'm don't think. How do you explain that the call to load() does not always work, whereas if I use my patch that works perfectly ?
Comment 5 Albert Astals Cid 2011-03-20 06:15:17 UTC
http://doc.qt.nokia.com/4.6/qfile.html#encodeName
Comment 6 yoch 2011-03-23 00:54:22 UTC
(In reply to comment #5)
> http://doc.qt.nokia.com/4.6/qfile.html#encodeName

Okay, so you say the problem comes from Qt ?
Comment 7 Albert Astals Cid 2011-03-23 01:52:04 UTC
No.
Comment 8 yoch 2011-03-23 04:35:03 UTC
Feel free to believe me or not...

This bug exists really in Windows Seven, which is clearly due to QFile::EncodeName() function, or more generally the QString::toLocale8Bit() function, which does not properly convert all the characters ...

The bug is easy to reproduce : use poppler_qt4viewer.exe on Windows Seven, and try to open a pdf file whith filename or pathname contains hebrew chars (probably also other exotic characters)...

++
Comment 9 Albert Astals Cid 2011-03-23 11:54:28 UTC
Then it's you saying it's a Qt bug?
Comment 10 yoch 2011-03-24 00:42:58 UTC
(In reply to comment #9)
> Then it's you saying it's a Qt bug?

I think (but I could be wrong).

Bugreport created :
http://bugreports.qt.nokia.com/browse/QTBUG-18274
Comment 11 yoch 2011-04-18 05:57:07 UTC
Okay, this is not a bug in Qt.

I quote the reply to my report :

"imo this is invalid use case. QFile::encodeName is documented to encode the file name in a local 8 bit encoding, which will is not unicode, hence it will not be able to handle certain characters.

For example, if you Windows is configured in Russian, then the local 8bit encoding is cp1251, so QFile::encodeName tries to convert a string from UTF-16 (that's how QString stores the data) to cp1251 - russian characters will be converted properly and you will be able to use the resulted string with fopen(), however e.g. Hebrew characters will not be handled correctly because they cannot be represented in cp1251.

Try using QFile api to access the file content - that should better as it doesn't convert the file name to the local 8 bit encoding. Alternatively, use Win32 api directly to access the file (i.e. CreateFile, etc)"
Comment 12 Hib Eris 2011-11-01 05:59:17 UTC
In the poppler glib bindings on windows we use
  new PDFDoc(filenameW, length, password_g, password_g);
instead of
  new PDFDoc(filename_g, password_g, password_g);
to create a PDFDoc. See glib/poppler-document.cc

I guess, the same thing should work for the qt bindings in poppler-private.h: DocumentData(GooString *filePath, GooString *ownerPassword, GooString *userPassword)
Comment 13 Hib Eris 2011-11-01 12:34:53 UTC
Created attachment 53018 [details] [review]
0001-qt4-Use-PDFDoc-wchar_t-.-on-Windows.patch

This patch fixes this issue for me in poppler_qt4viewer.exe
Comment 14 Albert Astals Cid 2011-11-01 16:49:14 UTC
Thanks Hib, i've commited it to master, will wait for the kde windows guys input before backporting to 0.18.x

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.