Riku Leino wrote: > Nicholas Vettese wrote: >> Select get text -> browse and select the document - > click open >> Nothing happens
... because we're clearly not checking for an error return from gzopen(...) and telling the user like we should be. > And if anybody knows anything > about gzopen and supported encodings, please let us know. At least on *nix, gzopen is unaware of text encodings. It, like the vast majority of UNIX library and system calls, must be passed text in the local 8 bit encoding. It works on byte strings and has no understanding of "text". This will be because it passes the arguments though to the underlying fopen() from the C library. It seems this might be different on win32, probably due to the use of native win32 file handling calls. I'll check it out once I'm done with my exams. BTW, re the bug comment, QString::ucs2() strings cannot be used as arguments in functions that take just a `const char *'. Because UCS-2 can contain embedded null characters and often does, it just won't work. Most functions provide a second form that takes an integral argument for the string length in bytes so they don't need to check for null termination. Anyway, we know gzopen doesn't require a UCS-2 string for its argument, because it works correctly when the input string has no non-ASCII chars (ie the lower 7 bits are matching). If it was interpreting the argument as UCS-2 this would not be the case since it's a 2-byte wide encoding and the string would be interpreted as gibberish. -- Craig Ringer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20061114/bc3ead91/attachment.pgp
