Unless you can provide precise examples of what is wrong i don't know how you expect us to fix anything.

(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);
}

QFile:: EncodeName () is correct, it is what you have to use when you pass QStrings to functions like fopen that are 8bit aware.

(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 ?

http://doc.qt.nokia.com/4.6/qfile.html#encodeName

(In reply to comment #5)
> http://doc.qt.nokia.com/4.6/qfile.html#encodeName

Okay, so you say the problem comes from Qt ?

No.

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)...

++

Then it's you saying it's a Qt bug?

(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

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)"

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)

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

Thanks Hib, i've commited it to master, will wait for the kde windows guys input before backporting to 0.18.x